Как мы решили проблемы с серверами в 2024 году

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

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

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

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

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

Проверка теорий
Мы проверили гипотезы об оборудовании. Может ли это быть специфично для определенных марок серверов? Проблемы возникали в системах Lenovo, Dell и HPE и не были связаны с проблемами жесткого диска. Может быть, определенные местоположения центров обработки данных? Никакой закономерности. Мы рассмотрели различные версии ОС и программного обеспечения для виртуализации, но также не было четкой причины. Даже когда мы проанализировали, как разные клиенты использовали свои серверы, мы не смогли обнаружить никаких значимых закономерностей.

Первый прорыв произошел, когда мы изменили Proxmox и версию ядра Linux, которую мы используем на наших серверах vhost. Стабильность в целом улучшилась, но теперь у серверов начали возникать совершенно другие проблемы с производительностью. Наша целевая группа продолжала копать, изучая шаблоны управления памятью.

Понимание управления памятью
Танец памяти
Прежде чем продолжить наш рассказ, давайте объясним, что такое управление памятью.

В производственных средах управление памятью — это осторожный балансирующий акт. ЦП постоянно дирижирует сложным танцем, перемещая данные между ОЗУ и подкачкой. Активные приложения остаются в быстрой ОЗУ, а неактивные перемещаются в более медленное пространство подкачки на основе шаблонов использования.

Эта координация происходит тысячи раз в секунду, обычно без чьего-либо внимания. Это отраслевой стандарт, используемый в облачных вычислениях на протяжении десятилетий. Этот подход RAM-плюс-своп обрабатывает все, от небольших сайтов WordPress до загруженных баз данных и далее.

Обещание ZRAM
Введите ZRAM — стандартную функцию ядра Linux, разработанную для того, чтобы сделать управление памятью еще более эффективным. Сжимая данные прямо в самой RAM, он предлагает на 25% больше емкости. Подумайте об этом так: в то время как swap используется для хранения менее используемых данных вне RAM, ZRAM сжимает данные, чтобы хранить больше их в RAM.

Раскрытие настоящего виновника
Теперь, когда у нас есть некоторый контекст, давайте вернемся к нашему расследованию. Со временем, исправляя некоторые проблемы со стабильностью с помощью обновлений системы, мы внедрили ZRAM в нашу инфраструктуру. Сначала все казалось хорошо. Затем наши инструменты мониторинга начали улавливать необычные закономерности в операциях ввода/вывода.

Проблема не была сразу очевидна. Серверы работали нормально, пока не достигали определенного состояния памяти. Критический момент наступал, когда системы достигали полной емкости и им требовалось одновременно обрабатывать как ZRAM, так и пространство подкачки. Мы обнаружили, что запуск физической памяти с подкачкой работал нормально, как и физическая память с ZRAM. Но когда были включены и сжатие, и подкачка, возникала проблема зависания сервера.

Наши отладочные журналы и дампы данных раскрыли всю историю. Отладка на уровне ядра показала, что когда и ОЗУ (сжатая с помощью ZRAM), и подкачка достигли емкости, передача между ними работала неправильно. Вместо плавного перемещения данных между сжатой ОЗУ и пространством подкачки системы полностью зависали. Модели задержек в наших отладочных дампах указывали на фундаментальную проблему с этим подходом к управлению памятью.

К декабрю 2024 года у нас было достаточно доказательств, чтобы сделать решительный шаг. Мы деактивировали ZRAM во всех системах. Эффект был мгновенным и очевидным: эти загадочные проблемы ввода/вывода исчезли. Что еще важнее, загадочные зависания системы, которые раздражали наших клиентов и нас самих, резко сократились.

Миссия выполнена.

Мы надеемся, что полученные нами знания о поведении ZRAM помогут другим поставщикам, сталкивающимся с аналогичными проблемами.

С нетерпением жду
Поддержание стабильности инфраструктуры сервера — это постоянная задача. Хотя деактивация ZRAM решила проблему снижения производительности, с которой мы столкнулись в 2024 году, мы продолжаем изучать другие способы обеспечения еще более стабильной среды. Мы также улучшаем нашу инфраструктуру: мы обновляем наш парк vhosts до новых процессоров AMD Turin, новейших ЦП, которые предлагают еще более эффективную обработку памяти.

Мы не можем гарантировать, что вы никогда не столкнетесь с простоями, но мы можем гарантировать, что продолжим оптимизировать и совершенствовать работу, чтобы ваши рабочие нагрузки выполнялись бесперебойно 24 часа в сутки, 7 дней в неделю, 365 дней в году.

contabo.com