Я хочу точно понять, как использовать среднюю нагрузку и использование ЦП на машине Red Hat, на которой размещен только Tomcat 8. Посмотрев в сети, я сделал следующие утверждения. Верны ли утверждения? Я полностью уверен в первом, поскольку он взят из официальной документации Tomcat. И я не понимаю, какие процессы могут быть в непрерывном сне.
1) Tomcat использует поток для обработки запроса, максимальное количество используемых потоков определяется конфигурацией Tomcat (см. Документация Tomcat )
2) Oracle JVM работает с собственными потоками только с JRE 1.3 (см. JVM и потоки Ссылку на Oracle по этому поводу я не нашел)
3) Очередь выполнения Linux содержит процессы и потоки (собственные потоки id) таким же образом (см. Средняя загрузка Linux: разгадка тайны и Википедия )
4) Средняя загрузка показывает среднее количество процессов / потоков в очереди выполнения (см. Linux журнал )
5) На машине Linux, на которой запущен только Tomcat, средняя загрузка обеспечивает почти среднее количество запросов.
6) В Linux процесс / потоки подсчитывают среднюю загрузку в состоянии «запущено», «выполняется» и в состоянии непрерывного сна (см. Linux журнал )
7) Процесс / потоки в непрерывном спящем режиме ожидают ввода-вывода дисков, непрерывных блокировок, сетевого ввода-вывода (см. Документация Redhat который включает сетевой ввод / вывод и Средняя загрузка Linux: разгадка тайны который не включает сетевой ввод / вывод)
Пункт 7 не согласуется со ссылкой См. Linux журнал в котором говорится, что «Фактически, измеряется именно загрузка ЦП, потому что средние значения нагрузки не включают какие-либо процессы или потоки, ожидающие ввода-вывода, сети, баз данных или чего-либо еще, не требующего ЦП».
Я понял, что если процесс читает подкачку, он находится в непрерывном сне, но если он читает файл на внутреннем диске, в папке nfs или отсеке SAN, находится ли он в непрерывном сне? В документации Red Hat указана сеть, если процесс запрашивает ресурс в сети, находится ли он в непрерывном режиме сна?
На мой взгляд, "точность" - не самая лучшая вещь для достижения средней нагрузки. Это алгоритм, но несколько произвольно разработанная совокупность ощущений от медленной системы. Из sched / loadavg.c:
Этот файл содержит волшебные биты, необходимые для вычисления глобального показателя loadavg. Это глупое число, но люди считают его важным.
В частности, эта статья в Linux Journal немного вводит в заблуждение, говоря о средней нагрузке как о ЦПУ метрика нагрузки. Начиная с добавления TASK_UNINTERRUPTIBLE примерно в 1993 году, ЦП отключил такие состояния, как ввод-вывод или определенные блокировки. Что делает его скорее метрикой загрузки системы. (И это характерно для Linux.)
Сообщение Грегга, на которое вы ссылались, Средняя загрузка Linux: разгадка тайны не имел их полного списка, потому что
В настоящее время в Linux 4.12 существует около 400 кодовых путей, которые устанавливают TASK_UNINTERRUPTIBLE, включая некоторые примитивы блокировки.
Скорее, это полный список, который показывает, как измерить бесперебойность ядра с помощью графика пламени вне процессора. Это полезно для понимания того, почему средняя загрузка вашей рабочей нагрузки может быть высокой, даже если загрузка ЦП может быть низкой.
Хорошее время отклика приложения профилей мониторинга производительности для полного запроса.
Найдите какое-либо соотношение времени отклика со средней нагрузкой. Может случиться так, что нагрузка на систему с 4 ЦП является признаком снижения производительности вашей рабочей нагрузки. (Я придумал это число, посмотрите свои данные.)
При высокой загрузке убедитесь, что приложение медленно отвечает, а затем исследуйте все ресурсы системы, чтобы выяснить, почему.
1) Да: Tomcat использует поток для обработки запроса.
2) Да: Oracle JVM и OpenJDK JVM работают с собственными потоками только с JRE 1.3.
3) Да: очередь выполнения Linux содержит процессы и потоки (собственные потоки id) таким же образом
4) Да: средняя загрузка показывает среднее количество процессов / потоков в очереди выполнения.
5) Н / Д
6) Да: в Linux средняя загрузка подсчитывает процессы / потоки в состоянии выполнения, работоспособности и непрерывном спящем режиме.
7) Это нужно перефразировать. Кажется, вы знаете, как работает пространство подкачки. Итак, главный вопрос: нормальный ввод-вывод файлы обычно делается с помощью одного и того же механизма (не похожего - буквально одного и того же). Это называется mmap. Когда ваше приложение хочет записать в файл abc.txt он просто изменяет байты по заранее заданному адресу памяти. Страница памяти (4096 байт) помечена dirty. Вскоре фоновый демон записывает его в файловую систему (а не для подкачки пространства). И когда приложение просто открывает файл для чтения, оно получает адрес памяти без страницы памяти. Когда оно действительно обращается к памяти, ядро считывает страницы файла и заставляет их появиться там. Так работает общий дисковый кеш в Linux - это очень много страниц, не более того.
Сейчас сеть часть. В Linux есть несколько способов монтировать файловые системы, которые не находятся на локальных дисках SAS / SATA / FC, но фактически обмениваются данными по сети (например, NFS или CIFS). Так что листаем a.txt фактически заставляет пакеты летать по сети. В этом конкретном случае ваш процесс не имеет сокета, а только адрес в формате mmapped в собственном адресном пространстве. Все, что он делает, - перемещает байты между ячейками памяти.
Непрерывный сон определяется как ожидание этого механизма - независимо от того, смонтирована ли файловая система с диска или из сети. Допустим, мы читаем и ждем следующей страницы - процесс должен существовать и должен владеть памятью, потому что память должна быть готова принять байты, считываемые с диска (подумайте: DMA в процессе ). Вот почему это остается, несмотря на тебя kill -9 Это.
И нормальный сетевой трафик, выполняемый с сокетами, принадлежащими процессу, - это стандартный спящий режим, который не учитывается в средней нагрузке.
Процесс также мог читать диски "по-старому" без mmap, это тоже будет стандартный сон. Это довольно редко.