В целом, лучше ли настроить службу REST Tomcat с рациональным ограничением максимального числа потоков или установить для нее практически бесконечное значение?

Question

На этот вопрос нет единого ответа, но я не знаю, где еще задать этот вопрос.

Я работаю в большой корпоративной системе, которая использует Tomcat для запуска служб REST, работающих в контейнерах, управляется kubernetes.

Tomcat, или любой другой обработчик запросов, обладает свойством «max threads», так что, если поступает достаточное количество запросов, это приводит к созданию множества потоков, если число созданных потоков достигает этого определенного предела. , он поместит дополнительные запросы в очередь (ограниченную значением другого свойства), а затем, возможно, запросы будут отклонены после того, как эта очередь заполнится.

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

Существует множество сценариев ios, которые следует учитывать, хотя единственными интересными являются случаи, когда трафик c чрезвычайно выше, чем обычно, либо из трафика реального клиента c, либо из вредоносного трафика ddos ​​c.

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

Некоторые члены моей команды считают, что для свойства "max threads" лучше установить эффективное бесконечность.

Что есть разумные мысли по этому поводу?

Answer 1

Как правило, я бы предложил попробовать масштабировать, запустив больше модулей (которые можно легко запланировать на нескольких хостах), а не запустив больше потоков. Для кластера также проще запланировать 16 одноядерных модулей, чем запланировать 1 16-ядерный модуль.

С точки зрения количества потоков, это зависит от того, сколько работы выполняет ваш процесс. Типичное веб-приложение тратит большую часть своего времени на общение с базой данных и выполняет небольшие локальные вычисления, поэтому вы часто можете настроить его на запуск 50 или 100 потоков, но при этом все еще с ограничением 1,0 ЦП, и эффективно использовать ресурсы. Если он требует значительных вычислительных ресурсов (скажем, он выполняет реальную обработку изображений или машинное обучение), вы можете ограничиться одним потоком на процессор. Плохой случай, когда ваш процесс выделяет 16 потоков, но на самом деле в системе доступно только 4 ядра, и в этом случае ваш процесс будет замедлен, но вы действительно хотите его увеличить.

Другое важное плохое состояние быть осведомленным о заполнении пула потоков. Если это произойдет, запросы будут помещены в очередь, как вы заметили, но если некоторые из этих запросов являются пробниками проверки работоспособности Kubernetes, это может привести к тому, что кластер будет регистрировать вашу службу как нездоровую. На самом деле это может привести к плохой спирали, когда перегруженная реплика будет уничтожена (поскольку она не отвечает на проверки работоспособности), поэтому ее загрузка отправляется другим репликам, которые также становятся перегруженными и перестают отвечать на проверки работоспособности. Вы можете избежать этого, запустив больше модулей или несколько потоков. (... или переписав ваше приложение во время выполнения, которое не имеет фиксированной верхней емкости, подобной этой.)

Также стоит прочитать об горизонтальном автоматическом скалере . Если вы можете подключить некоторые показатели c (загрузка ЦП, счетчик потоков), чтобы сказать «Мне нужно больше модулей», то Kubernetes может автоматически создавать для вас больше и уменьшать их, когда они не нужны.