В последнее время, если вы хотите проверить максимальное количество параллелей под OpenFire, вам необходимо открыть большое количество потоков для моделирования клиента. Я всегда был озадачен тем, сколько потоков может открыться экземпляр JVM, поэтому я планирую проверить его и найти следующие факторы, которые влияют на количество потоков:
-Xms | Интенсивный размер кучи Java |
-Xmx | максимальный размер кучи Java |
-Xss | Размер стека для каждого потока |
Системные ограничения | Максимальное количество потоков, которые можно открыть в системе |
Программа тестирования заключается в следующем: код Java:
импортировать java.util.concurrent.atomic.atomicinteger; Public Class TestThread Extends Thread {Private Static Final AtomicInteger Count = new Atomicinteger (); public static void main (string [] args) {while (true) (new TestThread ()). start (); } @Override public void run () {System.out.println (count.incrementAndget ()); while (true) try {thread.sleep (integer.max_value); } catch (прерванная экспрессия e) {break; }}} Тестовая среда: Система: Ubuntu 10.04 Linux Kernel 2.6 (32-битный)
Память: 2G
JDK: 1,7
Результаты теста:
Ø Не учитывая системные ограничения
-Xms | -Xmx | -Xss | результат |
1024M | 1024M | 1024K | 1737 |
1024M | 1024M | 64K | 26077 |
512 м | 512 м | 64K | 31842 |
256 м | 256 м | 64K | 31842 |
Когда количество созданных потоков достигает 31 842, в системе не может быть создано нити.
Из приведенных выше результатов теста можно видеть, что увеличение памяти кучи (-xms, -xmx) уменьшит количество потоков, которые могут быть созданы, и увеличение памяти стека потоков (-xss минимальное значение этого параметра в 32-битных системах составляет 60 тыс.) Также уменьшит количество потоков, которые могут быть созданы.
Ø в сочетании с системными ограничениями
Предел количества потоков 31842 определяется максимальным количеством потоков, которые система может генерировать:/proc/sys/kernel/threads-max, но ее значение по умолчанию составляет 32080. Модифицировать его значение до 10000: Echo 10000>/Proc/Sys/Kernel/Threads-max, а результаты модифицированных тестов являются следующими:
-Xms | -Xmx | -Xss | результат |
256 м | 256 м | 64K | 9761 |
В этом случае это означает, что может быть настроено как можно больше потоков? Сделайте еще одну модификацию: Echo 1000000>/proc/sys/kernel/threads-max, модифицированные результаты теста следующие:
-Xms | -Xmx | -Xss | результат |
256 м | 256 м | 64K | 32279 |
128M | 128M | 64K | 32279 |
Установлено, что количество потоков больше не будет увеличиваться после достижения 32279. После проверки максимальное количество PID, которые могут быть созданы с помощью 32-разрядной системы Linux, составляет 32678. Это значение может быть изменено через/proc/sys/kernel/pid_max (метод модификации одинаково, что и потоки), но в системе 32, это может быть изменено, и это может быть меньше, и может быть меньше, и может быть меньше, и это может быть меньше, и это может быть меньше. Когда Threads-Max определенно, результаты теста для изменения PID_MAX заключаются в следующем:
pid_max | -Xms | -Xmx | -Xss | результат |
1000 | 128M | 128M | 64K | 582 |
10000 | 128M | 128M | 64K | 9507 |
Ситуация на окнах должна быть аналогичной, но количество потоков, которые могут быть созданы в Windows, может быть меньше Linux. Серверы на основе модели потока всегда ограничены количеством потоков.
На максимальное число, которое может быть сгенерировано в JVM, влияет размер памяти кучи JVM, размер памяти стека и максимальное количество потоков, которые может создать система (реализация потоков Java основана на механизме резьбы под Linux). Конкретное количество может быть оценено на основе максимальной памяти, к которой может получить доступ процесс Java (обычно 2G в 32-битных системах), памяти кучи и памяти стека потока.
последовательность:
Протестированный на 64-разрядной системе Linux (Memory CentoS6, 3G), я обнаружил, что существует другой параметр, который ограничивает количество потоков: maxuserProcess (можно просматривать через Ulimita, значение по умолчанию составляет 1024, и это значение может быть изменено через Ulimitu). Это значение не ограничено в вышеуказанной 32-битной тестовой среде Ubuntu.
Измените Threads -Max, PID_MAX, MaxuserProcess, все три параметра до 100000, -xms, -xmx как можно меньше (128 м, 64 м) и -xS как можно меньше (104K при 64 битах, значение может быть 128 тыс.). Предсказанный заранее в этой тестовой среде количество потоков будет ограничено только размером памяти (3G) тестовой среды. Тем не менее, фактический результат теста заключается в том, что когда количество потоков достигает 32 тыс. (32768, максимальное количество созданных составляет около 33 000), JVM бросает предупреждение: попытка ToallocateStackGuardPages не удалось, а затем OutofmemoryError не может создать локальную нить. После проверки памяти я обнаружил, что есть еще много свободного времени, поэтому это не должно быть связано с емкостью памяти. Предупреждение Google бесплодно. Я не знаю почему, и это требует дальнейших исследований.
Шаг 2:
Я случайно обнаружил статью [7] сегодня и попробовал ее немедленно. Конечно же, этот коэффициент повлияет на количество создания потоков. Согласно описанию в статье, количество/proc/sys/vm/max_map_count удваивается с 65536 до 131072. Общее количество созданных потоков достиг 65000+. Компьютер в основном должен застрять (память 3G) ... Я кратко проверил функцию этого параметра, и описание в [8] выглядит следующим образом:
«Этот файл содержит максимальное количество MemoryMapareasPocessmayhave.memorymapareasareusedasaside-эффект Callingmalloc, непосредственно Bymmapandmprotect, Andalso при загрузке общих библиотек.
В то время как большинство приложений необходимы меньше, чем у карт, определенные программы, особенно Mallocdebuggers, могут потреблять задницу, например, UptoOneortWomapsPerallocation.
Thedefaultvalueis65536 ".
Хорошо, эта проблема наконец была решена полностью. Наконец, факторы, влияющие на количество потоков Java, обобщены:
Сама виртуальная машина Java: -xms, -xmx, -xss;
Системные ограничения:
/proc/sys/kernel/pid_max,
/proc/sys/kernel/thread-max,
max_user_process (ulimit-u),
/proc/sys/vm/max_map_count.
Суммировать
Выше приведено все о простом испытании JVM, поддерживающего максимальное количество потоков. Я надеюсь, что это будет полезно для всех. Заинтересованные друзья могут продолжать ссылаться на другие связанные темы на этом сайте. Если есть какие -либо недостатки, пожалуйста, оставьте сообщение, чтобы указать это.