Возможно, я неправильно формулирую заголовок этого вопроса, поэтому, возможно, лучше начать с наблюдаемого поведения.
Я установил предел PID, используя docker-compose из 120 PIDS для изображения на основе Java. Чтобы быть точным adoptopenjdk/openjdk11:jdk-11.0.2.9-alpine-slim
120 был немного произвольным в том смысле, что все, что я делал, это использовал docker stats, чтобы посмотреть на 20 бегущих изображений и отметить, что у них в то время все PID составляли <100, и я дал еще 20 в качестве запаса. </p>
С тех пор я наблюдал некоторое поведение, когда происходят подобные ошибки:
вызвано: java.lang.OutOfMemoryError: невозможно создать собственный поток: возможно, недостаточно памяти или достигнут предел процесса / ресурса
и docker stats показывают использование памяти около 80%, например:
301,8 МБ / 376 МБ 80,26% от используемой памяти
но принципиально 120 pids.
Теперь мне интересно несколько вещей:
- я просто установил 120 слишком низко, и если это так, то что разумно - может сильно зависеть от моего конкретного случая использования, такого как размеры пула потоков, одновременные запросы и активность GC и т. Д. Но если это так, то какой способ лучше всего измерить - возможно, измерить активность PIDS в течение недели или двух и установить уровень немного выше, чем макс.
- Знает ли JVM о применяемом в настоящее время пределе PIDS, может ли эргономика виртуальной машины даже определить этот предел и узнать, может ли виртуальная машина создавать больше потоков или есть флаги, которые могли бы сообщить об этом. Если это даже может сделать это, это фундаментально что-то изменит, например, ВМ была бы более консервативна в отношении количества потоков, которые она пытается начать выполнять, например, GC или JIT, или для внутреннего обслуживания?