po ndjek pohimet në lidhje me ngarkesën linux dhe tomcat apo jo?
Unë po kërkoj të kuptoj saktësisht se si të përdorim mesataren e ngarkesës dhe përdorimin e CPU në një makinë me kapelë të Kuqe që pret vetëm një Tomcat 8. Pasi pashë në rrjetë, përfundova pohimet e mëposhtme. A janë pohimet e duhura? Jam thellësisht i sigurt për të parin pasi vjen nga dokumentacioni zyrtar i Tomcat. Dhe jam i hutuar se cilat procese mund të jenë në gjumë të pandërprerë.
1) Tomcat përdor një fije për të përpunuar një kërkesë, numri maksimal i fijeve të përdorura përcaktohet nga konfigurimi i Tomcat (shih Dokumentacioni i Tomcat )
2) Oracle JVM punon me fije vendase vetëm që nga JRE 1.3 (Shih JVM dhe fije Unë nuk gjeta një referencë Oracle për këtë pikë)
3) Radha e ekzekutimit të Linux përmban procese dhe fije (id fijet vendase) në të njëjtën mënyrë (Shih Mesataret e Ngarkesës Linux: Zgjidhja e Misterit dhe Wikipedia ]
4) Mesatarja e ngarkesës siguron numrin mesatar të procesit / fijeve në radhë të vrapimit ( Shikoni Linux Journal )
5) Në një makinë Linux që drejton vetëm një Tomcat, mesatarja e ngarkesës siguron pothuajse numrin mesatar të kërkesave.
6) Në Linux procesi / fijet e llogaritjes së mesatares së ngarkesës në gjendje të ekzekutuar, të ekzekutueshme dhe të pandërprerë (Shih Linux Journal ]
7) Procesi / fijet në gjumë të pandërprerë po presin për disqet / O, brava pa ndërprerje, rrjeti I / O (Shih Redhat documenationt që përfshin rrjetin I / O dhe Mesataret e Ngarkesës Linux: Zgjidhja e Misterit që nuk përfshin rrjetin I / 0)
Pika 7 nuk është koherente me referencën Shih Linux Journal që thotë se "Në fakt, është saktësisht ngarkesa e CPU-së që matet, sepse mesataret e ngarkesës nuk përfshijnë ndonjë proces ose fije që pret Unë / O, rrjetëzim, baza të dhënash ose ndonjë gjë tjetër që nuk kërkon CPU. ".
Kam kuptuar që nëse një proces lexon swap është në gjumë të pandërprerë, por nëse lexon një skedar në disk të brendshëm, dosje nfs ose një gji SAN, a është në gjumë të pandërprerë? Rrjeti i listuar i dokumentacionit të kapelave të kuqe, nëse një proces kërkon një burim në rrjet, a është në gjumë të pandërprerë?
1) Да: Tomcat использует поток для обработки запроса.
2) Да: Oracle JVM и OpenJDK JVM работают с собственными потоками только с JRE 1.3
3) Да: Очередь выполнения Linux содержит процессы и потоки (собственные потоки id) таким же образом
4) Да: средняя загрузка показывает среднее количество процессов / потоков в очереди выполнения
5) Н / Д
6) Да : В Linux средняя загрузка подсчитывает процессы / потоки в состоянии выполнения, работоспособности и непрерывном режиме сна
7) Это требует перефразирования. Вы, кажется, знаете, как работает область подкачки. Итак, главный момент: ввод-вывод в обычные файлы обычно выполняется с помощью одного и того же механизма (не похожего - буквально одного и того же). Это называется mmap . Когда ваше приложение хочет записать в файл abc.txt , оно просто изменяет байты по заранее заданному адресу памяти. Страница памяти (4096 байт) помечена грязной . Вскоре фоновый демон записывает его в файловую систему (а не для подкачки пространства). И когда приложение просто открывает файл для чтения, оно получает адрес памяти без страницы памяти. Когда оно действительно обращается к памяти, ядро считывает страницы файла и заставляет их появиться там. Вот как работает общий дисковый кеш в Linux - это очень много страниц, не более того.
Теперь о сети . В Linux есть несколько способов монтирования файловых систем, которые не находятся на локальных дисках SAS / SATA / FC, но фактически обмениваются данными по сети (например, NFS или CIFS). Таким образом, пейджинг a.txt фактически заставляет пакеты летать по сети. В этом конкретном случае ваш процесс не имеет сокета, а только адрес в формате mmapped в собственном адресном пространстве. Все, что он делает, - перемещает байты между ячейками памяти.
Непрерывный сон определяется как ожидание этого механизма - независимо от того, смонтирована ли файловая система с диска или из сети. Допустим, мы читаем и ждем следующей страницы - процесс должен существовать и должен владеть памятью, потому что память должна быть готова принять байты, считываемые с диска (подумайте: DMA в процессе ). Вот почему он остается, несмотря на то, что вы kill -9 it.
И нормальный сетевой трафик, выполняемый с сокетами, принадлежащими процессу, - это стандартный спящий режим, он не учитывается при средней нагрузке.
A процесс также мог читать диски "по-старому" без mmap , это также был бы стандартный спящий режим. Это довольно редко.
На мой взгляд, "точная" не очень полезная вещь для достижения средней нагрузки. Это алгоритм,но несколько произвольно развитая совокупность ощущений медленной системы. Из sched / loadavg.c :
Этот файл содержит волшебные биты, необходимые для вычисления глобального loadavg рисунок. Глупое число, но люди думают, что это
В частности, эта статья в Linux Journal немного вводит в заблуждение, говоря о средней нагрузке как о метрике нагрузки CPU . Начиная с добавления TASK_UNINTERRUPTIBLE примерно в 1993 году, ЦП отключил такие состояния, как ввод-вывод или определенные блокировки. Что делает его скорее метрикой загрузки системы. (И это относится к Linux.)
Сообщение Грегга, на которое вы ссылались, Средние значения нагрузки Linux: разгадывая загадку не содержало их полного списка, потому что
В настоящее время в Linux 4.12 есть почти 400 кодовых путей, которые устанавливают TASK_UNINTERRUPTIBLE, включая некоторые примитивы блокировки.
Скорее, это полный список, который показывает, как измерить бесперебойность ядра с помощью графика пламени вне процессора. Это полезно для понимания того, почему средняя загрузка вашей рабочей нагрузки может быть высокой, даже если загрузка ЦП может быть низкой.
Хорошее время отклика приложения профилей мониторинга производительности для полного запроса.
Найдите корреляцию времени отклика со средней нагрузкой. Может случиться так, что нагрузка на систему с 4 ЦП является признаком снижения производительности вашей рабочей нагрузки. (Я придумал это число, посмотрите на ваши данные.)
Когда нагрузка высока, убедитесь, что приложение медленно отвечает, затем исследуйте каждый ресурс системы, чтобы выяснить, почему.