Dive in performance tools. Часть 2️⃣ [top / htop]

2️⃣.3️⃣ Таблица процессов в top

Ниже разберём, что означают поля PR, NI, VIRT, RES, SHR в выводе top (или похожих утилит):

1. PR (Priority) – приоритет, с которым планировщик ядра запускает процесс. В Linux приоритет обычно отображается целым числом, где более высокое число означает более низкий приоритет (несмотря на кажущуюся «логичность» наоборот). Значения PR могут меняться динамически ядром, исходя из нагрузки и «nice»-приоритета процесса.

2. NI (Nice) – «nice»-значение процесса, задающее его базовый приоритет. Диапазон nice: от -20 (самый высокий приоритет) до +19 (низкий приоритет). По умолчанию процессы запускаются с nice = 0. Если запустить процесс с nice -n 10 COMMAND, то процесс получит NI = 10, то есть будет иметь более низкий приоритет при распределении CPU.

3. VIRT (Virtual Memory) – объём виртуального адресного пространства, зарезервированного или видимого для процесса. Большой VIRT не обязательно означает, что процесс реально занимает столько физической памяти; часть из этого может никогда не загружаться в оперативную память (RAM).

4. RES (Resident Memory) – резидентная (фактически используемая) память в физической оперативной памяти (RAM). Это объём памяти, действительно загруженный в ОЗУ для данного процесса. Если часть процесса или библиотеки выгружена в swap (или ещё не загружена), она не считается в RES.

5. SHR (Shared Memory) – объём разделяемой памяти, используемой процессом. Обычно это доля памяти, которую процесс использует вместе с другими (например, разделяемые библиотеки, общие сегменты). Если два процесса используют одну и ту же библиотеку, её часть может отображаться в SHR у обоих, но в действительности она хранится в памяти единоразово.

Таким образом:

- PR и NI определяют, с каким приоритетом планировщик будет выделять CPU для процесса.
- VIRT говорит, сколько адресного пространства потенциально доступно процессу.
- RES показывает, сколько физической памяти реально выделено ему в данный момент.
- SHR указывает, какую часть этой резидентной памяти (RES) процесс делит с другими.

Теперь разберем практический пример. Здесь мы видим группу процессов Redis под пользователем с UID 999, а также системные процессы (root). Пример строк с Redis:

PID      USER  PR NI    VIRT    RES   SHR  %CPU %MEM    TIME+      COMMAND
110005   999   20  0 8182684 3.2g  1524  36.5 10.8   0:14.70   redis-server
110045   999   20  0 8182684 1.1g  1532  28.2  3.6   1:10.86   redis-server
109437   999   20  0 8182292 3.2g  1744   9.6 12.9 111:19.74   redis-server
... и т.д.

- VIRT ~8.1 ГБ Это виртуальное адресное пространство (не значит, что все 8 ГБ реально заняты). В данном случае для Redis нормально поднимать большие VIRT, особенно если включены RDB/AOF-снапшоты.

- RES (фактическая резидентная память): мы видим 3.2G, 1.1G, 3.8G и т. д. У нескольких процессов Redis довольно большие значения. Суммарно они занимают значительную часть из 30 ГБ ОЗУ.

- %CPU по Redis варьируется от 9.3% до ~36%. Если сложить все Redis-процессы, получится внушительный процент — но поскольку система многопроцессорная, это ещё не обязательно «упор» в один CPU.

Продолжение следует… ⬇️

Dive in performance tools. Часть 2️⃣ [top / htop]

2️⃣.4️⃣ Основные выводы в практическом примере

1. Высокий iowait (26.3% wa). Процессор «ждёт» операций ввода-вывода, что может указывать на интенсивные записи/чтения (например, Redis, сбрасывающий данные на диск). Для дальнейшей диагностики можно использовать утилиты вроде iotop, iostat, dstat, чтобы выявить «виновника» I/O. О них мы поговорим в следующих сериях.

2. Память (buff/cache). ~8.9 ГБ в кэше и буферах — это нормально: ядро старается использовать RAM по максимуму, чтобы ускорять операции. При необходимости эта память освобождается, так что free может быть небольшим, но available (9.4 ГБ) ещё даёт большой запас.

3. Нагрузка на CPU (us, sy, si). Суммарный пользовательский и системный процент невысок (около 13%), однако iowait делает общую картину менее радужной. Нужно следить за si (softirq), если оно продолжит расти, возможно, идёт большой сетевой трафик или нуждаются в настройке сетевые стеки.

4. Load average ~6. На сервере с 8 ядрами это не критично, но при дальнейших пиках нагрузка может дойти до очередей на выполнение задач. Необходимо мониторить в динамике - нет ли дальнейшего роста или все подконтролем.


2️⃣.5️⃣. Что еще можно посмотреть в top

Надо сказать, что вы можете настраивать список столбцов и отображать много других метрик, например:

- SWAP: объём свопа, используемый процессом.
- ENV: перменные окружения которые видит процесс.
- CODE, DATA: размер сегментов кода и данных в памяти.
- MajF, MinF: количество «major» и «minor» ошибок страницы (page faults).
- VolCxt, NonVolCxt: количество переключений контекста (voluntary/involuntary).
- P, CPU: на каком процессоре (или ядре) выполняется процесс.
- Threads: общее число потоков, запущенных процессом.
- И т. д.

Чтобы выбрать и упорядочить столбцы в интерактивном режиме можно нажать F и выбрать интересующую метрику.

И на этом у меня все, всем спасибо и хорошего дня 🦾️️️️️️ Дальше мы будем разбираться с другими тулами

Почитать на habr: https://habr.com/ru/articles/876428/

Бонус: для обучения сделал https://top.tools.devopsbrain.ru

🆕 Вредные советы начинающим специалистам в IT

Идея написать вредные советы у меня давно витала в голове. Если вы опытный специалист, то я надеюсь вам понравится и вы вспомните где то себя. А если вы как раз в начале карьеры, я надеюсь вы сделаете выводы.

0️⃣1️⃣ Не читай документацию. Она только путает и отвлекает от настоящей работы — гугли ответы на форумах и копируй чужие решения с StackOverflow или GPT.

0️⃣2️⃣ Никогда не проси помощи у коллег. Покажи всем, что ты «волк-одиночка» и можешь сам во всем разобраться, даже если это будет стоить бизнесу денег.

0️⃣3️⃣ Постоянно проси помощи у коллег. Это же в их интересах, чтобы ты сделал задачу побыстрее, поэтому постоянно проси помощи. К тому же, коллегам это очень нравится - они так чувствуют, что они важны в компании. Поверь, они очень любят помогать.

0️⃣4️⃣ Специально переусложняй реализацию. Чем запутаннее твое решение, тем более высоко смогут оценить тебя коллеги. Ведь это покажет, что ты можешь реализовать “сложные” решения.

0️⃣5️⃣ Комментарии и осмысленные названия переменных не нужны. Тут итак все понятно, зачем тратить время на какую то ерунду. К тому же, тимлид и коллеги явно поопытнее и уж точно разберутся.

0️⃣6️⃣ Не трать время на тестирование своего решения. Вообще пусть тестирует тот кто поставил тебе задачу, это же им надо.

0️⃣7️⃣ Не используй системы контроля версий. Зачем усложнять себе жизнь Git? Просто сохраняй файлы с названиями project_final_v6_final2 (FINAL).zip. Просто потом их в чат можно скинуть автору задачи, он там сам разберется уже. Зато ничего лишнего не будет в архиве.

0️⃣8️⃣ Сразу делай в production окружении. Тестовые и локальные окружения только трата времени. Зачем что-то проверять локально, если можно сделать в проде тем самым быстро пофиксить проблему. Коллеги оценят твою скорость и может даже премию дадут.

0️⃣9️⃣ Забудь про резервное копирование. Бэкапы — удел тех, кто не уверен в том что делает. Но ты то совершенно точно все делаешь правильно.

1️⃣0️⃣ Пароли храни в текстовом файле. Парольные менеджеры это переусложнение на ровном месте. У тебя же стоит антивирус и ты не ставишь программы с левых сайтов. Так что тебя точно никто и никогда не взломает и вирус ты никакой не поймаешь. А в файле все удобно, все под рукой

1️⃣1️⃣ Игнорируй обратную связь. Да что они вообще понимают? Ты итак потратил целых 2 недели на решение, а им еще что-то не нравится. Пусть сами тогда делают. Так и скажи руководителю. Скорее всего тебе пойдут на встречу и доделывать будет уже кто то другой.

1️⃣2️⃣ Тратить время на свое обучение больше не нужно. Ты ведь уже итак специалист: закончил курсы, посмотрел пару уроков на YouTube, почитал несколько статей — достаточно. Все остальное на практике доберешь. Лучше все изучать сразу на практике без нудной теории. Вот когда коснется чего то, тогда и изучишь.

1️⃣3️⃣ Любые знания, не относящиеся к твоей текущей задаче, бесполезны. Мир меняется очень медленно, чтобы тратить время на расширение кругозора и знаний. Если надо будет что то изучить новое — твой руководитель сразу к тебе придет и скажет. Тогда и поизучаешь.

1️⃣4️⃣ Забудь о документировании кода и проектов. Всё держи в голове. Документацию придумали те, кому лень разбираться в чем то. Хороший специалист разберется и так в том, что ты написал.

1️⃣5️⃣ Не контролируй сроки. Можно не париться на счет сроков. Пусть повисит в in progress несколько недель без движения — никто не заметит. К тому же когда ты ее закроешь, руководство увидит сколько времени потрачено и поймет, что это сложная задача.

1️⃣6️⃣ Никому не говори, если где то увидел проблему в проекте. Поверь, не надо подсвечивать ни свои, ни чужие косяки. Во-первых, вдруг "это не баг" и тогда тебя просто выставят дураком. Во-вторых, могут заставить фиксить.

1️⃣7️⃣ И самое главное — скрывай, если накосячил. Никогда, никому не сообщай, что где то серьезно продолбался. Ведь ты явно потеряешь репутацию или (что еще хуже) за это могут сразу уволить. А это явно не входит в твои планы, тем более это может серьезно помешать тебе стать успешным ойтипшником.

https://habr.com/ru/articles/875152/

Бесконечно можно смотреть на 3 вещи: огонь, воду и симулятор kafka от softwaremill

🔗 https://softwaremill.com/kafka-visualisation.

Очень классная визуализация, которая позволяет понять принципы работы и покрутить разные ручки для разных сценариев 🔥

#kafka #simulators

Dive in performance tools. Часть 3️⃣ [bmon / bandwhich / iptraf / iperf]

Продолжим разбирать утилиты, помогающие в диагностике проблем с производительностью. Сегодня коснемся сетей. Но я сразу хочу проговорить пару моментов:

1. Разобрать детально все возможные проблемы с сетью, которые могут повлиять на производительность, в рамках одной данной серии постов нереально. Поэтому остановимся на тулах с прямым уклоном в определении что, куда и зачем утилизирует сеть.
2. Помимо перечисленных ниже тулзов существует огромное множество альтернатив. Я же хочу остановиться на тех, которые мне кажутся наиболее полезными и имеют вменяемый TUI.
3. Я не буду описывать способы установки тулзов под каждый дистрибутив, а остановлюсь на демонстрации основных возможностей. Установку гуглится за пару секунд — не будем тратить на это время.
4. Чтобы не спамить в канал буду выкладывать каждый день по 1 туле из списка.

3️⃣.1️⃣ bmon

https://github.com/tgraf/bmon — утилита для мониторинга сетевого трафика в реальном времени. Она показывает скорость передачи данных, ошибки, потери пакетов и общую статистику по интерфейсам.

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

Давайте посмотрим данные, на которые стоит обратить внимание.

▶️ Bytes — Показывает объем входящего и исходящего трафика в байтах.
▶️ Abort Error — Ошибки разрыва соединения между источником и получателем пакета.
▶️ Carrier Errors — Ошибки связи между устройствами, возникающие из-за несоответствия дуплекса или проблем с сигналом.
▶️ Collisions — Количество коллизий (конфликтов) при передаче данных между устройствами.
▶️ CRC Errors — Ошибки контрольной суммы (Cyclic Redundancy Check, CRC), возникающие из-за поврежденных пакетов.
▶️ Dropped — Количество пакетов, которые были отброшены из-за проблем с доставкой (например, перегрузка сети).
▶️ Errors — Общее количество ошибок в сети.
▶️ FIFO Errors — Ошибки очереди FIFO (First In, First Out) — возникают, когда сетевой интерфейс не успевает передавать данные и буфер заполняется.
▶️ Frame Error — Ошибки фрейма — поврежденные пакеты, вызванные сбоями в передаче данных.
▶️ Heartbeat Errors — Количество потерянных сигналов (heartbeat) между оборудованием или программными модулями, что может привести к проблемам синхронизации.
▶️ Length Error — Ошибки длины пакетов - когда длина в заголовке меньше минимально возможного размера.
▶️ Missed Error — Количество пакетов, пропущенных при передаче (обычно пакеты нумеруются для их восстановления).
▶️ No Handler — Количество пакетов, для которых не найден обработчик протокола.
▶️ Over Errors — Ошибки переполнения - когда буфер приема был переполнен или пакеты превышали максимальную длину фрейма.
▶️ Window Error — Количество пакетов, в которых размер окна (число октетов в заголовке) оказался некорректным и не может быть обработан.


💭 Анализ вывода bmon на примере из скриншота

В данном случае разберем конкретный сетевой интерфейс. На графике показано мы видим ходящий трафик (RX): примерно 780 KiBps. Исходящий трафик (TX): 3.76 MiBps. Вывод: сервер больше отправляет данных, чем получает. Это характерно для сервера - тут вопросов нет.

Явные проблемы:

- 18K потерянных пакетов (RX) — возможно, перегрузка интерфейса или дроп пакетов из-за политики очередей (QoS).
- 7.82K ошибок приема — проблемы могут быть на уровне сетевого оборудования или драйвера.

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

А на этом у меня все, а в следущих постах мы с вами детально разберем bandwhich, iptraf и iperf...stay tuned ⬇️

Dive in performance tools. Часть 3️⃣.2️⃣ [bandwhich]

Мы уже познакомились с bmon тут https://t.me/devopsbrain/123. Сегодня максимально коротко - хочу познакомить с bandwhich.

bandwhich - это консольная тулза для отображения текущего использования сети по процессам, соединениям и удалённым IP-адресам.

Киллер-фича данной тулы в том, что она показывает суммарную утилизацию по remote IP-адресам (Панель utilization by remote address вверху справа). Есть много тузов которые показывают текущее состояние в разрезе процессов или установленных соединений, протоколов и портов - bandwhich же группирует по ip адресам. Это бывает очень полезно, если вы не хотите видеть шум а картину в целом, но с группировкой по IP-адресу.

Также интересно бывает посмотреть утилизацию сети в разрезе на каждое соединение, чтобы определить потенциальный источник проблемы как в целом системы, bandwhich также позволит это сделать.