Заметил, как на одном небольшом веб сервере постоянно занят весь swap, хотя использование оперативной памяти там сбалансировано и явного недостатка не возникает. Решил повнимательнее посмотреть, что там происходит и почему складывается такая ситуация. Интуитивно кажется, что swap не должен использоваться, тем более на весь объём, если оперативной памяти достаточно, но это не совсем так.

В данном случае речь пойдёт про типовой веб сервер всё в одном: 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.swappiness
vm.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: 📱 Telegram | 🌐 Сайт | 📲 MAX

#perfomance #webserver

Думаю, все уже слышали или знают такой продукт, как Angie. Это веб сервер, форк Nginx, который развивается, насколько я понимаю, независимо от него. Я уже давно нигде не устанавливаю Nginx. Если только по привычке на тестах каких-нибудь, потому что он есть в базовых репах дистрибутивов, а Angie - нет. В работу везде ставлю Angie, потому что он функциональнее и удобнее Nginx.

Мне сейчас сходу трудно перечислить ключевые отличия от Nginx, потому что за последним банально перестал следить. Мне лично Angie сразу понравился в первую очередь тем, что там:

🔹Удобнее устанавливать дополнительные модули. Они все упакованы в пакеты в едином репозитории. Просто берёшь, ставишь и настраиваешь. В то время, как Nginx приходилось собирать самому с нужными модулями.

🔹У Angie реализован экспорт метрик для мониторинга, плюс панель веб управления, где своя визуализация некоторых метрик и настроек. Я сделал себе шаблон для Zabbix, но после того, как разработчики опубликовали свой дашборд для Grafana, перешёл на него, так как стало лень поддерживать свой шаблон самому. А тут всё уже есть в готовом виде.

🔹Над Angie активно работают и улучшают, в том числе полностью бесплатную open source версию. Бесплатный Nginx после продажи компании F5 как-будто развивать вообще перестали и просто поддерживают на плаву.

Сейчас Angie умеет, как и Traefik, проксировать запросы в Docker контейнеры на основании их меток. На этой теме последний поднялся в своё время, потому что никто так больше не умел. Я недавно случайно увидел эту возможность. Не знаю, когда она появилось, но это удобно.

Про настройку Angie написал отличный содержательный цикл статей Лавлинский Николай. Его материалы, как и анонсы вебинаров Отуса с его участием, можно периодически наблюдать на моём канале.

Каждая статья содержит как текстовое описание, так и подробное видео с примерами. Очень содержательный материал. Рекомендую. Я смотрел все видео. Там и по базовой, и не только, настройки есть всё, что нужно. Цикл опубликован на Хабре:

◽️Почему стоит переходить на Angie.
◽️Установка Angie из пакетов и в докере.
◽️Переезд с Nginx на Angie. Пошаговая инструкция.
◽️Настройка location в Angie. Разделение динамических и статических запросов.
◽️Перенаправления в Angie: return, rewrite и примеры их применения.
◽️Сжатие текста в Angie: статика, динамика, производительность.
◽️Серверное кэширование в Angie: тонкости настройки.
◽️Настройка TLS в Angie: безопасность и скорость.
◽️Настройка Angie в роли обратного HTTP-прокси.
◽️Балансировка нагрузки для HTTP(S) в Angie.
◽️Мониторинг Angie с помощью Console Light и API.
◽️Балансировка и проксирование L4-трафика в Angie.
◽️Клиентское кэширование в Angie.
◽️Динамические группы проксируемых серверов в Angie.
◽️Мониторинг Angie с Prometheus и Grafana.

Немного не в тему, но добавлю ещё одну интересную ссылку с полезным материалом:

⇨ Ещё одно тестирование Angie, HAProxy, Envoy, Caddy и Traefik от Devhands
HAProxy показывает наиболее сбалансированные и стабильные результаты на стандартных настройках. Старый, проверенный универсальный балансировщик.

Если всё ещё используете Nginx, рекомендую попробовать Angie. Переезд на него не требует практически никаких изменений конфигурации. Возможно где-то только пути придётся поправить с /etc/nginx на /etc/angie, а может и этого не придётся в зависимости от структуры вашей конфигурации.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#webserver #angie #отечественное

Ранее я уже рассказывал про Small HTTP server. Это необычный веб сервер из далёкого виндового прошлого 90-х годов, который до сих пор поддерживается, немного развивается, и за это время оброс дополнительной функциональностью. Я с тех пор подписался на канал автора и наблюдал, как время от времени выходят обновления.

Проект меня заинтересовал. В первую очередь тем, что там из дополнительной функциональности заявлен HTTP TLS VPN сервер с небольшим VPN клиентом под Windows и Linux. С учётом того, что продукт этот мало кому известен, подумал, что это может быть полезным. Забегая вперёд скажу, что у меня не получилось его настроить, потому что надоело разбираться с продуктом, для которого толком нет документации и примеров настройки. В какой-то момент не захотелось дальше время тратить.

Стало жаль терять то, что уже сделал, поэтому решил написать публикацию. Автор выкладывает исходники и deb пакеты для запуска сервера под Linux. Но у меня не получилось установить из готового пакета, потому что он хочет старую версию libssl, которой в современной системе нет. А если берёшь старую систему, то не подходит версия libgnutls, так как требуется более новая.

Судя по всему автор собирает всё это сам с явным подключением нужных версий. Я в итоге нашёл конфигурацию дистрибутива, куда удалось автоматом всё установить из пакетов и не собирать вручную. Завернул всё это в Dockerfile и оформил в виде Docker Compose.

Выложил всё на Gitflic, там же и описание запуска:

⇨ https://gitflic.ru/project/serveradmin/smallsrv

Клонируете себе репозиторий:

# git clone https://gitflic.ru/project/serveradmin/smallsrv.git
# cd smallsrv

При необходимости правите конфигурацию сервера в файле httpd.cfg, наполняете директорию www/. Если туда не положить файл index.html, то будет работать простой листинг файлов. Можно в качестве простого файлового сервера использовать.

После этого запускаете:

# docker compose up -d

Будет собран локальный образ и запущен контейнер. Если надо что-то настроить в контейнере, то зайдите в него:

# docker exec -it smallsrv bash

Если измените конфигурацию сервера, контейнер нужно будет перезапустить:

# docker restart smallsrv

Не знаю, пригодится ли это кому-нибудь, но раз уж сделал, то выкладываю. Это, кстати, наглядный пример того, зачем может пригодиться Docker. А то частенько спрашивают люди, зачем он нужен, если ты не разработчик и не работаешь с микросервисами.

С помощью Docker очень легко упаковать приложение в преднастроенную среду и не мучать пользователей с настройкой. Причём сделать это может и человек со стороны. Теперь можно без проблем запустить приложение на любом линуксе.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#webserver #vpn