|
Tomcat 8 оптимальные настройки для высокой нагрузки.
|
|||
---|---|---|---|
#18+
Добрый день. Поделитесь пожалуйста опытом как правильно настроить систему. Дано: 1. Два сервера приложений c одинаковой конфигурацией - Tomcat 8 (-Xmx26G), Java 8, Centos 7, 5 разных приложений обрабатывающих http запросы. 2. Балансировщик roundrobin dns. Есть проблема - часто клиенты приложений получают ошибку connection timeout. Моё предположение что это происходит из-за сборщика мусора java пока собирается мусор томкат не отвечает и попытка соединения завершается с ошибкой connection timeout. Какие варианты я рассматривал: 1. Увеличить количество серверов приложений, чтобы нагрузка была меньше на каждый конкретный сервер. 2. Выделить каждое приложение в отдельный инстанс томката, что в результате тоже приведёт к снижению нагрузки но уже на уровне томката, а не всего сервера. 3. Сделать "тонкую настройку" сборщика мусора в надежде получить минимальные задержки при сборке мусора. (Как их делать я пока не знаю) Что вы посоветуете в этой ситуации? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2022, 14:05 |
|
Tomcat 8 оптимальные настройки для высокой нагрузки.
|
|||
---|---|---|---|
#18+
Самое главное на этом этапе - определить профиль нагрузки, т.е. какие сервера насколько загружены, как часто и насколько долго там GC происходит, сколько памяти съедается. Иначе любое решение будет наугад. PS: такой огромный хип (26G) правда нужен? Настолько много данных в память загружается? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2022, 14:13 |
|
Tomcat 8 оптимальные настройки для высокой нагрузки.
|
|||
---|---|---|---|
#18+
Stanislav Bashkyrtsev, При установки объёма памяти исходили из того что много памяти это всегда хорошо. Все сервера нагружены примерно одинаково, zabbix, в среднем, показывает 50% загрузки. На серверах всего 32 ГБ памяти и 8 процессоров (потоков не сокетов). Нагрузка распределяется примерно так 80% запросов это мелочь, ответ сервера не превышает 5-7кб остальные ответы могут быть 10 и более мегабайт. Количество запросов примерно 2 тыс./сек. всего на оба сервера, на один получается примерно 1 тыс./сек. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2022, 14:25 |
|
Tomcat 8 оптимальные настройки для высокой нагрузки.
|
|||
---|---|---|---|
#18+
Mandarin , 1тыщ/сек - это больше чем я когда-либо обрабатывал, поэтому на мои советы можно не особо полагаться. Это вместе со статикой или это все доходит прям до апп сервера и БД? Парочка комментариев: MandarinПри установки объёма памяти исходили из того что много памяти это всегда хорошо.Хм.. как-то нелогично. Чем больше хипа, тем длинней будут full GC задержки. Я бы выделял памяти столько сколько надо, не накидывая сверху просто так. MandarinВсе сервера нагружены примерно одинаково, zabbix, в среднем, показывает 50% загрузки. Среднее - это медиана? Звучит многовато.. Получается во время пиковой загрузки мы уходим под 100%? И подобные цифры на БД серверах тоже? Mandarinчасто клиенты приложений получают ошибку connection timeout.Т.к. это connection timeout, то значит клиент не смог даже подключиться. Т.е. в очередь на соединение (Socket acceptCount) он попал, и ждет когда же до него дойдет обработка. И может это не GC, а просто потоки успевают? Если так то я бы уменьшил maxConnections. Чтоб Томкат не принимал соединения если он не справляется. Счас они видимо приняты и просто ждут своей очереди. Если же уменьшить их, то все connection timeout должны уйти и вместо них появятся connection reset/refused. Но они будут сразу случаться, а не ждать еще таймаута. И не будут лишние ресурсы удерживать. Но опять же - это все наугад. Надо все-таки замерить и точно узнать GC это или нет. И если GC, то первое что приходит в голову - уменьшать хип. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2022, 14:42 |
|
Tomcat 8 оптимальные настройки для высокой нагрузки.
|
|||
---|---|---|---|
#18+
Stanislav Bashkyrtsev, Уменьшение хипа может привести к появлению ошибки ОutOfMemmory, наверное придётся увеличить количество серверов, сделать там меньше конфигурацию, соответсвенно и хип уменьшится. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2022, 14:56 |
|
Tomcat 8 оптимальные настройки для высокой нагрузки.
|
|||
---|---|---|---|
#18+
Я думаю что для серверных решений есть "плавная" сборка мусора которая не должна приводить к тому что приложение замирает, ну или это должно происходить очень не продолжительное время. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2022, 15:00 |
|
Tomcat 8 оптимальные настройки для высокой нагрузки.
|
|||
---|---|---|---|
#18+
Mandarin, Че ты уперся в сборщик мусора. Разве ты точно выяснил что это бутылочное горлышко? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2022, 15:19 |
|
Tomcat 8 оптимальные настройки для высокой нагрузки.
|
|||
---|---|---|---|
#18+
Mandarin, Нагрузочный тест вообще не делал? Как писать без тестов то вообще? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2022, 15:21 |
|
Tomcat 8 оптимальные настройки для высокой нагрузки.
|
|||
---|---|---|---|
#18+
Хотя бы собрать базову информацию по нодам: - график CPU utilization - график heap - график использования tomcat http pool Без этого ничего вообще сказать нельзя. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2022, 19:05 |
|
Tomcat 8 оптимальные настройки для высокой нагрузки.
|
|||
---|---|---|---|
#18+
Коллеги. Я еще раз верну всех к первому посту. Mandarin Есть проблема - часто клиенты приложений получают ошибку connection timeout. Моё предположение что это происходит из-за сборщика мусора java пока собирается мусор томкат не отвечает и попытка соединения завершается с ошибкой connection timeout. Несколько мыслей 1) Как верно заметил Петро - н ет оснований пока говорить что виноват GC. Поэтому предлагаю автору включить логгирование GC. Для восьмёрки Код: java 1.
В логах мы должны видеть таймауты. Я не знаю какой должен быть таймаут для того чтоб сокет не открылся вовремя. Это - вопрос открытый ко всем. Но мы должны УВИДЕТЬ проблему в этих логах и сматчить ее с ситуацией на конкретной ноде. Если клиент получал ошибку connection timeout - то в это время в логах должно сверкнуть аномально-большое время. Это будет доказательством связи GC с проблемой. Таймаутом GC можно поуправлять. Можно попробовать активировать G1GC (он должен быть в восмерке) Поставим 100 мс на цикл сборки. Код: java 1.
Это не гарантированная макс пауза а скорее некое пожелание к GC работать ограниченное время. 2) Что там за алгоритм вообще во время высокой нагрузки ? Может в нем проблема? Надо собрать сведенья профилирования для той ситуации когда баг воспроизводится. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2022, 20:54 |
|
Tomcat 8 оптимальные настройки для высокой нагрузки.
|
|||
---|---|---|---|
#18+
Хочу напомнить уважаемым экспертам, что при обработке HTTP-запросов действуют два разных таймаута. Сначала клиент ожидает первый байт (заголовков) ответа. И ожидает он не более пятнадцати минут. И этим временем нельзя управлять. P.S. 26ГБ - порадовало: "В этом году мы посеем двести га свеклы - пусть долгоносик обожрётся до смерти". ... |
|||
:
Нравится:
Не нравится:
|
|||
08.02.2022, 08:35 |
|
Tomcat 8 оптимальные настройки для высокой нагрузки.
|
|||
---|---|---|---|
#18+
Mandarin на один получается примерно 1 тыс./сек. Вкллючай дебаг у логера и к гадалке не ходи увидишь o.apache.tomcat.util.threads.LimitLatch : Counting up[http-nio-8081-Acceptor] latch=503 Наверняка дефолтные server.tomcat.max-threads=200 не тянут 1 тыс./сек ... |
|||
:
Нравится:
Не нравится:
|
|||
08.02.2022, 23:04 |
|
Tomcat 8 оптимальные настройки для высокой нагрузки.
|
|||
---|---|---|---|
#18+
1000 в секунду ... это тяготеет к react/netty. Даже не верится. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.02.2022, 23:48 |
|
Tomcat 8 оптимальные настройки для высокой нагрузки.
|
|||
---|---|---|---|
#18+
MandarinНагрузка распределяется примерно так 80% запросов это мелочь, ответ сервера не превышает 5-7кб остальные ответы могут быть 10 и более мегабайт. Количество запросов примерно 2 тыс./сек. всего на оба сервера, на один получается примерно 1 тыс./сек. Если так посчитать, то получается что в секунду приходит 200 запросов, ответ на которые более 10 мегабайт. Получается что томкат отдает больше 2 гагабайт пейлоада в секунду. Кажется что слишком много... Да и скорее всего каждый запрос на 10+мб отрабатывает не меньше чем за секунду. Можно поинтересоваться, что это за тип нагрузки такой? 1) гоняем данные из БД через REST (если БД в одном экземпляре, то кажется что если просто заскейлить приложения - то поплохеет ей) 2) какие либо данные из S3/файловой системы отдаем наружу? если не ошибаюсь, то скорости железа в принципе такие: сеть 10 GBps - 1.1 гб/сек крутой SSD на чтение - 4-7 гб/сек чтение из оперативной памяти Core i7 + DDR4 - 40~50 гб/сек ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2022, 14:32 |
|
|
Start [/forum/topic.php?fid=59&msg=40132698&tid=2120248]: |
0ms |
get settings: |
30ms |
get forum list: |
11ms |
check forum access: |
8ms |
check topic access: |
8ms |
track hit: |
124ms |
get topic data: |
23ms |
get forum data: |
6ms |
get page messages: |
738ms |
get tp. blocked users: |
3ms |
others: | 158ms |
total: | 1109ms |
0 / 0 |