Я недавно рассказывал про namespaces в Linux. На основе этой изоляции работает множество софта. Далее будет пример одного из них, который использует network namespaces для записи дампа трафика конкретного приложения.
Речь пойдёт про nsntrace. Это относительно простое приложение, которое, как я уже сказал, может собрать дамп трафика отдельного приложения. Для этого оно делает следующие вещи:
1️⃣ Создаёт отдельный network namespace для исследуемого приложения.
2️⃣ Для того, чтобы там был доступ в интернет, создаются виртуальные сетевые интерфейсы. Один в новом namespace, другой в основном. В новом используется шлюз из основного namespace. Из-за этой схемы у запускаемого приложения будет IP адрес виртуальной сети.
3️⃣ Средствами iptables трафик натится из виртуальной сети в реальную.
4️⃣ Запускает приложение в новом namespace и собирает его трафик с помощью libpcap. Результат сохраняет в обычный pcap файл.
Nsntrace есть в базовых репах Debian:
Самый банальный пример, чтобы проверить работу:
На выходе получаем nsntrace.pcap, который можно посмотреть тут же, если у вас есть tshark:
Можно и в режиме реального времени наблюдать:
Помимо обычных приложений, снимать трафик можно и со скриптов:
Проверим на простом python скрипте:
Запускаем анализ сетевой активности:
Смотрим:
Можно передать .pcap на другую машину и посмотреть в Wireshark.
Удобный инструмент. Нужен не часто, но конкретно для скриптов мне реализация понравилась. Обычно это нетривиальная задача, посмотреть, куда он стучится и что делает. Нужно вычленять именно его запросы из общего трафика, а это не всегда просто. Либо трассировку работы делать, что тоже сложнее, чем просто воспользоваться nsntrace.
#network #perfomance
Речь пойдёт про nsntrace. Это относительно простое приложение, которое, как я уже сказал, может собрать дамп трафика отдельного приложения. Для этого оно делает следующие вещи:
1️⃣ Создаёт отдельный network namespace для исследуемого приложения.
2️⃣ Для того, чтобы там был доступ в интернет, создаются виртуальные сетевые интерфейсы. Один в новом namespace, другой в основном. В новом используется шлюз из основного namespace. Из-за этой схемы у запускаемого приложения будет IP адрес виртуальной сети.
3️⃣ Средствами iptables трафик натится из виртуальной сети в реальную.
4️⃣ Запускает приложение в новом namespace и собирает его трафик с помощью libpcap. Результат сохраняет в обычный pcap файл.
Nsntrace есть в базовых репах Debian:
# apt install nsntraceСамый банальный пример, чтобы проверить работу:
# nsntrace wget google.comНа выходе получаем nsntrace.pcap, который можно посмотреть тут же, если у вас есть tshark:
# tshark -r nsntrace.pcapМожно и в режиме реального времени наблюдать:
# nsntrace -o - wget google.com 2> /dev/null | tshark -r -Помимо обычных приложений, снимать трафик можно и со скриптов:
# nsntrace php script.php# nsntrace python script.pyПроверим на простом python скрипте:
import requestsres = requests.get('https://ya.ru')Запускаем анализ сетевой активности:
# nsntrace python3 script.pyStarting network trace of 'python3' on interface eth0.Your IP address in this trace is 172.16.42.255.Use ctrl-c to end at any time.Finished capturing 57 packets.Смотрим:
# tshark -r nsntrace.pcapМожно передать .pcap на другую машину и посмотреть в Wireshark.
Удобный инструмент. Нужен не часто, но конкретно для скриптов мне реализация понравилась. Обычно это нетривиальная задача, посмотреть, куда он стучится и что делает. Нужно вычленять именно его запросы из общего трафика, а это не всегда просто. Либо трассировку работы делать, что тоже сложнее, чем просто воспользоваться nsntrace.
#network #perfomance
👍115👎2
В Linux есть простой и удобный инструмент для просмотра дисковой активности в режиме реального времени - iotop. У него формат вывода похож на традиционный top, только вся информация в выводе посвящена дисковой активности процессов.
В последнее время стал замечать, что в основном везде используется iotop-c. Это тот же iotop, только переписанный на C. Новая реализация поддерживается и понемногу развивается, в то время, как оригинальный iotop не развивается очень давно.
В каких-то дистрибутивах остались обе эти утилиты, а в каких-то iotop полностью заметили на iotop-c. Например, в Debian остались обе:
А в Fedora iotop полностью заменили на iotop-c, с сохранением старого названия.
Так что если захотите воспользоваться iotop, чтобы отследить дисковую активность отдельных процессов, то ставьте на всякий случай сразу iotop-c. Программа простая и удобная. Запустили, отсортировали по нужному столбцу (стрелками влево или вправо) и смотрим активность. Обычно в первую очередь запись интересует.
Напомню, что у меня есть небольшая заметка про комплексный анализ дисковой активности в Linux с помощью различных консольных утилит.
#perfomance
В последнее время стал замечать, что в основном везде используется iotop-c. Это тот же iotop, только переписанный на C. Новая реализация поддерживается и понемногу развивается, в то время, как оригинальный iotop не развивается очень давно.
В каких-то дистрибутивах остались обе эти утилиты, а в каких-то iotop полностью заметили на iotop-c. Например, в Debian остались обе:
# apt search iotopiotop/stable 0.6-42-ga14256a-0.1+b2 amd64 simple top-like I/O monitoriotop-c/stable,now 1.23-1+deb12u1 amd64 [installed] simple top-like I/O monitor (implemented in C)А в Fedora iotop полностью заменили на iotop-c, с сохранением старого названия.
Так что если захотите воспользоваться iotop, чтобы отследить дисковую активность отдельных процессов, то ставьте на всякий случай сразу iotop-c. Программа простая и удобная. Запустили, отсортировали по нужному столбцу (стрелками влево или вправо) и смотрим активность. Обычно в первую очередь запись интересует.
Напомню, что у меня есть небольшая заметка про комплексный анализ дисковой активности в Linux с помощью различных консольных утилит.
#perfomance
👍94👎1
Вчера в заметке я немного рассказал про планировщики процессов для блочных устройств в Linux и чуток ошибся. Тема новая и непростая, особо не погружался в неё, поэтому не совсем правильно понял. Немного больше её изучил, поэтому своими словами дам краткую выжимку того, что я по ней понял и узнал.
Наиболее актуальны сейчас следующие планировщики:
🔹mq-deadline - по умолчанию отдаёт приоритет запросам на чтение.
🔹kyber - более продвинутый вариант deadline, написанный под самые современные быстрые устройства, даёт ещё меньшую задержку на чтение, чем deadline.
🔹CFQ и BFQ - второй является усовершенствованной версией первого. Формируют очередь запросов по процессам и приоритетам. Дают возможность объединять запросы в классы, назначать приоритеты.
🔹none или noop - отсутствие какого-либо алгоритма обработки запросов, простая FIFO-очередь.
В современных системах на базе ядра Linux планировщик может выбираться автоматически в зависимости от используемых дисков. Разные дистрибутивы могут использовать разные подходы к выбору. Посмотреть текущий планировщик можно так:
Тут я вчера ошибся. Не понял, что в данном случае используется планировщик none. То, что выделено в квадратных скобках - используемый планировщик. Вот ещё пример:
Тут выбран планировщик mq-deadline. Поддержка планировщика реализована через модули ядра. Если вы хотите добавить отсутствующий планировщик, то загрузите соответствующий модуль.
Загрузили модуль kyber-iosched и активировали этот планировщик. Действовать это изменение будет до перезагрузки системы. Для постоянной работы нужно добавить загрузку этого модуля ядра. Добавьте в файл
А для применения планировщика создайте правило udev, например в отдельном файле
В виртуальных машинах чаще всего по умолчанию выставляется планировщик none и в общем случае это оправдано, так как реальной записью на диск управляет гипервизор, а если есть рейд контроллер, то он. К примеру, в Proxmox на диски автоматически устанавливается планировщик mq-deadline. По крайней мере у меня это так. Проверил на нескольких серверах. А вот в виртуалках с Debian 12 на нём автоматически устанавливается none. Хостеры на своих виртуальных машинах могут автоматически выставлять разные планировщики. Мне встретились none и mq-deadline. Другие не видел.
Теперь что всё это значит на практике. Оценить влияние различных планировщиков очень трудно, так как нужно чётко эмулировать рабочую нагрузку и делать замеры. Если вам нужно настроить приоритизацию, то выбор планировщика в сторону BFQ будет оправдан. Особенно если у вас какой-то проект или сетевой диск с кучей файлов, с которыми постоянно работают, а вам нужно часто снимать с него бэкапы или выполнять какие-либо ещё фоновые действия. Тогда будет удобно настроить минимальный приоритет для фоновых процессов, чтобы они не мешали основной нагрузке.
Если у вас быстрые современные диски, вам нужен приоритет и минимальный отклик для операций чтения, то имеет смысл использовать kyber. Если у вас обычный сервер общего назначения на обычный средних SSD дисках, то можно смело ставить none и не париться.
Некоторые полезные объёмные материалы, которые изучил:
🔥https://selectel.ru/blog/blk-mq-tests/ (много тестов)
⇨ https://habr.com/ru/articles/337102/
⇨ https://redos.red-soft.ru/base/arm/base-arm-hardware/disks/using-ssd/io-scheduler/
⇨ https://timeweb.cloud/blog/blk-mq-i-planirovschiki-vvoda-vyvoda
#linux #kernel #perfomance
Наиболее актуальны сейчас следующие планировщики:
🔹mq-deadline - по умолчанию отдаёт приоритет запросам на чтение.
🔹kyber - более продвинутый вариант deadline, написанный под самые современные быстрые устройства, даёт ещё меньшую задержку на чтение, чем deadline.
🔹CFQ и BFQ - второй является усовершенствованной версией первого. Формируют очередь запросов по процессам и приоритетам. Дают возможность объединять запросы в классы, назначать приоритеты.
🔹none или noop - отсутствие какого-либо алгоритма обработки запросов, простая FIFO-очередь.
В современных системах на базе ядра Linux планировщик может выбираться автоматически в зависимости от используемых дисков. Разные дистрибутивы могут использовать разные подходы к выбору. Посмотреть текущий планировщик можно так:
# cat /sys/block/sda/queue/scheduler[none] mq-deadlineТут я вчера ошибся. Не понял, что в данном случае используется планировщик none. То, что выделено в квадратных скобках - используемый планировщик. Вот ещё пример:
# cat /sys/block/vda/queue/scheduler[mq-deadline] kyber bfq noneТут выбран планировщик mq-deadline. Поддержка планировщика реализована через модули ядра. Если вы хотите добавить отсутствующий планировщик, то загрузите соответствующий модуль.
# cat /sys/block/sda/queue/scheduler[none] mq-deadline# modprobe kyber-iosched# cat /sys/block/sda/queue/scheduler[none] mq-deadline kyber# echo kyber > /sys/block/sda/queue/scheduler# cat /sys/block/sda/queue/schedulermq-deadline [kyber] noneЗагрузили модуль kyber-iosched и активировали этот планировщик. Действовать это изменение будет до перезагрузки системы. Для постоянной работы нужно добавить загрузку этого модуля ядра. Добавьте в файл
/etc/modules-load.d/modules.conf название модуля:kyber-ioschedА для применения планировщика создайте правило udev, например в отдельном файле
/etc/udev/rules.d/schedulerset.rules:ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="sd?", ATTR{queue/scheduler}="kyber"В виртуальных машинах чаще всего по умолчанию выставляется планировщик none и в общем случае это оправдано, так как реальной записью на диск управляет гипервизор, а если есть рейд контроллер, то он. К примеру, в Proxmox на диски автоматически устанавливается планировщик mq-deadline. По крайней мере у меня это так. Проверил на нескольких серверах. А вот в виртуалках с Debian 12 на нём автоматически устанавливается none. Хостеры на своих виртуальных машинах могут автоматически выставлять разные планировщики. Мне встретились none и mq-deadline. Другие не видел.
Теперь что всё это значит на практике. Оценить влияние различных планировщиков очень трудно, так как нужно чётко эмулировать рабочую нагрузку и делать замеры. Если вам нужно настроить приоритизацию, то выбор планировщика в сторону BFQ будет оправдан. Особенно если у вас какой-то проект или сетевой диск с кучей файлов, с которыми постоянно работают, а вам нужно часто снимать с него бэкапы или выполнять какие-либо ещё фоновые действия. Тогда будет удобно настроить минимальный приоритет для фоновых процессов, чтобы они не мешали основной нагрузке.
Если у вас быстрые современные диски, вам нужен приоритет и минимальный отклик для операций чтения, то имеет смысл использовать kyber. Если у вас обычный сервер общего назначения на обычный средних SSD дисках, то можно смело ставить none и не париться.
Некоторые полезные объёмные материалы, которые изучил:
🔥https://selectel.ru/blog/blk-mq-tests/ (много тестов)
⇨ https://habr.com/ru/articles/337102/
⇨ https://redos.red-soft.ru/base/arm/base-arm-hardware/disks/using-ssd/io-scheduler/
⇨ https://timeweb.cloud/blog/blk-mq-i-planirovschiki-vvoda-vyvoda
#linux #kernel #perfomance
👍61👎1
Вчера очень внимательно читал статью на хабре про расследование паразитного чтения диска, когда не было понятно, кто и почему его постоянно читает и таким образом нагружает:
⇨ Расследуем фантомные чтения с диска в Linux
Я люблю такие материалы, так как обычно конспектирую, если нахожу что-то новое. Записываю себе в свою базу знаний. Частично из неё потом получаются заметки здесь.
Там расследовали чтение с помощью blktrace. Я знаю этот инструмент, но он довольно сложный с большим количеством подробностей, которые не нужны, если ты не разбираешься в нюансах работы ядра. Я воспроизвёл описанную историю. Покажу по шагам:
1️⃣ Через
2️⃣ Запускаем
Вывод примерно такой:
В данном случае
3️⃣ Смотрим, что это за блок:
То есть этот блок имеет номер айноды
4️⃣ Смотрим, что это за файл:
Нашли файл, который активно читает процесс questdb-ilpwrit.
Я всё это воспроизвёл у себя на тесте, записал последовательность. Вариант рабочий, но утомительный, если всё делать вручную. Может быть много временных файлов, которых уже не будет существовать, когда ты будешь искать номер айноды соответствующего блока.
Был уверен, что это можно сделать проще, так как я уже занимался подобными вопросами. Вспомнил про утилиту fatrace. Она заменяет более сложные strace или blktrace в простых случаях.
Просто запускаем её и наблюдаем
В соседней консоли откроем лог:
Смотрим в консоль fatrace:
Результат тот же самый, что и выше с blktrace, только намного проще. В fatrace можно сразу отфильтровать вывод по типам операций. Например, только чтение или запись:
Собираем все события в течении 30 секунд с записью в текстовый лог:
Не хватает только наблюдения за конкретным процессом. Почему-то ключ
Можно исключить, к примеру bash или sshd. Они обычно не нужны для расследований.
Рекомендую заметку сохранить, особенно про fatrace. Я себе отдельно записал ещё вот это:
#linux #perfomance
⇨ Расследуем фантомные чтения с диска в Linux
Я люблю такие материалы, так как обычно конспектирую, если нахожу что-то новое. Записываю себе в свою базу знаний. Частично из неё потом получаются заметки здесь.
Там расследовали чтение с помощью blktrace. Я знаю этот инструмент, но он довольно сложный с большим количеством подробностей, которые не нужны, если ты не разбираешься в нюансах работы ядра. Я воспроизвёл описанную историю. Покажу по шагам:
1️⃣ Через
iostat смотрим нагрузку на диск и убеждаемся, что кто-то его активно читает. Сейчас уже не обязательно iostat ставить, так как htop может показать то же самое. 2️⃣ Запускаем
blktrace в режиме наблюдения за операциями чтения с выводом результата в консоль:# blktrace -d /dev/sda1 -a read -o - | blkparse -i -Вывод примерно такой:
259,0 7 4618 5.943408644 425548 Q RA 536514808 + 8 [questdb-ilpwrit]В данном случае
RA 536514808 это событие чтения с диска начиная с блока 536514808.3️⃣ Смотрим, что это за блок:
# debugfs -R 'icheck 536514808 ' /dev/sda1debugfs 1.46.5 (30-Dec-2021)Block Inode number536514808 8270377То есть этот блок имеет номер айноды
8270377. 4️⃣ Смотрим, что это за файл:
debugfs -R 'ncheck 8270377' /dev/sda1Inode Pathname8270377 /home/ubuntu/.questdb/db/table_name/2022-10-04/symbol_col9.d.1092Нашли файл, который активно читает процесс questdb-ilpwrit.
Я всё это воспроизвёл у себя на тесте, записал последовательность. Вариант рабочий, но утомительный, если всё делать вручную. Может быть много временных файлов, которых уже не будет существовать, когда ты будешь искать номер айноды соответствующего блока.
Был уверен, что это можно сделать проще, так как я уже занимался подобными вопросами. Вспомнил про утилиту fatrace. Она заменяет более сложные strace или blktrace в простых случаях.
# apt install fatraceПросто запускаем её и наблюдаем
# fatraceВ соседней консоли откроем лог:
# tail -n 10 /var/log/syslogСмотрим в консоль fatrace:
bash(2143): RO /usr/bin/tailtail(2143): RO /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2tail(2143): O /etc/ld.so.cachetail(2143): RO /usr/lib/x86_64-linux-gnu/libc.so.6tail(2143): C /etc/ld.so.cachetail(2143): O /usr/lib/locale/locale-archivetail(2143): RCO /etc/locale.aliastail(2143): O /var/log/syslogtail(2143): R /var/log/syslogРезультат тот же самый, что и выше с blktrace, только намного проще. В fatrace можно сразу отфильтровать вывод по типам операций. Например, только чтение или запись:
# fatrace -f R# fatrace -f WСобираем все события в течении 30 секунд с записью в текстовый лог:
# fatrace -s -t 30 -o /tmp/fatrace.logНе хватает только наблюдения за конкретным процессом. Почему-то ключ
-p позволяет не задать конкретный пид процесса для наблюдения, а исключить из результатов операции процесса с этим pid:# fatrace -p 697Можно исключить, к примеру bash или sshd. Они обычно не нужны для расследований.
Рекомендую заметку сохранить, особенно про fatrace. Я себе отдельно записал ещё вот это:
# debugfs -R 'icheck 536514808 ' /dev/sda1# debugfs -R 'ncheck 8270377' /dev/sda1#linux #perfomance
2👍150👎3
В выходные прочитал интересную статью:
⇨ Как настроить веб-приложение под высокие нагрузки
Первый раз попал на этот ресурс. Понравилось качество контента. С удовольствием прочитал несколько статей. Эта понравилась больше всего, поэтому решил поделиться и сделать небольшую выжимку для тех, кто не захочет тратить время на весь материал. Там есть интересные для админов моменты.
Автор рассказал, как один проект лавинообразно начал расти и тормозить под нагрузкой во время пандемии, когда его посещаемость выросла в разы. Он поэтапно описал, как они изменяли железо, настройки, архитектуру приложения.
Изначально это был небольшой проект на PHP и его фреймворке Symfony, который писали 3-5 проектировщиков. СУБД была PostgreSQL, под кэш Redis, написана API и очередь для неё на RabbitMQ. Такое типовое классическое веб приложение. Проект располагался на 16 физических серверах, фронтенды и бэкенды — по 24 ядра и 128 ОЗУ каждый, ноды СУБД имели 56 ядер и 512 ГБ ОЗУ.
Огромную помощью в решении возникающих проблем оказывал мониторинг. Он был реализован на базе Zabbix, Symfony Profiler, Cockpit, DBeaver, Nginx Amplify.
🔹Одним из узких мест оказались логи Nginx. Была включена буферизация логов. В момент скидывания буферов на диск, они тормозили. Временно перенесли логи в RAM-диски (tmpfs). Потом перенастроили систему хранения логов.
🔹Другим узким местом была главная страница. Её целиком закешировали и поместили в Redis. Далее весь код перетряхнули и по возможности настроили использование кэша в Redis. После этого Redis вынесли в отдельный кластер. Это привело к тому, что даже в границах одной серверной и максимально быстрой сети, кэш стал работать медленнее, а на саму локалку сильно выросла сетевая нагрузка. Пришлось разбить кэш на 2 уровня. Первый хранить в локальных инстансах Redis, а второй в отдельном кластере с доступом по сети.
🔹Для разгрузки СУБД установили PgBouncer для управления пулом соединений, постановки их в очередь, если всё занято. Один огромный сервер под СУБД распили на кластер из 5-ти серверов. Запросы к кластеру стали распределять с помощью PGPool. INSERT, UPDATE, DELETE отправляли на Master, всё остальное распределяли между остальными серверами.
🔹В какой-то момент все серверные мощности были нагружены на 70-80%. Это стало приводить к проблемам, когда что-то из железа выходило из строя. Пришлось добавить серверов, чтобы нагрузка стала 40-50%.
🔹Далее упёрлись в ёмкость входного канала. Пришлось переходить на использование геораспределённой CDN.
#perfomance
⇨ Как настроить веб-приложение под высокие нагрузки
Первый раз попал на этот ресурс. Понравилось качество контента. С удовольствием прочитал несколько статей. Эта понравилась больше всего, поэтому решил поделиться и сделать небольшую выжимку для тех, кто не захочет тратить время на весь материал. Там есть интересные для админов моменты.
Автор рассказал, как один проект лавинообразно начал расти и тормозить под нагрузкой во время пандемии, когда его посещаемость выросла в разы. Он поэтапно описал, как они изменяли железо, настройки, архитектуру приложения.
Изначально это был небольшой проект на PHP и его фреймворке Symfony, который писали 3-5 проектировщиков. СУБД была PostgreSQL, под кэш Redis, написана API и очередь для неё на RabbitMQ. Такое типовое классическое веб приложение. Проект располагался на 16 физических серверах, фронтенды и бэкенды — по 24 ядра и 128 ОЗУ каждый, ноды СУБД имели 56 ядер и 512 ГБ ОЗУ.
Огромную помощью в решении возникающих проблем оказывал мониторинг. Он был реализован на базе Zabbix, Symfony Profiler, Cockpit, DBeaver, Nginx Amplify.
🔹Одним из узких мест оказались логи Nginx. Была включена буферизация логов. В момент скидывания буферов на диск, они тормозили. Временно перенесли логи в RAM-диски (tmpfs). Потом перенастроили систему хранения логов.
🔹Другим узким местом была главная страница. Её целиком закешировали и поместили в Redis. Далее весь код перетряхнули и по возможности настроили использование кэша в Redis. После этого Redis вынесли в отдельный кластер. Это привело к тому, что даже в границах одной серверной и максимально быстрой сети, кэш стал работать медленнее, а на саму локалку сильно выросла сетевая нагрузка. Пришлось разбить кэш на 2 уровня. Первый хранить в локальных инстансах Redis, а второй в отдельном кластере с доступом по сети.
🔹Для разгрузки СУБД установили PgBouncer для управления пулом соединений, постановки их в очередь, если всё занято. Один огромный сервер под СУБД распили на кластер из 5-ти серверов. Запросы к кластеру стали распределять с помощью PGPool. INSERT, UPDATE, DELETE отправляли на Master, всё остальное распределяли между остальными серверами.
🔹В какой-то момент все серверные мощности были нагружены на 70-80%. Это стало приводить к проблемам, когда что-то из железа выходило из строя. Пришлось добавить серверов, чтобы нагрузка стала 40-50%.
🔹Далее упёрлись в ёмкость входного канала. Пришлось переходить на использование геораспределённой CDN.
#perfomance
1👍119👎3
Прочитал очень интересную техническую статью на хабре, в которой много просто любопытных и прикладных моментов. Зафиксирую некоторые их них в заметке для тех, кто не захочет читать весь материал. Он объёмный.
⇨ Как небольшой «тюнинг» Talos Linux увеличил производительность NVMe SSD в 2.5 раза
1️⃣ Кто-то заезжает в облака, кто-то выезжает. Автор построил Kubernetes кластер на Bare Metal, снизив затраты по сравнению с Google Cloud в 4 раза, увеличив производительность в 4 раза! Так что не стоит полностью забывать железо и жить в облачных абстракциях. В каких-то случаях стоит спускаться на землю и не терять навык работы на ней.
2️⃣ Очень объёмный и насыщенный материал по тестированию дисковой подсистемы с конкретными примерами для fio. Если не хочется сильно вникать, то можно сразу брать готовые команды для линейного чтения, линейной записи, задержки случайного чтения и т.д. Там для всех популярных метрик есть примеры.
3️⃣ Автор собрал свой Docker контейнер, который выполнят весь набор тестов и выводит результат в формате CSV для удобного экспорта в табличку с графиками.
❗️Тест fio с записью на диск деструктивный. Нельзя запускать этот тест на диске с данными. Они будут уничтожены. Это для чистых блочных устройств. Я попробовал эти тесты. Удобно сделано. Рекомендую забрать к себе. Там всё самое интересное в скрипте
Полученные данные каким-то образом переносятся вот в такую наглядную таблицу. Я не понял, как это сделано, но надеюсь, что получиться разобраться. Очень удобно и наглядно проводить тестирование и сравнивать результаты.
4️⃣ Производительность дисковой подсистемы в Talos Linux по сравнению с обычным Debian была в 1,5-2 раза ниже. Причина была в разных параметрах ядра.
5️⃣ Настроек ядра очень много. Сравнение настроек в разных дистрибутивах вручную очень трудоёмкая задача. Автор сгрузил diff файл параметров ядра указанных систем в ChatGPT и он сразу же выдал ответ, какой параметр приводит к снижению производительности:
В Talos Linux включен параметр CONFIG_IOMMU_DEFAULT_DMA_STRICT=y, в то время как в Debian используется CONFIG_IOMMU_DEFAULT_DMA_LAZY=y. Режим strict в IOMMU заставляет ядро немедленно выполнять сброс кэшей IOMMU при каждом связывании и отвязывании DMA (то есть при каждом вводе-выводе), что приводит к дополнительной нагрузке на систему и может значительно снизить производительность ввода-вывода при интенсивных операциях, таких как тестирование IOPS.
6️⃣ Разница в производительности может быть значительной между разными версиями ядра Linux. Это связано с патчами безопасности, которые снижают производительность. Для каких-то старых ядер, которые уже не поддерживаются, этих патчей может не быть. На них производительность будет выше (а безопасность ниже).
7️⃣ Благодаря множественным манипуляциям над системой Talos Linux автору удалось подтянуть её производительность до оригинального Debian. Но всё равно она была ниже. Из этого можно сделать вывод, что различные альтернативные дистрибутивы Linux стоит использовать осторожно и осмысленно. Изначальная разница в производительности в 2 раза как-бы не мелочь.
Статью рекомендую прочитать полностью. Если работаете с железом и Linux, будет полезно. Я для себя забрал оттуда тесты и табличку. Попробую всё это скрестить, чтобы так же красиво и быстро сравнивать результаты. Пригодится как минимум для тестов разных типов хранилищ в системах виртуализации.
☝️ Отметил для себя полезность ИИ. Надо начинать пользоваться.
#linux #perfomance
⇨ Как небольшой «тюнинг» Talos Linux увеличил производительность NVMe SSD в 2.5 раза
# docker run -it --rm --entrypoint /run.sh --privileged maxpain/fio:latest /dev/nvme0n1❗️Тест fio с записью на диск деструктивный. Нельзя запускать этот тест на диске с данными. Они будут уничтожены. Это для чистых блочных устройств. Я попробовал эти тесты. Удобно сделано. Рекомендую забрать к себе. Там всё самое интересное в скрипте
/run.sh. Можно сохранить к себе на память только его:# docker create --name fio maxpain/fio:latest false# docker cp fio:/run.sh ~/run.shПолученные данные каким-то образом переносятся вот в такую наглядную таблицу. Я не понял, как это сделано, но надеюсь, что получиться разобраться. Очень удобно и наглядно проводить тестирование и сравнивать результаты.
В Talos Linux включен параметр CONFIG_IOMMU_DEFAULT_DMA_STRICT=y, в то время как в Debian используется CONFIG_IOMMU_DEFAULT_DMA_LAZY=y. Режим strict в IOMMU заставляет ядро немедленно выполнять сброс кэшей IOMMU при каждом связывании и отвязывании DMA (то есть при каждом вводе-выводе), что приводит к дополнительной нагрузке на систему и может значительно снизить производительность ввода-вывода при интенсивных операциях, таких как тестирование IOPS.
Статью рекомендую прочитать полностью. Если работаете с железом и Linux, будет полезно. Я для себя забрал оттуда тесты и табличку. Попробую всё это скрестить, чтобы так же красиво и быстро сравнивать результаты. Пригодится как минимум для тестов разных типов хранилищ в системах виртуализации.
☝️ Отметил для себя полезность ИИ. Надо начинать пользоваться.
#linux #perfomance
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Как небольшой «тюнинг» Talos Linux увеличил производительность NVMe SSD в 2.5 раза
Предыстория Недавно я начал готовить очередной Kubernetes кластер на Bare Metal серверах для одного из наших проектов дабы съехать с Google Cloud и снизить расходы на инфраструктуру примерно в 4 раза,...
2👍118👎10
Пока была возможность, решил проверить, какой штраф на дисковые операции накладывает виртуализация в Proxmox. В моей работе чаще всего именно дисковая подсистема является узким местом серверов. CPU обычно хватает, память сейчас недорога и легко расширяется. С дисками проблем больше всего.
Взял тестовый сервер Proxmox, в котором есть железный RAID контроллер без кэша и собранный RAID10 из 4-х HDD. Воткнул туда дополнительно обычный SSD AMD Radeon R5 R5SL480G 480ГБ. RAID10 подключил как обычный LVM storage, а SSD как LVM-Thin.
Нарезал там LV для хоста:
Сделал фс ext4 и смонтировал:
Прогнал серию из 10-ти тестов для каждого хранилища с помощью dd:
Далее взял fio и прогнал тесты с его помощью:
Линейное чтение:
Линейная запись:
Пиковые IOPS случайной записи:
Так для обоих дисков. С dd сделал по 10 тестов, с fio по 5. Потом создал VM на Debian 12, создал для неё такие же диски, выбрав параметры:
▪️Device: SCSI
▪️Cache: Default (No cache)
▪️IO thread: yes
▪️Async IO: Default (io_uring)
Настройки все по умолчанию. И там выполнил точно такие же тесты. Свёл всё в одну таблицу. Я тут приводить точные цифры тестов не буду, так как они не имеют принципиального значения. Цифры можете сами посмотреть. Перейду сразу к выводам.
Разброс в производительности не более 9%. А если точно, то разница между хостом и VM только в одном тесте на запись была 9%, в остальных случаях 2-6%. Немного удивило то, что в паре тестов в VM результаты были выше на 2%, чем на хосте. Я несколько раз перепроверял, но ситуация воспроизводилась снова. Не знаю, с чем это может быть связано.
Честно говоря думал, что по диску просадка будет больше в виртуальных машинах. А на практике она очень незначительная. Часто выбирают контейнеры, чтобы минимизировать разницу в производительности дисков, так как там хранилище прямо с хоста подключается. Для себя большого смысла не увидел в этом, если это единственный довод в пользу контейнера. Предпочту развернуть нагрузку в VM, как более универсальное решение, если не стоит задача максимальной плотности размещения для утилизации процессора и памяти.
#proxmox #disk #perfomance
Взял тестовый сервер Proxmox, в котором есть железный RAID контроллер без кэша и собранный RAID10 из 4-х HDD. Воткнул туда дополнительно обычный SSD AMD Radeon R5 R5SL480G 480ГБ. RAID10 подключил как обычный LVM storage, а SSD как LVM-Thin.
Нарезал там LV для хоста:
# lvcreate -V 10G -n test_ssd --thinpool SSD-RADEON/SSD-RADEON# lvcreate -L 10G -n test_raid10 raid10Сделал фс ext4 и смонтировал:
# mkfs.ext4 /dev/SSD-RADEON/test_ssd# mkfs.ext4 /dev/raid10/test_raid10# mount /dev/SSD-RADEON/test_ssd /mnt/SSD-RADEON# mount /dev/raid10/test_raid10 /mnt/raid10Прогнал серию из 10-ти тестов для каждого хранилища с помощью dd:
# dd if=/dev/zero of=/mnt/raid10/tempfile bs=1M count=2000 oflag=direct# dd if=/dev/zero of=/mnt/SSD-RADEON/tempfile bs=1M count=2000 oflag=directДалее взял fio и прогнал тесты с его помощью:
Линейное чтение:
# fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=1M -iodepth=32 -rw=read -runtime=30 -filename=/dev/raid10/test_raid10Линейная запись:
# fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=1M -iodepth=32 -rw=write -runtime=30 -filename=/dev/raid10/test_raid10Пиковые IOPS случайной записи:
# fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=128 -rw=randwrite -runtime=30 -filename=/dev/raid10/test_raid10Так для обоих дисков. С dd сделал по 10 тестов, с fio по 5. Потом создал VM на Debian 12, создал для неё такие же диски, выбрав параметры:
▪️Device: SCSI
▪️Cache: Default (No cache)
▪️IO thread: yes
▪️Async IO: Default (io_uring)
Настройки все по умолчанию. И там выполнил точно такие же тесты. Свёл всё в одну таблицу. Я тут приводить точные цифры тестов не буду, так как они не имеют принципиального значения. Цифры можете сами посмотреть. Перейду сразу к выводам.
Разброс в производительности не более 9%. А если точно, то разница между хостом и VM только в одном тесте на запись была 9%, в остальных случаях 2-6%. Немного удивило то, что в паре тестов в VM результаты были выше на 2%, чем на хосте. Я несколько раз перепроверял, но ситуация воспроизводилась снова. Не знаю, с чем это может быть связано.
Честно говоря думал, что по диску просадка будет больше в виртуальных машинах. А на практике она очень незначительная. Часто выбирают контейнеры, чтобы минимизировать разницу в производительности дисков, так как там хранилище прямо с хоста подключается. Для себя большого смысла не увидел в этом, если это единственный довод в пользу контейнера. Предпочту развернуть нагрузку в VM, как более универсальное решение, если не стоит задача максимальной плотности размещения для утилизации процессора и памяти.
#proxmox #disk #perfomance
Google Docs
Тесты дисков
2👍126👎4
Посмотрел очень интересное видео про снижение задержек в SSD дисках. Там и по теории прошлись, но в основном по практике. По шагам рассказали, что пробовали сделать, какие параметры ОС и софта меняли и к чему это приводило.
⇨ Как в Айри.рф сократили SSD-задержки в 61 раз
Мне такой формат выступления нравится, потому что его можно оформить в мини-инструкцию, зафиксировать основные моменты и потом использовать в своей работе. Так что я законспектировал выступление и выделил ключевые моменты, которые могут пригодиться.
У автора стал тормозить классический веб стек под Nginx. Увеличились как задержки на отдачу обычной статики пользователю из кэша, доходили до 1-2 секунд, так и динамические запросы мимо кэша. Было не понятно, с чем это связано. Использовались одиночные SSD диски Samsung Evo без рейда, файловая система ext4 поверх LVM разделов.
Начали разбор ситуации с выделения метрик и утилит для отслеживания отклика дисков:
◽️системный i/o wait
◽️метрики disk timings (статистика от Prometheus)
◽️утилиты ioping / iostat / iotop
◽️HTTP response time
Эти данные ничего не прояснили и не подсказали, куда в итоге надо смотреть и что делать. Далее начали анализировать очередь на запись операционной системы. На практике это никак не помогло понять, где возникают дисковые задержки.
Между приложением и диском есть несколько звеньев: буфер nginx, буфер ОС, очередь на запись. Каждый из этих этапов может добавлять задержку. Проанализировать всё это - нетривиальная задача.
Пробовали следующие изменения:
● асинхронные потоки в nginx через параметр
● уменьшение очереди на запись ОС:
не дало заметных улучшений
● изменение планировщика с cfq на deadline не принесло значимых изменений
● отключение журналирования через монтирование в fstab с параметром
● перенос логов nginx на внешние хранилища и отключение или перенос других системных логов еще уменьшили задержки на 10%.
Для дальнейшего анализа производительности сервиса решили привязаться к метрикам nginx для запросов, которые проходят мима кэша:
Что в итоге помогло больше всего?
🔹Отключение полностью журналирования на серверах с кэшем, который можно без последствий потерять
🔹Включение Trim по расписанию примерно тогда, когда объём диска предположительно полностью перезаписан. В данном случае это происходило примерно через неделю работы. Этот интервал и использовали. Я раз в сутки обычно ставлю на своих виртуалках.
🔹Использование tmpfs там, где это возможно. Уменьшает нагрузку на запись, увеличивает срок жизни SSD, работает только на небольших объёмах данных, которые можно потерять.
Каждый из этих шагов дал примерно в 2-3 раза снижение задержек. И в сумме получился заметный прирост для всего сервиса. Плюс, оптимизировали немного само приложение. И в итоге всё заработало в десятки раз быстрее.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#perfomance #disk
⇨ Как в Айри.рф сократили SSD-задержки в 61 раз
Мне такой формат выступления нравится, потому что его можно оформить в мини-инструкцию, зафиксировать основные моменты и потом использовать в своей работе. Так что я законспектировал выступление и выделил ключевые моменты, которые могут пригодиться.
У автора стал тормозить классический веб стек под Nginx. Увеличились как задержки на отдачу обычной статики пользователю из кэша, доходили до 1-2 секунд, так и динамические запросы мимо кэша. Было не понятно, с чем это связано. Использовались одиночные SSD диски Samsung Evo без рейда, файловая система ext4 поверх LVM разделов.
Начали разбор ситуации с выделения метрик и утилит для отслеживания отклика дисков:
◽️системный i/o wait
◽️метрики disk timings (статистика от Prometheus)
◽️утилиты ioping / iostat / iotop
◽️HTTP response time
Эти данные ничего не прояснили и не подсказали, куда в итоге надо смотреть и что делать. Далее начали анализировать очередь на запись операционной системы. На практике это никак не помогло понять, где возникают дисковые задержки.
Между приложением и диском есть несколько звеньев: буфер nginx, буфер ОС, очередь на запись. Каждый из этих этапов может добавлять задержку. Проанализировать всё это - нетривиальная задача.
Пробовали следующие изменения:
● асинхронные потоки в nginx через параметр
aio threads = default; результат: снижение задержек на 5-10%;● уменьшение очереди на запись ОС:
vm_dirty_expire_centisecs=1vm_dirty_writeback_centisecs=1не дало заметных улучшений
● изменение планировщика с cfq на deadline не принесло значимых изменений
● отключение журналирования через монтирование в fstab с параметром
noatime снизило на 10% задержки.● перенос логов nginx на внешние хранилища и отключение или перенос других системных логов еще уменьшили задержки на 10%.
Для дальнейшего анализа производительности сервиса решили привязаться к метрикам nginx для запросов, которые проходят мима кэша:
nginx_time_request и nginx_upstream_header_time. Анализ этих метрик позволил оценить производительность сервиса в целом: лучше он стал работать или нет. Я, кстати, тоже включаю метрику request_time для веб серверов, где требуется оценка производительности. Можно почитать об этом в моей статье Мониторинг производительности бэкенда с помощью ELK Stack.Что в итоге помогло больше всего?
🔹Отключение полностью журналирования на серверах с кэшем, который можно без последствий потерять
🔹Включение Trim по расписанию примерно тогда, когда объём диска предположительно полностью перезаписан. В данном случае это происходило примерно через неделю работы. Этот интервал и использовали. Я раз в сутки обычно ставлю на своих виртуалках.
🔹Использование tmpfs там, где это возможно. Уменьшает нагрузку на запись, увеличивает срок жизни SSD, работает только на небольших объёмах данных, которые можно потерять.
Каждый из этих шагов дал примерно в 2-3 раза снижение задержек. И в сумме получился заметный прирост для всего сервиса. Плюс, оптимизировали немного само приложение. И в итоге всё заработало в десятки раз быстрее.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#perfomance #disk
2👍164👎2
Прочитал интересную статью про Linux IOWait в блоге компании Percona. У автора оказались подозрительно русские имя и фамилия - Peter Zaitsev. Навёл справки. Оказалось, что это Пётр Зайцев - сооснователь компании Percona. Я и не знал, что эта компания основана русскими, хотя пользуюсь её бесплатными продуктами много лет.
⇨ Understanding Linux IOWait
Сделал короткую выжимку из статьи, чтобы передать суть. Информация показалась полезной и новой для меня. Вначале пример от автора, как можно жёстко нагрузить дисковую подсистему:
Используется утилита sysbench. Я, кстати, писал про неё. У неё есть встроенные тесты для СУБД. Приведённая выше команда жёстко нагрузит метрику cpu iowait. Проверить можно через vmstat, колонка wa.
Пробуем дальше нагружать систему нагрузкой на процессор, не прерывая прошлый тест:
Снова смотрим на vmstat и видим, что нагрузка IOWait куда-то пропала. Как так? Первый тест продолжает нагружать диски, но мы уже этого не видим в привычной метрике.
Смысл тут вот в чём. Когда мы долго ждём ответа от дисков, процессор простаивает. Растёт метрика cpu idle. Простой процессора из-за ожидания I/O засчитывается в метрику IOWait. Но как только мы нагружаем процессор другой работой, метрика idle падает, а за ней и IOWait. Это особенность подсчёта этих метрик.
Теперь вместо первого теста в 8 потоков, запустим только один на виртуалке с 4-мя ядрами:
Несмотря на то, что этот тест тоже полностью нагрузит дисковую подсистему, мы увидим IOWait в районе 20-25%. А на виртуальных машинах с большим числом ядер (32-64) цифра будет настолько незначительна, что мы можем вообще не заметить её. Но при этом дисковая подсистема будет полностью загружена.
Таким образом, высокая метрика IOWait показывает, что процессор ожидает операции I/O. Но при этом низкий показатель не гарантирует, что у вас не загружены диски. Надо уточнять.
Как же узнать, что у нас есть проблемы с нагрузкой по I/O? Можно посмотреть на столбец
В продукте Percona Monitoring and Management есть плагин, который в том числе показывает статистику по процессам. Там будут видны процессы, ожидающие I/O. Указанный мониторинг бесплатен, это open source.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #perfomance
⇨ Understanding Linux IOWait
Сделал короткую выжимку из статьи, чтобы передать суть. Информация показалась полезной и новой для меня. Вначале пример от автора, как можно жёстко нагрузить дисковую подсистему:
# sysbench --threads=8 --time=0 --max-requests=0 fileio --file-num=1 --file-total-size=10G --file-io-mode=sync --file-extra-flags=direct --file-test-mode=rndrd run Используется утилита sysbench. Я, кстати, писал про неё. У неё есть встроенные тесты для СУБД. Приведённая выше команда жёстко нагрузит метрику cpu iowait. Проверить можно через vmstat, колонка wa.
Пробуем дальше нагружать систему нагрузкой на процессор, не прерывая прошлый тест:
# sysbench --threads=8 --time=0 cpu runСнова смотрим на vmstat и видим, что нагрузка IOWait куда-то пропала. Как так? Первый тест продолжает нагружать диски, но мы уже этого не видим в привычной метрике.
Смысл тут вот в чём. Когда мы долго ждём ответа от дисков, процессор простаивает. Растёт метрика cpu idle. Простой процессора из-за ожидания I/O засчитывается в метрику IOWait. Но как только мы нагружаем процессор другой работой, метрика idle падает, а за ней и IOWait. Это особенность подсчёта этих метрик.
Теперь вместо первого теста в 8 потоков, запустим только один на виртуалке с 4-мя ядрами:
# sysbench --threads=1 --time=0 --max-requests=0 fileio --file-num=1 --file-total-size=10G --file-io-mode=sync --file-extra-flags=direct --file-test-mode=rndrd runНесмотря на то, что этот тест тоже полностью нагрузит дисковую подсистему, мы увидим IOWait в районе 20-25%. А на виртуальных машинах с большим числом ядер (32-64) цифра будет настолько незначительна, что мы можем вообще не заметить её. Но при этом дисковая подсистема будет полностью загружена.
Таким образом, высокая метрика IOWait показывает, что процессор ожидает операции I/O. Но при этом низкий показатель не гарантирует, что у вас не загружены диски. Надо уточнять.
Как же узнать, что у нас есть проблемы с нагрузкой по I/O? Можно посмотреть на столбец
b в vmstat. Он показывает количество процессов, которые заблокированы в ожидании I/O для завершения. Соседний столбец r покажет суммарное число запущенных процессов.В продукте Percona Monitoring and Management есть плагин, который в том числе показывает статистику по процессам. Там будут видны процессы, ожидающие I/O. Указанный мониторинг бесплатен, это open source.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #perfomance
Percona Database Performance Blog
Understanding Linux IOWait
Why looking at the “IOWait” portion of CPU usage to indicate whenever the system is I/O-bound is unreliable, and what better indicators you can use instead.
3👍153👎7
При использование популярной в Linux утилиты
Зачастую удобнее сразу указать имя процесса. Покажу на примере просмотра потоков процесса, о которых дальше пойдёт речь:
Увидели сразу PID процесса 525 и все его потоки с номерами SPID. Иногда бывает нужно посмотреть или сразу посчитать потоки во время отладки какого-то приложения, которое, к примеру, виснет по какой-то причине. Быстро считаем его потоки:
Обращаю внимание, что вывод с потоками будет больше, чем просто вывод списка процессов, которые тоже часто считают для задач мониторинга. На том же сервере в тот же момент:
Если есть какие-то проблемы с приложением, и не понятно, что именно тормозит, можно вывести нужные метрики с разбивкой на потоки. Это хорошо показать на примере Fail2ban с PID 508.
У Fail2ban может быть много фильтров, которые обрабатываются в разных потоках. И какой-то из них в случае лавинообразного разрастания лога может очень сильно нагружать систему. Зная PID и SPID можно посмотреть подробности потока:
Всю строку не привожу, так как самое интересное в начале. Тут видно, что указанный поток обрабатывает jail с именем wp-login. Больше информации покажет
Ещё более подробную информацию можно получить через strace. Он не только по PID может подключаться, но и по SPID:
Там будет виден и лог, который поток читает, и даже конкретные строки. На нагруженном сервере завалит консоль, так что лучше сразу в файл выводить и потом смотреть. Обычное перенаправление в файл не сработает, надо использовать ключ
Можно конкретизировать, что записывать. Например, для Fail2ban будут актуальны операции открытия файлов и чтения:
А для каких-то процессов будет иметь смысл следить за записью:
Подобная проверка с strace будет очень актуальна, когда у вас какой-то поток приложения, к примеру, обращается по сети к ресурсу, который недоступен. И запрос висит по таймауту хрен знает сколько времени. А у вас сам процесс из-за него тормозит или висит.
Трейсы в режиме реального времени можно посмотреть и в
Стандартные и относительно простые утилиты консоли Linux позволят продебажить и разобраться даже в сложных и неочевидных на первый взгляд ситуациях.
📌 Полезные ссылки по теме заметки дебага консольными утилитами:
▪️Примеры использования ps
▪️Анализ дисковой активности в Linux
▪️Узнаём, что конкретно тормозит в php коде
▪️Расследование фантомных чтений с диска
▪️Расследование тормозов php сайта с помощью perf
▪️Профилирование нагрузки в Linux
▪️Кто и как использует swap
▪️Анализируем нагрузку на диск с помощью perf-tools
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #terminal #perfomance
ps чаще всего оперируешь PID процесса или грепаешь вывод по строке в имени процесса:# ps -p 524 -o %mem,%cpu,cmd# ps ax | grep prometheusЗачастую удобнее сразу указать имя процесса. Покажу на примере просмотра потоков процесса, о которых дальше пойдёт речь:
# ps -T -C prometheus PID SPID TTY TIME CMD 525 525 ? 00:55:34 prometheus 525 803 ? 00:03:10 prometheus 525 808 ? 00:09:22 prometheus 525 1054 ? 00:08:44 prometheus 525 1113 ? 00:12:03 prometheus 525 1129 ? 00:10:42 prometheus 525 58983 ? 00:11:30 prometheusУвидели сразу PID процесса 525 и все его потоки с номерами SPID. Иногда бывает нужно посмотреть или сразу посчитать потоки во время отладки какого-то приложения, которое, к примеру, виснет по какой-то причине. Быстро считаем его потоки:
# ps -T -C zabbix_server | wc -l82Обращаю внимание, что вывод с потоками будет больше, чем просто вывод списка процессов, которые тоже часто считают для задач мониторинга. На том же сервере в тот же момент:
# ps ax | grep zabbix_server | wc -l59Если есть какие-то проблемы с приложением, и не понятно, что именно тормозит, можно вывести нужные метрики с разбивкой на потоки. Это хорошо показать на примере Fail2ban с PID 508.
# ps -L -o spid,%mem,%cpu,cmd 508 SPID %MEM %CPU CMD 1070 0.6 0.0 /usr/bin/python3 /usr/bin/fail2ban-server -xf start 1071 0.6 0.1 /usr/bin/python3 /usr/bin/fail2ban-server -xf start 1072 0.6 0.0 /usr/bin/python3 /usr/bin/fail2ban-server -xf start 1074 0.6 0.1 /usr/bin/python3 /usr/bin/fail2ban-server -xf start 1075 0.6 0.0 /usr/bin/python3 /usr/bin/fail2ban-server -xf start 1077 0.6 0.3 /usr/bin/python3 /usr/bin/fail2ban-server -xf startУ Fail2ban может быть много фильтров, которые обрабатываются в разных потоках. И какой-то из них в случае лавинообразного разрастания лога может очень сильно нагружать систему. Зная PID и SPID можно посмотреть подробности потока:
# cat /proc/508/task/1077/stat1077 (f2b/f.wp-login) ...................................Всю строку не привожу, так как самое интересное в начале. Тут видно, что указанный поток обрабатывает jail с именем wp-login. Больше информации покажет
status:# cat /proc/508/task/1077/statusЕщё более подробную информацию можно получить через strace. Он не только по PID может подключаться, но и по SPID:
# strace -p 1077Там будет виден и лог, который поток читает, и даже конкретные строки. На нагруженном сервере завалит консоль, так что лучше сразу в файл выводить и потом смотреть. Обычное перенаправление в файл не сработает, надо использовать ключ
-o:# strace -p 1077 -o ~/strace.outМожно конкретизировать, что записывать. Например, для Fail2ban будут актуальны операции открытия файлов и чтения:
# strace -p 1077 -e trace=openat,readА для каких-то процессов будет иметь смысл следить за записью:
# strace -p 1077 -e trace=writeПодобная проверка с strace будет очень актуальна, когда у вас какой-то поток приложения, к примеру, обращается по сети к ресурсу, который недоступен. И запрос висит по таймауту хрен знает сколько времени. А у вас сам процесс из-за него тормозит или висит.
Трейсы в режиме реального времени можно посмотреть и в
htop. Выбираете нужный процесс или поток и нажимайте s. Если strace установлена в системе, то увидите её работу.Стандартные и относительно простые утилиты консоли Linux позволят продебажить и разобраться даже в сложных и неочевидных на первый взгляд ситуациях.
📌 Полезные ссылки по теме заметки дебага консольными утилитами:
▪️Примеры использования ps
▪️Анализ дисковой активности в Linux
▪️Узнаём, что конкретно тормозит в php коде
▪️Расследование фантомных чтений с диска
▪️Расследование тормозов php сайта с помощью perf
▪️Профилирование нагрузки в Linux
▪️Кто и как использует swap
▪️Анализируем нагрузку на диск с помощью perf-tools
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #terminal #perfomance
15👍196👎2
На днях разбирался с одной относительно простой задачей, но из-за того, что затупил, потратил на неё очень много времени. Так как проделал множество всевозможных операций, решил всё подробно описать. Пригодится в других похожих историях.
Есть MySQL сервер, у которого, как мне показалось, очень большая нагрузка по CPU. Проект немного стух, записи в базу должно быть мало и мне было странно видеть высокую нагрузку от СУБД. Решил разобраться, в чём там дело.
Для начала просто посмотрел нагрузку через
В таких случаях часто помогает strace. Можно подцепиться к процессу и посмотреть, что он пишет:
В моём случае я не получил результата. В выводе просто было пусто. Я не понял, почему. Стал разбираться дальше. Смотрю потоки процесса:
Вижу, что CPU нагружает сильно больше всех остальных один поток с SPID 19547. Смотрю по нему информацию:
В выводе только цифры и отсылка к основному потоку mysqld. То есть вообще не понятно, что там реально происходит.
Тут до меня доходит подцепиться к потоку через strace:
Вижу системные вызовы futex (синхронизацией потоков), io_submit (асинхронные операции ввода-вывода) и некоторые другие.
Смотрю, в какие файлы пишет mysqld:
Это
А на серваке выполнялись десятки простых SELECT за считанные миллисекунды или ещё быстрее. Не отслеживал. И они тупо не попадали в вывод. И я думал, что запросов мало, а их было дохрена. Они и давали нагрузку на CPU.
Запросы увидел так. Не перезапуская сервер выполнил в консоли mysql:
Так же это было видно в выводе:
В разделе I/O. Эти потоки отвечают за асинхронные операции ввода-вывода (AIO).
Достаточно было на несколько секунд запустить, чтобы понять всю картину. Потом сразу отключил, чтобы не нагружать диски.
Осталось разобраться, а что на диск то записывается. Вроде как файлы
xb_doublewrite - это некий буфер InnoDB для повышения надёжности хранения, отключать не рекомендуется, хотя можно.
В общем, время я по сути потратил впустую, если не считать вот эту заметку итоговым результатом. Думаю, она мне ещё понадобится. Времени уже не оставалось дальше разбираться с этой историей. В целом, нагрузка там рабочая, абсолютно некритичная, так что разбираться с ней дальше большой нужды не было. Но я всё равно планирую подумать, как её снизить. И вообще не совсем понятно, почему её так много, с учётом того, что сайт активно кэшируется. Надо будет разбираться.
Отдельно отмечу, что очень активно нагружал этой темой DeepSeek, но он особо не помог. Да, много всякой информации давал и анализировал мои результаты, но фактически я сам догадался в чём причина. Он как-то больше по кругу ходил и всякие команды накидывал.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mysql #perfomance
Есть MySQL сервер, у которого, как мне показалось, очень большая нагрузка по CPU. Проект немного стух, записи в базу должно быть мало и мне было странно видеть высокую нагрузку от СУБД. Решил разобраться, в чём там дело.
Для начала просто посмотрел нагрузку через
top. Mysql почти постоянно кушает одно ядро и периодически остальные дёргает. Дополнительно смотрю в iotop и pidstat и вижу постоянно запись со стороны службы mysqld с pid 19535:# iotop -obPat# pidstat -p 19535 -d 1В таких случаях часто помогает strace. Можно подцепиться к процессу и посмотреть, что он пишет:
# strace -e trace=write -p 19535В моём случае я не получил результата. В выводе просто было пусто. Я не понял, почему. Стал разбираться дальше. Смотрю потоки процесса:
# ps -L -o spid,%mem,%cpu,cmd 16005Вижу, что CPU нагружает сильно больше всех остальных один поток с SPID 19547. Смотрю по нему информацию:
# cat /proc/19535/task/19547/stat# cat /proc/19535/task/19547/statusВ выводе только цифры и отсылка к основному потоку mysqld. То есть вообще не понятно, что там реально происходит.
Тут до меня доходит подцепиться к потоку через strace:
# strace -p 19547Вижу системные вызовы futex (синхронизацией потоков), io_submit (асинхронные операции ввода-вывода) и некоторые другие.
Смотрю, в какие файлы пишет mysqld:
# inotifywait -m /var/lib/mysqlЭто
ib_logfile0 и xb_doublewrite. Никак не могу понять, почему он туда активно пишет, когда запросов к базе особо нет. И вот тут я как раз и затупил. Я смотрел запросы через mytop и SHOW FULL PROCESSLIST; И там их было очень мало. Эти команды показывают запросы в моменте.А на серваке выполнялись десятки простых SELECT за считанные миллисекунды или ещё быстрее. Не отслеживал. И они тупо не попадали в вывод. И я думал, что запросов мало, а их было дохрена. Они и давали нагрузку на CPU.
Запросы увидел так. Не перезапуская сервер выполнил в консоли mysql:
> SET GLOBAL general_log = 'ON';> SET GLOBAL general_log_file = '/var/log/mysql/general.log';Так же это было видно в выводе:
> SHOW ENGINE INNODB STATUS;В разделе I/O. Эти потоки отвечают за асинхронные операции ввода-вывода (AIO).
Достаточно было на несколько секунд запустить, чтобы понять всю картину. Потом сразу отключил, чтобы не нагружать диски.
Осталось разобраться, а что на диск то записывается. Вроде как файлы
ib_logfile0 это файлы журналов транзакций InnoDB, а разве SELECT вызывает транзакции? Я тут сильно не погружался, но мельком глянул информацию и понял, что всякие очистки устаревших данных, обновление статистики, индексов, хэшей могут тоже провоцировать запись, а точнее обновление этого файла.xb_doublewrite - это некий буфер InnoDB для повышения надёжности хранения, отключать не рекомендуется, хотя можно.
В общем, время я по сути потратил впустую, если не считать вот эту заметку итоговым результатом. Думаю, она мне ещё понадобится. Времени уже не оставалось дальше разбираться с этой историей. В целом, нагрузка там рабочая, абсолютно некритичная, так что разбираться с ней дальше большой нужды не было. Но я всё равно планирую подумать, как её снизить. И вообще не совсем понятно, почему её так много, с учётом того, что сайт активно кэшируется. Надо будет разбираться.
Отдельно отмечу, что очень активно нагружал этой темой DeepSeek, но он особо не помог. Да, много всякой информации давал и анализировал мои результаты, но фактически я сам догадался в чём причина. Он как-то больше по кругу ходил и всякие команды накидывал.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mysql #perfomance
7👍237👎4
На тему LA (Load Average) написано очень много материалов. Про неё любят спрашивать на собеседованиях, писать тематические статьи и проводить уроки различные онлайн школы. Это прям горячая тема. Я когда-то давно в одной переведённой с иностранного материала статье на хабре увидел очень хорошую аналогию LA с загрузкой шоссе машинами и сразу запомнил её. Не встречал с тех пор наглядных объяснений в таком контексте. Расскажу кратко тем, кто до конца не понимает, что эта загрузка означает.
Пара примеров, почему LA неоднозначна. Можно зайти на сервер, увидеть LA под 100, но при этом процессор будет не нагружен вообще. Это тупит примонтированный сетевой диск, например, по NFS или iSCSI. Или LA в 30 может показаться запредельно большой, но если на сервере 36 ядер и нагрузка хоть и большая, но в целом сервер её вывозит.
Для однопроцессорной системы понять логику измерения Load Average можно с помощью картинки во вложении. Для простоты восприятия LA сравнивают с транспортным потоком на мосту. Значение более 1 означает наличие очереди на въезде на мост. Размер этой очереди будет равен превышению единицы. Например, значение 1,7 показывает, что в очереди стоит 70% от числа машин, находящихся на мосту.
В ядре Linux процессы, выполняющиеся в данный момент, это машины на мосту, а процессы, ожидающие очереди на исполнение, это машины в пробке на въезде на мост. Причем очередь из процессов может образовываться не только из-за загруженности процессора, но и других компонентов системы. Например, подсистемы ввода-вывода (диск, сеть).
Идеально, когда пробки нет, никто никого не ждёт, есть запас по пропускной способности моста. Многопроцессорная система - это сумма таких мостов. Каждый увеличивает пропускную способность на единицу. Загрузка 1 для двух мостов означает нагрузку на мосты в 50%, для трёх на 33%. Ну и так далее. Очень просто и наглядно.
Если кто-то знает более простые и наглядные аналогии, расскажите.
И в продолжении этой темы добавлю ссылку на мою недавнюю заметку на тему метрики IOWait. Она тоже очень неоднозначна и может своими показаниями вводить в заблуждение, если не знаешь нюансов. Там, к сожалению, нет простой аналогии, нужно вчитаться и понять без аналогий, о чём идёт речь. Но информация важная, если вам приходится разбираться с производительностью систем на базе Linux.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #perfomance
Пара примеров, почему LA неоднозначна. Можно зайти на сервер, увидеть LA под 100, но при этом процессор будет не нагружен вообще. Это тупит примонтированный сетевой диск, например, по NFS или iSCSI. Или LA в 30 может показаться запредельно большой, но если на сервере 36 ядер и нагрузка хоть и большая, но в целом сервер её вывозит.
Для однопроцессорной системы понять логику измерения Load Average можно с помощью картинки во вложении. Для простоты восприятия LA сравнивают с транспортным потоком на мосту. Значение более 1 означает наличие очереди на въезде на мост. Размер этой очереди будет равен превышению единицы. Например, значение 1,7 показывает, что в очереди стоит 70% от числа машин, находящихся на мосту.
В ядре Linux процессы, выполняющиеся в данный момент, это машины на мосту, а процессы, ожидающие очереди на исполнение, это машины в пробке на въезде на мост. Причем очередь из процессов может образовываться не только из-за загруженности процессора, но и других компонентов системы. Например, подсистемы ввода-вывода (диск, сеть).
Идеально, когда пробки нет, никто никого не ждёт, есть запас по пропускной способности моста. Многопроцессорная система - это сумма таких мостов. Каждый увеличивает пропускную способность на единицу. Загрузка 1 для двух мостов означает нагрузку на мосты в 50%, для трёх на 33%. Ну и так далее. Очень просто и наглядно.
Если кто-то знает более простые и наглядные аналогии, расскажите.
И в продолжении этой темы добавлю ссылку на мою недавнюю заметку на тему метрики IOWait. Она тоже очень неоднозначна и может своими показаниями вводить в заблуждение, если не знаешь нюансов. Там, к сожалению, нет простой аналогии, нужно вчитаться и понять без аналогий, о чём идёт речь. Но информация важная, если вам приходится разбираться с производительностью систем на базе Linux.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #perfomance
3👍181👎3
Вопрос управлением памятью в Linux непростой. У меня уже были в разное время заметки по этой теме. Причём он не только технический, но и организационный. Как раскидать сервисы по виртуалкам и контейнерам? Всегда придётся искать баланс, потому что максимально всё подробить не обязательно будет удобно и эффективно. Но при любом раскладе нужно будет настраивать сами приложения. Покажу на нескольких примерах, как это выглядит на практике у меня.
1️⃣ Начну с MySQL. В качестве калькулятора при подборе настроек я использую MySQLTuner. Он много всего может проверить и посоветовать, но без глубокого понимания работы СУБД, лучше лишний раз не трогать настройки.
Мне главное понять, сколько памяти съест СУБД, если её максимально нагрузить при текущих параметрах. Это MySQLTuner как раз наглядно покажет. Подробно все настройки, на которые стоит обратить внимание в этом контексте, я разбирал в отдельной заметке. Не буду повторяться. Надо настроить так, чтобы MySQL не запросила памяти больше, чем есть на сервере, либо можно позволить выделить с учётом других сервисов, если они там есть. Параметры подбираются по ситуации.
Для PostgreSQL есть много конфигураторов, которые по заявленным характеристикам сервера сами посоветуют параметры, в том числе относящиеся к потреблению памяти. Мне больше всего нравится pgconfigurator.cybertec.at (хостится за CF, нужен VPN).
Есть софт попроще в плане настроек потребления памяти. Например, в Elasticsearch, Redis, Memcached можно одним параметром ограничить память, которую приложение будет использовать.
2️⃣ Дальше у нас идут приложения, которые в зависимости от нагрузки запускают разное количество экземпляров. Наглядным примером тут выступает php-fpm. Его нужно ограничить по количеству процессов, которые он может запустить в пределах отведённой ему памяти. Для этого надо понять, а сколько памяти в текущих условиях занимает один процесс?
Вопрос этот нетривиальный, так как у нас есть общая память, виртуальная память, реальная память. Форки одного процесса частично используют общую память и поэтому в лоб посмотреть в top или htop, сколько один процесс использует реальной памяти, не получится. Хотя для грубого подсчёта может и сойти. Более точно это можно определить с помощью
3️⃣ Отдельно идут приложения, которые не имеют своих настроек потребления памяти. Плюс, они не форкаются под выросшей нагрузкой. Наглядные примеры таких приложений - Nginx, Postfix, Dovecot. Сюда же можно отнести какие-то самописные скрипты, или тот же Fail2Ban. Последнего надо обязательно ограничивать, так как он легко может повесить сервер под нагрузкой.
Если мы хотим для таких приложений настроить ограничения, то можем воспользоваться настройками systemd. Их там несколько, можно очень гибко всё настроить. При определённом лимите можно ограничивать выделение памяти, а если не поможет, то перезапустить сервис или прибить. Тоже подробно это описывал ранее.
☝️ Может показаться, что контейнеры как раз и придумали в том числе для того, чтобы изолировать приложения друг от друга и ограничивать в ресурсах, и не тратить время на тонкую настройку. Частично да, в том числе для этого и придумали. Третий тип приложений отлично ограничивается на уровне выделенных ресурсов, но первые два, особенно СУБД, всё равно для стабильной работы нужно предварительно настроить под выделенные ресурсы.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#perfomance
Мне главное понять, сколько памяти съест СУБД, если её максимально нагрузить при текущих параметрах. Это MySQLTuner как раз наглядно покажет. Подробно все настройки, на которые стоит обратить внимание в этом контексте, я разбирал в отдельной заметке. Не буду повторяться. Надо настроить так, чтобы MySQL не запросила памяти больше, чем есть на сервере, либо можно позволить выделить с учётом других сервисов, если они там есть. Параметры подбираются по ситуации.
Для PostgreSQL есть много конфигураторов, которые по заявленным характеристикам сервера сами посоветуют параметры, в том числе относящиеся к потреблению памяти. Мне больше всего нравится pgconfigurator.cybertec.at (хостится за CF, нужен VPN).
Есть софт попроще в плане настроек потребления памяти. Например, в Elasticsearch, Redis, Memcached можно одним параметром ограничить память, которую приложение будет использовать.
Вопрос этот нетривиальный, так как у нас есть общая память, виртуальная память, реальная память. Форки одного процесса частично используют общую память и поэтому в лоб посмотреть в top или htop, сколько один процесс использует реальной памяти, не получится. Хотя для грубого подсчёта может и сойти. Более точно это можно определить с помощью
pmap. У меня была подробная заметка, где я на конкретном примере показал, как это сделать. Это руководство подойдёт для всех подобных приложений.Если мы хотим для таких приложений настроить ограничения, то можем воспользоваться настройками systemd. Их там несколько, можно очень гибко всё настроить. При определённом лимите можно ограничивать выделение памяти, а если не поможет, то перезапустить сервис или прибить. Тоже подробно это описывал ранее.
☝️ Может показаться, что контейнеры как раз и придумали в том числе для того, чтобы изолировать приложения друг от друга и ограничивать в ресурсах, и не тратить время на тонкую настройку. Частично да, в том числе для этого и придумали. Третий тип приложений отлично ограничивается на уровне выделенных ресурсов, но первые два, особенно СУБД, всё равно для стабильной работы нужно предварительно настроить под выделенные ресурсы.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#perfomance
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
4👍94👎2
☝️ Всё новое – хорошо забытое старое.
Не люблю делать повторы своих старых публикаций, потому что это странно выглядит для тех, кто их уже читал. При этом формат Telegram каналов таков, что к старой информации, если её не сохранили специально, редко кто обращается. Поэтому, чтобы не терять полезную уже написанную информацию, я её оформляю время от времени в подборки для того, чтобы новые читатели тоже имели возможность с ней познакомиться.
В эту подборку я объединил способы решения типовых задач в консоли Linux, которые практически не теряют актуальность со временем. Все заметки написаны лично мной и чаще всего с конкретными практическими примерами. Их имеет смысл сохранить, чтобы потом в нужный момент открыть и выполнить предложенные действия. Я сам таким образом использую эти заметки.
Система в целом:
🔥Профилирование нагрузки в Linux
▪️Краткий список действий, чтобы понять, из-за чего тормозит сервер
▪️Временная нагрузка на сервер с помощью системных утилит для проверки мониторинга
▪️Анализ производительности системы под нагрузкой с помощью sysbench
▪️Прикладные примеры использования lsof для различных задач
Диск:
🔥 Анализ дисковой активности в Linux с помощью btrace, iostat, iotop, pidstat, fatrace, strace
▪️Анализируем нагрузку на диск с помощью perf-tools
▪️Расследование фантомных чтений с диска
▪️Отличный скрипт, который позволит быстро разобраться, кто и чем занял свободное место на сервере
▪️Снижение задержек в SSD дисках
▪️Файл удалили, а место не освободилось
▪️Шпаргалка с командами, если у вас закончилось место на диске
Сеть:
🔥Подборка утилит для просмотра статистики сетевых интерфейсов
▪️Анализ направлений трафика с реальными скоростями с iftop
▪️Анализ сетевой активности с помощью утилит из пакета netsniff-ng
▪️Запись дампа трафика конкретного приложения
Память:
🔥Просмотр использования памяти процессами с помощью pmap
▪️Кто и как использует swap
▪️Уменьшение или увеличение ram на ходу
▪️Удобный скрипт для просмотра использования оперативной памяти программами (не процессами!)
Разное:
▪️Расследование тормозов MySQL сервера
▪️Трассировка медленных запросов в php-fpm
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#подборка #linux #perfomance
Не люблю делать повторы своих старых публикаций, потому что это странно выглядит для тех, кто их уже читал. При этом формат Telegram каналов таков, что к старой информации, если её не сохранили специально, редко кто обращается. Поэтому, чтобы не терять полезную уже написанную информацию, я её оформляю время от времени в подборки для того, чтобы новые читатели тоже имели возможность с ней познакомиться.
В эту подборку я объединил способы решения типовых задач в консоли Linux, которые практически не теряют актуальность со временем. Все заметки написаны лично мной и чаще всего с конкретными практическими примерами. Их имеет смысл сохранить, чтобы потом в нужный момент открыть и выполнить предложенные действия. Я сам таким образом использую эти заметки.
Система в целом:
🔥Профилирование нагрузки в Linux
▪️Краткий список действий, чтобы понять, из-за чего тормозит сервер
▪️Временная нагрузка на сервер с помощью системных утилит для проверки мониторинга
▪️Анализ производительности системы под нагрузкой с помощью sysbench
▪️Прикладные примеры использования lsof для различных задач
Диск:
🔥 Анализ дисковой активности в Linux с помощью btrace, iostat, iotop, pidstat, fatrace, strace
▪️Анализируем нагрузку на диск с помощью perf-tools
▪️Расследование фантомных чтений с диска
▪️Отличный скрипт, который позволит быстро разобраться, кто и чем занял свободное место на сервере
▪️Снижение задержек в SSD дисках
▪️Файл удалили, а место не освободилось
▪️Шпаргалка с командами, если у вас закончилось место на диске
Сеть:
🔥Подборка утилит для просмотра статистики сетевых интерфейсов
▪️Анализ направлений трафика с реальными скоростями с iftop
▪️Анализ сетевой активности с помощью утилит из пакета netsniff-ng
▪️Запись дампа трафика конкретного приложения
Память:
🔥Просмотр использования памяти процессами с помощью pmap
▪️Кто и как использует swap
▪️Уменьшение или увеличение ram на ходу
▪️Удобный скрипт для просмотра использования оперативной памяти программами (не процессами!)
Разное:
▪️Расследование тормозов MySQL сервера
▪️Трассировка медленных запросов в php-fpm
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#подборка #linux #perfomance
Telegram
ServerAdmin.ru
Как и обещал, подготовил заметку по профилированию нагрузки в Linux. Первое, что нужно понимать — для диагностики нужна методика. Хаотичное использование различных инструментов только в самом простом случае даст положительный результат.
Наиболее известные…
Наиболее известные…
1👍184👎2
Я не так давно рассказывал про очень простую и наглядную интерпретацию метрики LA (Load Average). Данную тему будет уместно дополнить более современными метриками – PSI (Pressure Stall Information). Это подсистема ядра Linux, которая отслеживает три наиболее важных ресурса:
▪️CPU
▪️Memory
▪️I/O
В отличие от LA, которая показывает очередь процессов, ожидающих выполнение, PSI измеряет время ожидания процессов при получении доступа к ресурсам, что даёт более точное представление о загрузке системы в режиме реального времени. Плюсом, PSI интегрирована в cgroups, что позволяет мониторить нагрузку отдельных служб и контейнеров.
PSI имеет 3 периода измерений: avg10, avg60, avg300. Это время в секундах, то есть 10 секунд, 1 минута и 5 минут. К периодам прилагаются два типа метрик:
🔹some - процент времени, когда хотя бы один процесс ждёт освобождение ресурсов (line indicates the share of time in which at least some tasks are stalled on a given resource)
🔹full - процент времени, когда все активные процессы находятся в ожидании освобождения ресурсов (line indicates the share of time in which all non-idle tasks are stalled on a given resource simultaneously)
Эти метрики можно и нужно использовать в повседневной работе, наравне с привычными LA, disk r/w, iops. В версии htop, начиная с 3.0.0, можно включить их отображение. По умолчанию они не отображаются. Включаются так:
Открываем htop ⇨ F2 ⇨ Meters ⇨ Aviable Meters ⇨ Выбираем нужные метрики, нажатием Enter ⇨ F10 выйти с сохранением.
В недавнем обновлении Proxmox эти метрики появились на стандартном дашборде.
PSI активно используется в systemd-oomd – современной замене OOM Killer. А точнее помощнике. На основе метрик PSI он более избирательно останавливает процессы, а не ждёт, как OOM Killer, когда закончится память, чтобы прибить самого жирного потребителя при прочих равных условиях.
На практике метрики PSI могут быстро помочь определить узкое место в системе. Например, у вас начала тормозить СУБД. Заходите на сервер и видите высокий LA. Но сама по себе эта метрика не даёт никакой конкретики. Может быть чрезмерно нагружен как процессор, так и диск. Рядом метрики cpu some и io some сразу ответят на вопрос, где у вас узкое место. Если оно реально в CPU, то не придётся лезть в дисковую подсистему и смотреть, что там происходит.
Изменение метрик в режиме реального времени позволяют сразу же оценить какие-то свои изменения и посмотреть, как они повлияли на нагрузку. В общем, это полезные метрики, которые имеет смысл по умолчанию выводить в htop. Не знаю, есть ли они в обычном top. Я на все свои сервера без исключения ставлю htop. Очень к нему привык. Там и PSI, и вкладка I/O с активностью диска, и lsof для просмотра открытых файлов, и strace. В общем, очень удобно.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #perfomance
▪️CPU
▪️Memory
▪️I/O
В отличие от LA, которая показывает очередь процессов, ожидающих выполнение, PSI измеряет время ожидания процессов при получении доступа к ресурсам, что даёт более точное представление о загрузке системы в режиме реального времени. Плюсом, PSI интегрирована в cgroups, что позволяет мониторить нагрузку отдельных служб и контейнеров.
PSI имеет 3 периода измерений: avg10, avg60, avg300. Это время в секундах, то есть 10 секунд, 1 минута и 5 минут. К периодам прилагаются два типа метрик:
🔹some - процент времени, когда хотя бы один процесс ждёт освобождение ресурсов (line indicates the share of time in which at least some tasks are stalled on a given resource)
🔹full - процент времени, когда все активные процессы находятся в ожидании освобождения ресурсов (line indicates the share of time in which all non-idle tasks are stalled on a given resource simultaneously)
Эти метрики можно и нужно использовать в повседневной работе, наравне с привычными LA, disk r/w, iops. В версии htop, начиная с 3.0.0, можно включить их отображение. По умолчанию они не отображаются. Включаются так:
Открываем htop ⇨ F2 ⇨ Meters ⇨ Aviable Meters ⇨ Выбираем нужные метрики, нажатием Enter ⇨ F10 выйти с сохранением.
В недавнем обновлении Proxmox эти метрики появились на стандартном дашборде.
PSI активно используется в systemd-oomd – современной замене OOM Killer. А точнее помощнике. На основе метрик PSI он более избирательно останавливает процессы, а не ждёт, как OOM Killer, когда закончится память, чтобы прибить самого жирного потребителя при прочих равных условиях.
На практике метрики PSI могут быстро помочь определить узкое место в системе. Например, у вас начала тормозить СУБД. Заходите на сервер и видите высокий LA. Но сама по себе эта метрика не даёт никакой конкретики. Может быть чрезмерно нагружен как процессор, так и диск. Рядом метрики cpu some и io some сразу ответят на вопрос, где у вас узкое место. Если оно реально в CPU, то не придётся лезть в дисковую подсистему и смотреть, что там происходит.
Изменение метрик в режиме реального времени позволяют сразу же оценить какие-то свои изменения и посмотреть, как они повлияли на нагрузку. В общем, это полезные метрики, которые имеет смысл по умолчанию выводить в htop. Не знаю, есть ли они в обычном top. Я на все свои сервера без исключения ставлю htop. Очень к нему привык. Там и PSI, и вкладка I/O с активностью диска, и lsof для просмотра открытых файлов, и strace. В общем, очень удобно.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #perfomance
4👍143👎2
Заметил, как на одном небольшом веб сервере постоянно занят весь swap, хотя использование оперативной памяти там сбалансировано и явного недостатка не возникает. Решил повнимательнее посмотреть, что там происходит и почему складывается такая ситуация. Интуитивно кажется, что swap не должен использоваться, тем более на весь объём, если оперативной памяти достаточно, но это не совсем так.
В данном случае речь пойдёт про типовой веб сервер всё в одном: MariaDB + Angie + PHP-fpm и некоторые сопутствующие сервисы для обеспечения безопасности, мониторинга и сбора логов.
Первым делом смотрю, кто занимает swap. В заметке по ссылке всё описано, не буду подробно останавливаться на этом. Кратко можно посмотреть прямо в консоли:
Первая строка - главный потребитель swap. В моём случае процесс mariadbd. Смотрим состояние памяти:
В системе 4GB оперативной памяти и 1GB swap. При этом доступно более 1GB оперативной памяти. По логике хотя бы её часть ещё могла бы использоваться вместо свопа.
За то, как активно система использует swap, отвечает параметр ядра vm.swappiness. Смотрим текущее значение:
По умолчанию разработчики Linux его ставят в значении 60. Оно обеспечивает баланс между swap и page cache. Напомню, для тех, кто не знает или забыл, что свободная оперативная память в Linux не простаивает, а используется под статический кэш, называемый page cache. Туда попадают данные, к которым чаще всего обращаются процессы, запущенные в системе. Таким образом снижается нагрузка на диски и уменьшается время доступа к этим данным.
Самой частой и очевидной рекомендацией по снижению использования свопа является уменьшение параметра vm.swappiness, например, до 10-ти. В этом случае данные в swap будут уходить только при очень серьёзном дефиците доступной оперативной памяти.
Казалось бы, уменьшай vm.swappiness, что тут думать. Но не всё так просто. Уменьшение использования swap уменьшит и размер доступной памяти под page cache. А в случае смешанной нагрузки на сервер, особенно со статикой от сайтов, не факт, что так будет лучше. Итоговая производительность всех сервисов может наоборот снизиться. Измерить результат в конкретных метриках очень сложно.
При таких вводных становится понятно, что если есть возможность и целесообразность, то разнородные сервисы лучше разделять по разным виртуалкам. Если у вас на сервере только СУБД и памяти хватает, то можно особо не заморачиваться и реально ставить vm.swappiness = 10. По моим представлениям это практически всегда пойдёт только в плюс производительности. Если СУБД чётко настроить под конкретные параметры виртуальной машины, она не будет выходить за свои лимиты настроенных ресурсов.
А вот если у вас разнородные сервисы, нагрузка смешанная, много чтений мелких файлов с диска, есть всплески нагрузки, то уже однозначно не ответить, как лучше поступить. Я лично не стал трогать vm.swappiness, оставил значение по умолчанию в 60. Не знаю точно, что СУБД сгружает в swap. По логике это должно быть что-то не очень важное и требовательное, раз СУБД решила не забирать память под кэши, а сгрузила их в swap. Ну и плюс, проходить внезапные пики потребления памяти будет проще, когда есть запас.
Если тоже задавались этим вопросом, то что в итоге для себя решили с использованием swap?
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#perfomance #webserver
В данном случае речь пойдёт про типовой веб сервер всё в одном: MariaDB + Angie + PHP-fpm и некоторые сопутствующие сервисы для обеспечения безопасности, мониторинга и сбора логов.
Первым делом смотрю, кто занимает swap. В заметке по ссылке всё описано, не буду подробно останавливаться на этом. Кратко можно посмотреть прямо в консоли:
# for file in /proc/*/status ; do awk '/VmSwap|Name/{printf $2 " " $3} END { print ""}' $file; done | sort -k 2 -n -r | lessПервая строка - главный потребитель swap. В моём случае процесс mariadbd. Смотрим состояние памяти:
# free -m
total used free shared buff/cache available
Mem: 3915 2731 185 89 1373 1183
Swap: 976 906 69В системе 4GB оперативной памяти и 1GB swap. При этом доступно более 1GB оперативной памяти. По логике хотя бы её часть ещё могла бы использоваться вместо свопа.
За то, как активно система использует swap, отвечает параметр ядра vm.swappiness. Смотрим текущее значение:
# sysctl vm.swappinessvm.swappiness = 60По умолчанию разработчики Linux его ставят в значении 60. Оно обеспечивает баланс между swap и page cache. Напомню, для тех, кто не знает или забыл, что свободная оперативная память в Linux не простаивает, а используется под статический кэш, называемый page cache. Туда попадают данные, к которым чаще всего обращаются процессы, запущенные в системе. Таким образом снижается нагрузка на диски и уменьшается время доступа к этим данным.
Самой частой и очевидной рекомендацией по снижению использования свопа является уменьшение параметра vm.swappiness, например, до 10-ти. В этом случае данные в swap будут уходить только при очень серьёзном дефиците доступной оперативной памяти.
Казалось бы, уменьшай vm.swappiness, что тут думать. Но не всё так просто. Уменьшение использования swap уменьшит и размер доступной памяти под page cache. А в случае смешанной нагрузки на сервер, особенно со статикой от сайтов, не факт, что так будет лучше. Итоговая производительность всех сервисов может наоборот снизиться. Измерить результат в конкретных метриках очень сложно.
При таких вводных становится понятно, что если есть возможность и целесообразность, то разнородные сервисы лучше разделять по разным виртуалкам. Если у вас на сервере только СУБД и памяти хватает, то можно особо не заморачиваться и реально ставить vm.swappiness = 10. По моим представлениям это практически всегда пойдёт только в плюс производительности. Если СУБД чётко настроить под конкретные параметры виртуальной машины, она не будет выходить за свои лимиты настроенных ресурсов.
А вот если у вас разнородные сервисы, нагрузка смешанная, много чтений мелких файлов с диска, есть всплески нагрузки, то уже однозначно не ответить, как лучше поступить. Я лично не стал трогать vm.swappiness, оставил значение по умолчанию в 60. Не знаю точно, что СУБД сгружает в swap. По логике это должно быть что-то не очень важное и требовательное, раз СУБД решила не забирать память под кэши, а сгрузила их в swap. Ну и плюс, проходить внезапные пики потребления памяти будет проще, когда есть запас.
Если тоже задавались этим вопросом, то что в итоге для себя решили с использованием swap?
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#perfomance #webserver
Please open Telegram to view this post
VIEW IN TELEGRAM
4👍130👎4