Что вызывает всплески вызовов JDBC к Oracle из Websphere?

Question

Мне было интересно, может ли кто-то пролить свет на следующую проблему:

Мы наблюдаем всплески вызовов JDBC из веб-службы на основе Spring 2.5.6, запущенной в Websphere 6.1 в AIX для вызовов в 64-битную версию Oracle 10.2.0.5.0 Версия драйвера JDBC - 10.2.0.3.0 .

Мы работаем с базой данных одним потоком, среднее время ответа для веб-службы составляет 16 мс, но мы наблюдаем 11 всплесков продолжительностью около 1 секунды или более (среди 11 000 вызовов за 5 минут). Introscope сообщает нам, что примерно половина этих пиков вызвана «выбором 1 из двойного» (который используется пулом соединений Websphere для проверки соединения).

На стороне базы данных мы проследили сеансы, созданные пулом соединений Websphere, и ни один из них не указывает на пики внутри базы данных.

Любые идеи / предложения о том, что может быть причиной этих шипов?

EDIT:

Наш пул соединений настроен на 20 соединений, и мониторинг показывает, что используется только одно соединение.

EDIT2:

Мы обновили наш драйвер Oracle JDBC до 10.2.0.5 без каких-либо различий.

Answer 1

Ответ на эту проблему в конечном итоге не был связан с WebSphere или Oracle, но был старой доброй проблемой конфигурации сети, которая привела к тайм-аутам повторной передачи TCP между сервером WebSphere и кластером Oracle RAC.

В порядкечтобы получить эту диагностику, я посмотрел на вывод netstat -p tcp до и после пробного запуска и обнаружил, что показатель

retransmit timeouts

увеличивается.Теперь можно просмотреть конфигурацию алгоритма тайм-аута ретрансляции с помощью:

$ no -a
...
                 rto_high = 64
               rto_length = 13
                rto_limit = 7
                  rto_low = 1

, что указывает на то, что тайм-ауты повторной передачи будут занимать от 1 до 64 секунд и будут все больше уменьшаться, что объясняет, почему мы наблюдаем скачки1 секунда, 2 секунды, 4 секунды, 10 секунд и 22 секунды, но ничего от этих пиков (т. Е. Нет 6-секундного скачка).

Как только конфигурация сети была исправлена, проблема исчезла.

Answer 2

Возможно, это пул, размер которого не соответствует норме.

11 000 вызовов за 5 минут или 300 секунд, означает 37 вызовов в секунду. В среднем 0,016 секунды на соединение означает, что вы можете обработать 2 313 вызовов на соединение. Размер пула 4-5 должен уметь обрабатывать трафик. Я не знаю, выполняется ли один из этих запросов слишком долго, если запрос заканчивается ожиданием подключения.

Запрос «SELECT 1 FROM DUAL» - это то, что пул будет выполнять, чтобы проверить и проверить, является ли соединение активным и работоспособным.

Вы можете попробовать увеличить размер пула или посмотреть некоторые другие параметры, которые определяют, что пул делает с соединением, чтобы убедиться, что оно работает.

Answer 3

Помогает ли отключение «Предварительное тестирование новых подключений» ?