Мы используем очень мощный компьютер Oracle 11G; имеет избыточное хранилище и т. д. Это зверь из того, что мне сказали.
Мы только что получили эту БД для инструмента, который, когда я впервые пришел в кооператив, использовали около 20 человек, а теперь уже более 150 человек. Я единственный работаю над этим :(
В настоящее время у нас есть система, которая распределяет скрипты PERL по всему нашему центру обработки данных, по сути, предоставляя нам своего рода вычислительную мощность «грид».
Скрипты Perl запускают своего рода моделирование и отправляют результаты в базу данных. Они выбирают / вставляют. Нагрузка на каждый скрипт не очень высока, но она может происходить в 20-50 системах одновременно.
Затем у нас есть несколько центров обработки данных, и все пользователи обращаются к одной и той же базе данных с помощью одного и того же подхода.
Наша основная проблема с этим заключается в том, что наша база данных перегружается соединениями и вынуждена их отбрасывать. Иногда у нас бывает более 500 подключений. Это старые сценарии Perl, и они плохо с этим справляются. По сути, они терпят неудачу, и результаты теряются. Я бы предпочел избежать необходимости переписывать многие из них, поскольку они плохо написаны и даже смотреть на них затруднительно.
Сама база данных не перегружена, просто накладные расходы на соединение слишком велики. Мы открываем соединение, делаем быстрый запрос и затем разрываем соединение. Очень короткие связи, но их много. Команда базы данных в основном сказала, что нам нужно уменьшить количество подключений, иначе они игнорируют нас.
Поскольку это распределено по нашей ферме, мы не можем реализовать постоянные соединения. Я делаю это с помощью нашего веб-сервера; но это в фиксированной системе. Остальные - это скрипты Perl, которые открываются и закрываются инструментом распространения и поэтому не всегда выполняются.
Как я могу лучше всего решить эту проблему? Сами скрипты могут дождаться открытия соединения. Им не нужно действовать немедленно. Какая-то система очередей?
Мне предложили создать несколько экземпляров инструмента под названием «SQL Relay». Может быть, по одному в каждом дата-центре. Насколько надежен этот инструмент? Насколько хорош такой подход? Сработает ли это для того, что нам нужно?
Мы могли бы иметь по одному для каждого центра обработки данных и передавать через него запросы в нашу основную базу данных, сохраняя конвейер открытых постоянных подключений? Имеет ли это смысл?
Есть ли еще какие-нибудь предложения? Любые идеи? Любая помощь будет принята с благодарностью.
К сожалению, я всего лишь студент-кооператив, работающий в очень большой компании, и каким-то образом все это легло мне на плечи (буквально не к кому обратиться за помощью; это аппаратная компания, все инженеры по аппаратному обеспечению, а команда базы данных бесполезна и в Индии), и я совершенно не понимаю, что было бы лучше всего?
Я очень перегружен работой, и эта проблема мешает продолжающемуся прогрессу, и, по сути, ее необходимо решить как можно быстрее; желательно без переписывания всей системы, покупки оборудования (этого не произойдет) и без пули.
ПОМОГИТЕ LOL!
«Мы открываем соединение, делаем быстрый запрос и затем разрываем соединение. Очень короткие соединения, но их много».
Я бы попробовал с подключениями к общему серверу. Oracle, работающий в системе unix, нуждается в процессе unix для выполнения «работы», запрошенной сеансом. Обычно при выделенном соединении он разветвляет новый процесс unix при подключении сеанса и завершает его при отключении сеанса.
В разделе «Общие серверы» администратор баз данных определяет минимальное и максимальное количество подключений, скажем, 100 и 250. При запуске база данных разделяет 100 процессов, и они ждут подключения. Если он получит 150 запросов, он запустит дополнительные 50 необходимых процессов. Если он получит 300 запросов, 50 из них будут зависать, пока не станет доступен один из 250 (макс.) Процессов.
Важно отметить, что процессы не привязаны к конкретному сеансу на время его существования, а только для конкретного вызова (например, отдельной вставки или обновления). Это действительно влияет на использование памяти. Все, что сохраняется между вызовами, должно находиться в общей памяти (SGA), а не в памяти процесса (PGA). Однако в версии 11g база данных может перемещать память между SGA и PGA, так что это не так важно, как раньше.
Читать далее Вот
Подключение / отключение от Oracle обходится довольно дорого, и использование ресурсов не отслеживается в обычных представлениях статистики Oracle. Вы можете увидеть это в некоторой степени в модели v $ system_time при времени соединения, но я видел случаи, когда это было не так в четыре раза. Просто чтобы привести примерную цифру - пара подключений в секунду может легко сжечь все ядро на 100%.
Если у вас есть процессор, который нужно записать, в целом все в порядке, за исключением того, что вы вводите задержку. Решение состоит в том, чтобы использовать пул сеансов, т.е. создать набор подключений к базе данных и иметь уровень кода, который управляет тем, кто использует эти подключения.
Многопоточный сервер Oracle - это всего лишь хакерское решение от Oracle, которое дает меньше, чем можно было бы ожидать от названия и маркетинга.
Вам нужны некоторые данные, чтобы понять это. У вас есть менеджер Oracle Enterprise Manager? Часто он подскажет вам, что именно вам нужно делать. Без этого вам нужно будет указать, какие сообщения об ошибках получают скрипты, и все, что отображается в журнале предупреждений одновременно. 500 подключений - это немного в мире Oracle, но есть параметры конфигурации, которые, возможно, потребуется увеличить.
Вы тестировали систему под нагрузкой, если увеличиваете количество подключений? Если у вас есть отдельная среда для тестирования, это было бы хорошо.
В краткосрочной перспективе, если вы можете контролировать, КОГДА выполняются сценарии, вы можете управлять им, так что вам не нужно привязывать соединения в любой момент времени. Вместо этого вы могли бы со временем растянуть его. Вы говорите, что сценарии могут ждать соединения, я бы сказал, что это лучшее место для начала.
Я полагаю, что также можно найти улучшения производительности, найдя запросы, выполнение которых занимает больше всего времени. Возможно, удастся найти улучшения, добавив индекс к таблице, которая может не индексироваться.