Использует ли JVM OpenJDK Hotspot эргономику для определения количества служебных потоков (соблюдайте ограничения pids докеров)

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

Я установил ограничение PID, используя docker-compose 120 PIDS для образа на основе Java. Если быть точным adoptopenjdk/openjdk11:jdk-11.0.2.9-alpine-slim

120 было немного произвольным, поскольку все, что я сделал, это использовал docker stats для просмотра 20 бегущих изображений и отметив, что в то время все они имели счетчики PID ‹100, и я дал еще 20 в качестве запаса.

С тех пор я наблюдал некоторое поведение, когда возникают такие ошибки:

вызвано: java.lang.OutOfMemoryError: невозможно создать собственный поток: возможно, не хватает памяти или достигнуты ограничения процесса/ресурса

и docker stats показывает использование памяти около 80%, например:

301,8 МБ / 376 МБ, используется 80,26% памяти

но главное 120 pids.

Мне сейчас интересно несколько вещей:

  1. я только что установил 120 слишком низко, и если да, то что разумно - может сильно зависеть от моего конкретного варианта использования, такого как размеры пула потоков, одновременные запросы и активность GC и т. д. Но если это так, то как лучше всего измерить - возможно измеряйте активность PIDS в течение недели или двух и устанавливайте уровень чуть выше максимального.
  2. Знает ли JVM об ограничении PIDS, которое применяется в настоящее время, может ли эргономика виртуальной машины даже обнаружить это ограничение и узнать, способна ли виртуальная машина создавать больше потоков или существуют флаги, которые могли бы сообщить об этом. Если он даже может это сделать, изменит ли это что-нибудь фундаментально, например. VM будет более консервативен в отношении количества потоков, которые он пытается начать делать, например, GC или JIT или внутреннюю уборку?

person David    schedule 27.03.2019    source источник
comment
1. Зачем вообще ограничивать PID? В зависимости от приложения оно может создавать сотни или даже тысячи потоков. 2. Сама JVM создает фиксированное количество потоков. Опять же, приложение должно создавать новые потоки, и JVM не может помешать приложению это делать. Итак, НЕТ - JVM не учитывает ограничение PID.   -  person apangin    schedule 27.03.2019
comment
Что касается того, почему, чтобы обеспечить лучшую изоляцию, чтобы ограничить падение приложения, которое ведет себя неправильно; например en.wikipedia.org/wiki/Fork_bomb#Java Я не ожидал JVM принять меры для предотвращения создания потоков приложений. Мне было больше интересно, есть ли в игре эргономика виртуальной машины, подобная той, которая может произойти для количества процессоров, определяющих доступную память, когда JVM выделяет такие вещи, как потоки GC и адаптивное определение размера кучи, например. если бы JVM знала о некотором ограничении количества потоков, которое она может породить, я подумал, что возможно она могла бы быть менее агрессивной при этом.   -  person David    schedule 28.03.2019
comment
Если JVM может работать с меньшим количеством потоков с той же производительностью, зачем ей вообще создавать больше потоков? Вы можете уменьшить количество GC, компилятора и нескольких других потоков вручную, но это, скорее всего, повлияет на производительность или удобство обслуживания. JVM не делает этого автоматически.   -  person apangin    schedule 28.03.2019
comment
Я принимаю вашу точку зрения и согласен. Ответ становится все более ясным, и ваши знания о внутренностях JVM очень полезны. Я не заявлял, что ожидаю или хочу такой же производительности с меньшим количеством потоков. Моя основная цель состояла в том, чтобы улучшить изоляцию в случае, если один контейнер начинает потреблять слишком много ресурсов, что может негативно повлиять на другие предположительно изолированные контейнеры, а не поддерживать тот же уровень пропускной способности, например, для В любом случае, кажется, ответ теперь ясен, нет, JVM не знает предела PID, и даже если бы он знал, он не делал ничего адаптивного, спасибо.   -  person David    schedule 29.03.2019