Pull to refresh

Comments 42

Беузмное упрощение. htop (как и любой top общего назначения) показывает состояние системы. Попытка описать в одной статье всё, что описывает htop, это всё равно, что пытаться в одной статье описать операционную систему.

На выходе статья полна ошибок и неточностей, местами «частная конфигурация» выдаётся за «оно так есть» (например, пароли в /etc/shadow — PAM для кого придумали?).
Да, упрощение. Но статья про то, как автор хотел выяснить то, что означают значения в одной утилите и разложить всё по полочкамм. Поэтому это скорее статья про то, как он это делал, что интересно почитать, на мой взгляд.

Нигде частная конфигурация не выдётся за правду. Тут расписан один конкретный случай с определённой операционной системой и следует это понимать.
Я же привёл пример. Человек утверждает, что пароли лежат в /etc/shadow. А если в /etc/pam.d/common-auth отсутсвует строчка «pam_unix.so», то не лежат. Парадокс? Интрига?
Опять же, автор рассматривает всё на примере установки одного чистого дистрибутива Linux. Не думаю, что упоминание всех возможных изменений и надстроек тут уместно. Взял один случай и разобрал его. В конце концов это же не мануал по Linux в целом, для этого существуют целые тома. Статья эта лишь описание его опыта, который для меня, например, оказался полезным.
UFO landed and left these words here
«Попробуйте запустить cat /dev/urandom > /dev/null,»

Вкусы автора очень специфичны ;)
Меня всегда интересовали цвета в графиках нагрузки ядра. help htop говорит, что красный цвет — это kernel. Но от этого не становится понятнее. К примеру эта нагрузка не влияет на load average. У меня периодически возникают ситуации, что ядра нагружены «красным» по 90% каждое, но load average — низкий.

Кто-то сталкивался с таким? И что это вообще значит? Заранее спасибо за ответ.
LA имеет такое-же отношение к загрузке отдельного ядра, как средняя температура в больнице к состоянию конкретного больного. LA отображает больше состояние очереди процессов, а не нагрузку, вот подробное описание для понимания
У меня периодически возникают ситуации, что ядра нагружены «красным» по 90% каждое, но load average — низкий.

Кто-то сталкивался с таким? И что это вообще значит?
Это значит что ядро сильно занято, а программы ресурсов процессора почти не используют. Ваш КО.

Простейший вариант — ваша программа аллоцировала 100GiB памяти и их все использует, а на машине всего парочка. В результате всё время уходит на то, чтобы закачивать/выкачивать страницы, а дело не движется.

Или, другая альтернатива — ваша программа отсылает куда-то гигибайты данных, но мало чего считает. Тогда ядро будет занято обслуживанием сетевой карты.

Да и вообще — мало ли чем занято ядро? Разбираться нужно…
а вот за наводку насчет сетевого интерфейса — спасибо! Как-то и в голову не приходило, но сервер как раз и работает как nfs-root через pxe для 150+ машин! Очень странно, что я просто не думал в сторону сети. Спасибо!

Попробуйте запустить perf top на сервере, он, обычно, помогает.

Kernel — значит режим ядра. Например когда приложение делает системные вызовы (open, read, write, ...), время, проведённое за их выполнением показывается как красный цвет полоски.


Много красного в многопроцессорной системе иногда может означать, что процессы конкурируют за доступ к какой-нибудь внутренней структуре ядра, проводя время в блокировках.


То, какие системные вызовы выполняет процесс, можно узнать, если установить курсор в htop на процесс и нажать "s" — htop запустит strace на него.


Другая полезная кнопка "l" показывает список файлов, открытых процессом.

Пример кода на си на попробовать, с большим количеством системных вызовов:


#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>

void main() {
        unsigned char data[100];

        while(1) {
                int fd = open("/etc/passwd", O_RDONLY);
                read(fd, data, 100);
                close(fd);
        }
}
за подсказки спасибо. Но повторюсь, все процессы по нулям, а красное бегает до 100%. Выше дали наводку на сеть и я думаю это верное направление.
Внезапно годнота. Спасибо за познавательный экскурс в повседневные мелочи! Продолжения стоит ли ждать?
У автора статьи есть небольшой TODO лист и он собирается обновлять её, как я полагаю.Соответствующие обновления я буду включать сюда. И разумеется, если у него появится новая хорошая статья, с радостью, переведу.
Вообще-то статья неплохо заинтересовывает вначале, но затем автор начинает скакать с одного на другого, с из /proc в /etc/shadow, и чтение перестает быть интересным, вдобавок там половина о том, как автор что-то нашел, а не как оно работает.

То, что автор статьи не удосуживается почитать стандартную документацию по тому же POSIX и начинает делать реверс инженеринг, вместо того чтобы написать man, при этом неподдельно удивляясь и радуясь выводам — начинает сильно раздражать примерно после 20% чтения, что столько времени тратится на уже давно протертое до дыр знание. Если бы не эти «удивления», читалось бы легче.

Тем не менее, спасибо за stacktrace -e

Не совсем понял фразу:


Если бы процессоров было 2, то загрузка соответственно была бы 50%, т.к. можно было бы одновременно выполнять 2 процесса. Максимальная средняя загрузка (100% использования CPU) системы с двумя процессорами составляет 2.00.

Ведь, например, если взять систему с двумя процессорами и запустить восемь задач, до LA будет приближаться к 8.


Для тех, кому интересно, вот так будут выглядеть три значения LA, если запустить на бездействующей системе один процесс, постоянно использующий CPU на полчаса, а потом его завершить.


График

image


Можно заметить, что ни один из графиков за пол часа так и не достиг единицы.


Моделирующий код
#!/usr/bin/env python

FIXED1 = 2048

EXP1 = 1884
EXP2 = 2014
EXP3 = 2037

def calc_load(load, exp, tasks):
    tasks <<= 11
    load *= exp
    load += tasks * (FIXED1 - exp)
    load >>= 11
    return load

load1 = 0
load2 = 0
load3 = 0

for i in range(720 + 1):
    secs = i * 5

    if i < 720 / 2:
        tasks_on_step = 1
    else:
        tasks_on_step = 0

    load1 = calc_load(load1, EXP1, tasks_on_step)
    load2 = calc_load(load2, EXP2, tasks_on_step)
    load3 = calc_load(load3, EXP3, tasks_on_step)

    print "%02d:%02d %.2f %.2f %.2f" % (secs // 60, secs % 60,
                                        round(float(load1) / 2048 * 100) / 100,
                                        round(float(load2) / 2048 * 100) / 100,
                                        round(float(load3) / 2048 * 100) / 100)
Ведь, например, если взять систему с двумя процессорами и запустить восемь задач, до LA будет приближаться к 8.
Скорее к 4, т.к. процессора 2, то нагрузка будет делиться пополам. Это означает что процессов в стеке процессора находится больше чем самих процессоров и загрузка соответственно больше 100%.

Спасибо за графики, наглядно иллюстрируют, что показатели экспоненциальны.

Но ведь в формуле вычисления LA не фигурирует число процессоров. Т.е. если запустить восемь задач на одноядерной и восьмиядерной машине, то LA будет расти примерно одинаково.


Это можно проверить командой:


for i in {0..7}; do perl -e 'while(1){}' & done
Да, простите, поторопился. Это нужно высчитывать самому. Т.е. нагрузка на один процессор (если задачи распределены поровну) будет составлять 4. Таким образом, нагрузка процессора (LA делённое на кол-во процессоров), не вызывающая перегрузку, должна быть меньше 1. Если больше, то будет означать, что задания находятся в очереди к процессору.
На самом деле LA ближе всего апроксимируется «сколько процессов не получило управление». соотвественно при одной и той же нагрузке на 1й системе будет 8, а на 4-х процессорной тоже действией выдаст чуть больше 5. Насколько больше — зависит от других факторов типа дисковой подсистемы и сети.

Согласен, в реальной жизни, скорее всего так и будет. т.к. многим реальным программам нужно какое-то ограниченное количество CPU в единицу времени. Например, серверу, чтобы обработать очередной запрос от клиента.


Если жё программе нужен CPU на всё время её работы, например вычислительным программам, то тогда LA будет расти примерно одинаково (см. предыдущий пример).

Нет, не одинаково. У вас количество потоков же возрастет. Так как вы говорите будет, если у вас эта одна программа требует 100 потоков и находится в экслюзивном реалтайм режиме. Это уже не обычное ядро.

Ещё один неясный момент:


Этот же сигнал посылается, если нажать комбинацию CTRL+C. bash пошлёт сигнал SIGINT процессу в фоне точно так же как мы это сделали вручную.

Во-первых, скорее всего, имелся в виду не фоновый процесс, а, наоборот, процесс находящийся на переднем плане.


Во-вторых, ctrl-c и kill работают чуть по-разному: ctrl-c посылает сигнал не процессу, а группе процессов (которая может состоять и из одного процесса), а kill — только одному процессу.


Разницу можно понять, запустив такую программу:


#include <stdio.h>
#include <unistd.h>
#include <signal.h>

void sighandler(int signum) {
   printf("Got CTRL-C\n");
}

int main() {
   signal(SIGINT, sighandler);
   fork();
   fork();

   while(1) {
         sleep(1);
   }
}

и нажав ctrl-c внутри неё. Увидим 4 строки ctrl-c. А послав сигнал, увидим только одну строку.


Чтобы kill работал похоже на ctrl-c нужно указывать отрицательный PID, например kill -SIGINT -31846.

Спасибо, очень полезное замечание. И да, имелся ввиду процесс на переднем плане, конечно же.
Если запускать программу в фоновом режиме (&) из bash, то PID выводится в квадратных скобках.

$ sleep 1000 &
[1] 12503


В квадратных скобках — номер задачи, и задачи (jobs) это не PID.
В GUI это называется фокусом, когда мы перемещаем фокус между foreground и background приложениями.
В консоли управление фоновыми и приоритетными задачами выполняются при помощи &, bg, fg, jobs
Про LA, как обычно, автор напутал.

Для тех же, кто часто пишет в консоли конструкции вида
 2>&1
дарю:
|&
и
>&
.

Пользоваться примерно вот так:
ffprobe http://video.hostring/some.file |& grep -i video

bash(1) рекомендует &> вместо >&, хотя никакой разницы между ними нет.

LA — это не то, сколько задач реально исполнялось, а сколько задач хотели быть исполнеными. И он, конечно же, не ограничен количеством ядер на машине. LA в 5000 — далеко не рекорд ) Это в пике, конечно, но всё равно, подобные числа видел.
Число загрузки считается как сумма количества процессов, которые запущены (выполняются или находятся в ожидании запуска) и непрерываемых процессов
это думаю и есть «сколько задач хотели быть исполнеными»

И в статье не говорится. что оно ограничено количеством процессов. Автор указал, что это не совсем правильно, но так легче ему понять, что при 100% загрузки, это число должно быть равно кол-ву процессов. Но загрузка может быть и больше 100%, и это уже сверхнагрузка.

Как правило, есть 2 выхода из данной ситуации:
  • echo "$USER ALL=(ALL) NOPASSWD: ALL" | sudo tee -a /etc/sudoers
  • sudo bash -c "echo '$USER ALL=(ALL) NOPASSWD: ALL' >> /etc/sudoers"

Плохой пример. Утилита visudo появилась не просто так.


Хотя можно придумать и хуже. Например, редактировать так файлики в /etc/pam.d, желательно по ssh и без ipkvm, чтоб жизнь мёдом не казалась (после неудачной правки).

… и не забывать после каждой правки перелогиниться.

Текущая сессия таким образом прерываеться?

Нет, pam уже пройден, но никто не гарантирует, что ssh не отвалится в самый неподходящий момент.

Это был риторический вопрос. В семействах подобных ос(да и не только в них) вообще никто ничего не гарантирует и все действия нужно производить продумано и понимать, что делаешь
htop ещё содержит большое количество опциональных колонок, которые по умолчанию не показываются. Я вот первым делом включаю IO Rate — интересно знать, кто шуршит винтом.
Когда процесс заканчивает свою работу с помощью exit и у неё остаются дочерние процессы, дочерние процессы становятся в состоянии зомби.


И сформулировано странно, и вообще не правильное определение.
В проекте FrreeBSD есть замечательная вещь, называется Руководство (HandBook) — https://www.freebsd.org/doc/ru_RU.KOI8-R/books/handbook/. К сожалению (в данном конкретном случае, а вообще — конечно, к счастью), я начинал свой unix-way именно во фре, и не знаю Linux-альтернативу данной книги, но думаю, что она наверняка есть. Так вот в ней раскрывается 95% материала, указанного в статье. Причем подход в Руководстве на порядок более серьезный. Это базовая книга для понимания того, как работает Unix вообще и FreeBSD в частности. ИМХО, активно эксплуатировать *nix-like ОС можно только имея преставление о внутреннем устройстве.
Соотношение любезности и приоритета следующее: PR = 20 + NI.

Видимо должно быть 120

Only those users with full accounts are able to leave comments. Log in, please.