Я не так давно рассказывал про очень простую и наглядную интерпретацию метрики 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👍144👎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👍133👎4