Вопрос управлением памятью в 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👍185👎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👍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