Как системному администратору оптимизировать сервер

Откуда берутся советы, которые ломают сервер?

Ответ сразу: большая часть вредных рекомендаций по оптимизации родилась в эпоху других объёмов памяти и медленных дисков, а потом расползлась по форумам без описания условий, в которых она работала. Совет копируют вместе с чужими цифрами, переносят на другую нагрузку и получают машину, которая тормозит сильнее прежней. Проверяется такой совет ровно одним способом: измерением до правки и после неё.

Схема повторяется годами. Администратор видит рост нагрузки, ищет решение в поиске, попадает на ветку форума десятилетней давности и вставляет чужой блок настроек в свой конфиг. Иногда становится лучше. Объяснить, почему именно, при этом не может никто.

У плохих рекомендаций есть общий признак: они говорят, что крутить, и молчат про условия. Сколько ядер, сколько оперативной памяти, какой профиль запросов, что показывал мониторинг до правки. Без этих деталей настройка превращается в лотерею с ценой в виде ночного простоя.

Вторая причина проще. Оптимизацию путают с закупкой: кажется, что производительность покупается за деньги, а настройка вторична. Отсюда берутся серверы с избытком памяти, которые упираются в один медленный диск. Базовый набор навыков, который закрывает эти пробелы, я разбирал в материале про то, что изучать системному администратору.

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

• железо вылечит любую медлительность;
• swap надо отключить полностью;
• больше рабочих процессов равно выше скорость;
• готовый конфиг из интернета подходит любой базе данных.

Правда ли, что достаточно докупить память и процессор?

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

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

Понять это можно за десять минут наблюдения. Инструменты давно стандартные:

1. htop покажет, кто ест процессор и память прямо сейчас.
2. vmstat и iostat расскажут про очередь к дискам и активность подкачки.
3. Netdata даёт живую картину по секундам, удобно ловить короткие всплески.
4. Prometheus и Zabbix хранят историю, по ней видно, когда деградация началась.

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

Отдельная ловушка: часть медленных ответов создаёт само приложение. Сервис на тяжёлом стеке потребляет больше памяти на тот же запрос, чем компактный бинарник, и это одна из причин, по которым крупные команды пересматривают язык серверной части. Тему сравнения платформ я разбирал в статье о том, почему крупные компании переходят на Go.

Источник: описание системных утилит наблюдения на официальных страницах руководств Linux.

Нужно ли отключать swap, чтобы сервер перестал тормозить?

Ответ сразу: полное отключение подкачки скорости не добавляет и лишает сервер страховки на случай всплеска потребления памяти. Когда своп выключен, ядро при нехватке памяти вызывает механизм принудительного завершения процессов, и первым падает самый прожорливый сервис, обычно база данных. Поведением подкачки управляют параметром vm.swappiness, значение подбирают под роль машины.

Миф вырос из реальной боли: если сервер активно ушёл в подкачку, отклик действительно проваливается. Только причина тут в дефиците памяти, и лечится она добавлением памяти или разгрузкой сервисов. Выключение свопа убирает индикатор проблемы и оставляет саму проблему на месте.

Значение vm.swappiness по умолчанию равно 60. Для машины с базой данных его часто снижают, чтобы ядро реже вытесняло страницы приложения на диск, но снижение до нуля означает почти полный отказ от подкачки со всеми последствиями. Разумная тактика: уменьшить значение, неделю понаблюдать за графиками, зафиксировать результат.

Смежная ошибка того же рода звучит как «оперативная память забита, надо срочно чистить». Linux сознательно занимает свободную память под кэш файловой системы и отдаёт её приложениям по требованию. Заполненный кэш тут говорит о здоровье системы.

Источник: раздел про параметры виртуальной памяти в документации ядра Linux.

Ускорится ли сайт, если поднять число рабочих процессов?

Ответ сразу: рост числа воркеров ускоряет отдачу только до тех пор, пока хватает ядер и памяти. Дальше процессы начинают конкурировать за одни и те же ресурсы, растёт время переключения контекста, а при исчерпании памяти сервер уходит в подкачку и падает. Документация nginx советует в спорной ситуации отталкиваться от числа доступных ядер и предупреждает, что оптимальное значение зависит ещё от дисков и профиля запросов.

Совет «поставь побольше воркеров» обычно приходит с форума вместе с готовым числом. У автора той рекомендации была своя машина, свой профиль запросов и своё железо. У вас всё другое.

В nginx по умолчанию поднимается один рабочий процесс, а значение auto пробует само определить число доступных ядер и запустить процесс на каждое. Тот же принцип действует и для пулов процессов приложения. Максимальное число дочерних процессов считают от объёма памяти: делят доступный объём на среднее потребление одного процесса и оставляют запас для системы и базы данных.

Проверка простая. Поднимаете значение на шаг, гоняете нагрузочный тест, смотрите на время ответа и на потребление памяти. Если время ответа перестало улучшаться, дальше расти бессмысленно. Такие замеры обычно делают вместе с командой тестирования: как устроена эта работа, разобрано в материале о том, как стать тестировщиком ПО с нуля.

Источник: директива worker_processes в официальной документации nginx.

Можно ли взять готовый конфиг базы данных из интернета?

Ответ сразу: чужой конфиг базы данных подходит вам ровно настолько, насколько ваша машина похожа на машину его автора. Ключевые параметры считаются от объёма оперативной памяти, характера запросов и типа дисков, поэтому копирование блока настроек с форума либо не даёт эффекта, либо выводит сервер за пределы доступной памяти. Считать нужно по своим цифрам.

Возьмём PostgreSQL. Официальная документация называет разумной стартовой точкой для параметра shared_buffers примерно четверть оперативной памяти, если сервер отдан базе целиком и памяти на нём не меньше гигабайта. На машине с общей нагрузкой цифра будет другой, а отдавать под этот параметр больше 40 процентов памяти документация смысла не видит. Слепо скопированное значение с чужого сервера ломает баланс между кэшем базы и кэшем файловой системы.

Похожая история с размером пула буферов в MySQL и с настройками журналирования. Каждый такой параметр меняют по одному, с фиксацией результата, желательно на тестовом стенде под воспроизводимой нагрузкой.

Отдельно про запросы. Правка конфига не спасёт базу от отсутствующего индекса и от выборки всей таблицы на каждой странице сайта. Профилирование медленных запросов почти всегда даёт больший выигрыш, чем тонкая настройка сервера.

Источник: параметры потребления ресурсов в документации PostgreSQL.

Что на самом деле повышает производительность сервера?

Ответ сразу: работает короткий цикл из четырёх шагов: измерить, изменить один параметр, измерить снова, зафиксировать в документации. Поверх этого цикла лежит базовая гигиена: кэширование, отдача статики через сеть доставки, выключение лишних служб, автоматические обновления и резервные копии, балансировка нагрузки при росте трафика. Ничего экзотического в этом списке нет.

Сначала сведу разобранные мифы в одно сопоставление.

1. Миф: железо вылечит всё. Как есть: покупка помогает после того, как мониторинг показал упор именно в процессор, память или диск.
2. Миф: swap надо отключить. Как есть: подкачку оставляют как страховку, её агрессивность настраивают параметром ядра.
3. Миф: чем больше воркеров, тем быстрее. Как есть: число процессов считают от ядер и доступной памяти, потолок ищут нагрузочным тестом.
4. Миф: чужой конфиг подойдёт. Как есть: параметры базы данных пересчитывают под свою память, свои диски и свой профиль запросов.
5. Миф: оптимизация делается один раз. Как есть: нагрузка меняется вместе с бизнесом, поэтому проверки повторяют по расписанию.

Теперь про базовую гигиену, которая даёт эффект почти всегда:

• Кэширование. Готовые ответы отдаются без обращения к базе, нагрузка на процессор падает заметно.
• Сеть доставки контента. Картинки, стили и скрипты уезжают с вашего канала на распределённые узлы.
• Лишние службы. Всё, что не нужно роли сервера, выключается: меньше процессов, меньше памяти, меньше открытых портов.
• Обновления и резервные копии. Ставятся по расписанию, копии проверяются восстановлением, иначе они существуют только на бумаге.
• Балансировка нагрузки. При устойчивом росте трафика запросы распределяют между несколькими машинами.

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

Ещё одна привычка, которая экономит недели: журнал изменений. Дата, параметр, старое значение, новое значение, что показали графики через сутки. Через полгода этот файл отвечает на вопрос «почему тут стоит именно такая цифра» лучше любой памяти.

Как отличить плохой совет по оптимизации от рабочего?

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

Вот эти вопросы:

1. Для какой роли сервера написан совет и какое там было железо?
2. Какая метрика улучшилась и на сколько, есть ли замеры до и после?
3. Какого года рекомендация и совпадает ли версия софта с вашей?
4. Что произойдёт при откате, сохранена ли копия конфига?
5. Есть ли подтверждение в официальной документации продукта?

Последний пункт закрывает половину случаев. Документация nginx, PostgreSQL, MySQL и ядра Linux открыта, читается за вечер и почти всегда объясняет, от чего зависит значение параметра. Форум объясняет редко.

Правило одного изменения тоже стоит держать в голове. Меняете один параметр, ждёте характерный цикл нагрузки, смотрите графики. Правка сразу пяти строк даёт результат, который невозможно разложить на составляющие.

И про инфраструктуру вокруг вас. Многие серверные сервисы сегодня пишут на компактных языках со скромным потреблением памяти: тем, кому интересно посмотреть на эту сторону, пригодится обзор того, где используется язык Go, и дорожная карта для начинающего разработчика на Go. Понимание приложения сокращает поиск узкого места.

Вопросы, которые задают чаще всего

Как часто проверять состояние сервера?

Автоматический мониторинг работает постоянно и сам присылает оповещение при выходе метрики за порог. Глазами графики смотрят раз в неделю: так видно медленный тренд, который не срабатывает по порогу, но за месяц съедает запас по памяти или месту на диске.

Что делать, если сервер тормозит только в часы пик?

Снимите показания именно в пик, а не в спокойное время. Дальше сравните графики процессора, диска и сети с журналом запросов за тот же интервал. Чаще всего в пик всплывает конкуренция за диск или блокировки в базе данных, и лечится это кэшированием либо распределением нагрузки между машинами.

Даёт ли переход на твердотельные накопители реальный выигрыш?

Даёт, когда узкое место в дисковых операциях: базы данных и файловые хранилища выигрывают заметно. Если сервер упирается в процессор или в медленный внешний сервис, замена дисков почти ничего не изменит. Порядок действий прежний: сначала измерение, потом закупка.

Нужна ли оптимизация, если пользователей пока мало?

Базовые вещи настраивают сразу: мониторинг, резервные копии, выключение лишних служб, обновления. Это дешевле сделать на спокойном сервере, чем в аварийном режиме под нагрузкой. Тонкую настройку параметров откладывают до появления реальной статистики, иначе вы оптимизируете то, чего ещё нет. Тем, кто только осваивает технику и хочет подтянуть базу, полезен разбор про обучение компьютеру для взрослых.

Источники

• Страницы руководств Linux, описание утилит наблюдения за нагрузкой.
• Документация ядра Linux, параметры виртуальной памяти и подкачки.
• Документация nginx, директива worker_processes.
• Документация PostgreSQL, потребление ресурсов и shared_buffers.