Отсутствующий файл подкачки, из-за которого зависли наши серверы

24 сентября один из наших продакшен-серверов перестал отвечать. Балансировщик нагрузки пометил его как нездоровый, а наш инструмент удалённых команд не мог до него достучаться, но ничего не упало и никакой процесс не был убит за избыток памяти. Сервер находился в состоянии трэшинга: без области подкачки и при том, что контейнерам разрешалось использовать больше памяти, чем было на машине, Linux тратил время на вытеснение и повторное чтение файлов, нужных для работы, и почти не продвигался. Добавление файла подкачки на 2 ГБ на каждом сервере всё исправило. Более интересный урок касался проверок работоспособности.

Как выглядело «зависание»

• Проверки работоспособности балансировщика на этом сервере истекали по таймауту.
• Команды, отправленные через AWS Systems Manager, висели в статусе «Pending» и так и не выполнялись.
• В логах не было убийства из-за нехватки памяти. Ни один процесс не погиб.

За неделю до этого мы перевели продакшен на меньшие ARM-серверы с 2 ГБ оперативной памяти у каждого. Наш стейджинг-сервер, ещё меньший, точно так же зависал во время распаковки образа контейнера при деплое.

Почему без ошибки памяти?

Linux убивает процесс только тогда, когда действительно заканчивается память, которую можно освободить. До этого момента он освобождает память из page cache — копий файлов, которые ядро держит в RAM, включая код каждой запущенной программы.

На наших серверах суммарные лимиты памяти контейнеров составляли около 3,3 ГБ при примерно 1,8 ГБ доступных на машине. Обычно все они не используют свой лимит одновременно. Когда же использовали, ядро постоянно вытесняло код программ из кэша, чтобы освободить место, а в момент, когда этот код снова запускался, его приходилось читать с диска. Этот цикл — трэшинг — может сделать машину почти полностью неотзывчивой, при этом формально память не заканчивается. Поэтому ничего не убивается и ничего не восстанавливается.

Без подкачки ядру некуда деть память, которая выделена, но редко используется, поэтому ему приходится забирать её из кэша.

Исправление

Скрипт первоначальной настройки сервера теперь создаёт файл подкачки 2 ГБ с низким значением swappiness (10) каждый раз, когда сервер загружается или восстанавливается. Низкий swappiness означает, что ядро по-прежнему предпочитает держать рабочую память в RAM, но редко используемые страницы могут переехать на диск, вместо того чтобы вытеснять код программ из кэша. Мы применили это на лету к обоим продакшен-серверам и стейджингу, а конвейер деплоя переопубликовывает скрипт настройки при каждом деплое в продакшен, чтобы заменённый сервер тоже его получил.

Что беспокоило нас больше: нездоровый сервер остался

Наша группа серверов использовала проверки работоспособности EC2 — «работает ли машина?» — а не проверки балансировщика — «отвечает ли она на запросы?». Поэтому сервер, от которого отказался балансировщик, для группы оставался здоровым. Его никогда бы не заменили. Продакшен тихо работал бы на одном сервере, пока кто-нибудь не заметил бы и не перезагрузил второй.

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

Поэтому пока мы добавили в чек-лист деплоя шаг: после каждого деплоя проверять работоспособность каждой цели на балансировщике, а не только то, прошла ли задача деплоя. Если команды к серверу висят в статусе «Pending», он трэшит — перезагрузите его; он уже выведен из ротации.

Что мы из этого вынесли

• «Не падает» — не значит «здоров». Трэшинг не даёт ошибок, только такую медлительность, что машина перестаёт отвечать.
• Маленьким серверам нужна подкачка. Даже небольшая, с низким swappiness, даёт ядру место, куда положить холодную память.
• Лимиты памяти, которые в сумме больше, чем у машины, — это ставка. Иногда вы её проигрываете. Знайте, когда вы её сделали.
• Знайте, какой проверке здоровья доверяет автомасштабирование. Проверка, которая спрашивает только «включена ли ВМ?», не заменит сервер, который перестал работать.