В прошлые выходные я сделал много предупреждений об ограничении тока во время мероприятия. Поэтому я попросил бога эксплуатации и обслуживания сначала добавить машины, чтобы временно выдерживать давление. Волна расширения добавила несколько машин. Затем я увидел больше предупреждений об истечении времени ожидания ответа интерфейса.
2019-06-22 23:32:07,957 WARN [New I/O server worker #1-9] com.alibaba.dubbo.common.threadpool.support.AbortPolicyWithReport:warn:54 [DUBBO] Thread pool is EXHAUSTED! Thread Name: DubboServerHandler-172.***:62075, Pool Size: 200 (active: 200, core: 200, max: 200, largest: 200), Task: 771 (completed: 571), Executor status:(isShutdown:false, isTerminated:false, isTerminating:false), in dubbo://172.***:62075!, dubbo version: 2.5.3, current host: 172.16.6.3
Thread pool is EXHAUSTED!
Устранение неполадок
Что? Пул потоков исчерпан.
1. Слишком много повторных попыток для клиентских вызовов?
Проверил и обнаружил, что количество повторных попыток для всех запросов равно 0.
2. Установлено ли слишком большое время ожидания ответа интерфейса?
Время ожидания для одного запроса составляет 3 с.
3. Есть ли блокировка потока?
Откройте Артаса.
thread -b
thread
Обнаружено, что все SimpleAsyncTaskExecutors заблокированы. Так что же они делают?
эпизод
После того, как эксплуатация и обслуживание перезапустили службу, поток SimpleAsyncTaskExecutor постепенно блокировался. (просто все для блокировки)
Продолжить просмотр одного из
thread 378
принадлежит DubboServerHandler Читать дальше
thread 146
Чтобы разобраться, текущий вывод состоит в том, что это не взаимоблокировка, а аномалия в запросе к базе данных. Странно, если в базе данных проблема другого рода
Почему нет сигнализации для службы?
Пожалуйста, проверьте работу и техническое обслуживание, конечно же, база данных приложения не находится в том же сегменте сети и не добавлена в белый список ip.
В заключение
Расширение игнорирует ссылки на базу данных. Исправлена проблема с белым списком.
считать
Согласно приведенному выше списку, есть проблема с подключением к базе данных. Это как-то связано со стратегией диспетчера Dubbo?
Решение было найдено в Интернете: (без проверки)
Измените политику диспетчера провайдера dubbo и установите для нее значение message
Диспетчер по умолчанию использует все, и все запросы будут распределяться в пул бизнес-потоков для обработки.
Размер пула бизнес-потоков по умолчанию для dubbo равен 200, а длина очереди ожидания равна 0.
Когда пул потоков заполнен, последующие запросы будут отброшены.
Однако отклоненные запросы также будут переданы в пул бизнес-потоков для обработки.
В этот момент может показаться, что сервер отказался, но потребитель ждал, пока истечет время ожидания.