Відсутній файл підкачки, через який зависали наші сервери

Двадцять четвертого вересня один із наших виробничих серверів перестав відповідати. Балансувальник навантаження позначив його як несправний, а наш інструмент віддалених команд не міг до нього достукатися, але нічого не впало і жоден процес не був убитий за надмірне використання пам'яті. Сервер трешив: без простору підкачки (swap), а контейнерам дозволялося використовувати більше пам'яті, ніж мала машина, Linux витрачав час на витіснення та повторне читання файлів, які потрібні для роботи, і майже не просувався. Додавання файлу підкачки 2 ГБ на кожен сервер вирішило проблему. Цікавішим був урок про перевірки здоров'я.

Як виглядало «зависання»

• Перевірки здоров'я балансувальника на тому сервері завершувалися тайм-аутом.
• Команди, надіслані через AWS Systems Manager, висіли в стані «Pending» і не виконувалися.
• У журналах не було нестачі пам'яті. Жоден процес не загинув.

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

Чому немає помилки пам'яті?

Linux убиває процес лише тоді, коли справді закінчується пам'ять, яку можна звільнити. До цього моменту він звільняє пам'ять із кешу сторінок, тобто копій файлів, які ядро тримає в оперативній пам'яті, включно з кодом кожної запущеної програми.

На наших серверах сумарні ліміти пам'яті контейнерів становили близько 3,3 ГБ на машині з приблизно 1,8 ГБ придатної пам'яті. Зазвичай вони не використовують свій ліміт усі разом. Коли використовували, ядро постійно витісняло код програм із кешу, щоб звільнити місце, а потім мусило знову читати його з диска, щойно той код знову запускався. Цей цикл, трешинг, може зробити машину майже повністю непрацездатною, хоча формально пам'ять не закінчується. Тому нічого не вбивається і нічого не відновлюється.

Без swap ядро не має куди подіти пам'ять, яка виділена, але рідко використовується, тому беремо її з кешу.

Виправлення

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

Що турбувало нас більше: несправний сервер залишився

Наша група серверів використовувала перевірки здоров'я EC2, тобто «чи працює машина?», а не перевірки здоров'я балансувальника, тобто «чи відповідає вона на запити?». Тож сервер, від якого балансувальник відмовився, для групи все ще був здоровим. Його ніколи б не замінили. Продакшен тихо працював би на одному сервері, доки хтось не помітив би це і не перезавантажив інший.

Перемкнути групу на перевірки здоров'я балансувальника звучить як очевидне виправлення, але для нас це непросто: під час розгортання сервери навмисно відповідають на свою кінцеву точку здоров'я помилкою, щоб балансувальник їх вивів з ротації (див. як ми досягли розгортань без помилок 502). Група, яка замінює сервери за цим сигналом, замінювала б їх посеред кожного розгортання.

Тож поки що ми додали до чеклиста розгортання крок: після кожного розгортання перевіряти здоров'я кожної цілі на балансувальнику, а не лише те, чи пройшло завдання розгортання. Якщо команди до сервера висять у «Pending», він трешить: перезавантажте його, він уже виведений з ротації.

Що ми з цього взяли

• «Не падає» не означає «здоровий». Трешинг не дає помилок, лише таку повільність, що машина перестає відповідати.
• Малим серверам потрібен swap. Навіть невеликий, з низькою swappiness, дає ядру куди покласти холодну пам'ять.
• Ліміти пам'яті, що в сумі перевищують машину, це ставка. Іноді ви її програєте. Знайте, коли ви її зробили.
• Знайте, якій перевірці здоров'я довіряє ваше автомасштабування. Перевірка, яка питає лише «чи ввімкнена віртуальна машина», не замінить сервер, що перестав працювати.