Прошло ровно три недели с момента моего расследования «ИНДУСТРИАЛЬНЫЙ ПОФИГИЗМ», где я препарировал труп профессионализма компании Hostkey. Казалось бы, после обнаружения чужих Ceph-данных на «новом» диске и 48-часовых замен железа, падать ниже некуда. Но снизу постучали. В пятницу клиент, оплативший когда-то давно через меня год (целый год, Карл!) этого цифрового ГУЛАГа, прислал логи.
Я читал их два дня. Я смеялся. Я плакал. Я снова смеялся. Я звал экзорциста, но он, увидев строку [TTM] Buffer eviction failed, перекрестился и ушел работать в Яндекс.Облако. Сегодня воскресенье, 1 февраля 2026 года, и я наконец готов представить вам этот шедевр оверселлинга и административного садизма.
Прежде чем мы перейдем к анализу, вот вам сам «некролог». Слабонервным и системным инженерам со здоровой психикой рекомендуется отойти от мониторов.
[РАЗВЕРНУТЬ ЛОГ ЦИФРОВОЙ СМЕРТИ]
Jan 28 20:45:20 XXXX kernel: [TTM] Buffer eviction failed Jan 28 20:45:20 XXXX kernel: INFO: task systemd:1 blocked for more than 120 seconds. Jan 28 20:45:20 XXXX kernel: Not tainted 6.12.63+deb13-amd64 #1 Debian 6.12.63-1 Jan 28 20:45:20 XXXX kernel: task:systemd state:D stack:0 pid:1 tgid:1 ppid:0 flags:0x00000002 Jan 28 20:45:20 XXXX kernel: INFO: task wineserver:1192 blocked for more than 120 seconds. Jan 28 20:45:20 XXXX kernel: task:wineserver state:D stack:0 pid:1192 tgid:1192 ppid:1 flags:0x00000002 Jan 28 20:45:32 XXXX kernel: [TTM] Buffer eviction failed Jan 28 20:46:02 XXXX kernel: [TTM] Buffer eviction failed Jan 28 20:47:21 XXXX kernel: INFO: task systemd:1 blocked for more than 241 seconds. Jan 28 20:42:11 XXXX kernel: [UFW BLOCK] IN=tap_vpn OUT=ens1 SRC=192.168.143.221 DST=172.217.18.206 ... Jan 28 20:42:40 XXXX kernel: [UFW BLOCK] IN=ens1 OUT= SRC=167.94.138.32 DST=45.155.103.93 DPT=2223 ... Jan 29 00:06:10 XXXX kernel: [TTM] Buffer eviction failed
Грех первый: Оверселлинг как религия
Начнем с хедлайнера нашего цирка: [TTM] Buffer eviction failed. Для тех, кто не в курсе — TTM (Translation Table Manager) управляет видеопамятью в ядре Linux. Казалось бы, откуда на безголовой VDS (Virtual Dedicated Server) проблемы с видеопамятью?
Всё просто и одновременно ужасно. Гипервизор Hostkey настолько перегружен соседями, что он не может выделить виртуальной видеокарте (которая нужна просто для отрисовки консоли!) даже жалкий мегабайт памяти. Система пытается «выселить» (evict) старые данные из буфера, чтобы освободить место, но… места нет. Физическая память на хост-машине кончилась. Совсем. Её выпили другие такие же несчастные VDS, которые Hostkey набил в сервер, как сельдей в бочку.
Это не просто оверселлинг. Это когда вы продаете однокомнатную квартиру 500 людям одновременно и надеетесь, что они будут дышать по очереди.
Грех второй: Клиническая смерть PID 1
INFO: task systemd:1 blocked for more than 120 seconds.
В мире Linux systemd с PID 1 — это мозг системы. Если мозг не отвечает 120 секунд — это клиническая смерть. Состояние state:D означает Uninterruptible Sleep. Процесс ждет ответа от дисковой подсистемы, а диск… диск ушел в нирвану.
Почему? Потому что I/O Wait на нодах Hostkey, судя по всему, измеряется не в процентах, а в световых годах. Пока физическая дисковая полка пытается разгрести запросы от тысячи клиентов, ваша VDS превращается в тыкву. Клиент заплатил за год, чтобы смотреть на то, как его сервер замирает на 241 секунду (четыре минуты, Карл!), пытаясь просто… существовать.
Грех третий: Праздник для брутфорсеров
В логах мы видим бесконечный поток [UFW BLOCK]. На сервер ломятся все боты интернета — от китайских школьников до автоматизированных сетей по подбору паролей к SSH.
Ирония ситуации зашкаливает: сервер Hostkey настолько слаб, что каждая попытка UFW заблокировать пакет превращается в пытку для процессора. Ядро пытается обработать прерывание от сетевухи, хочет записать лог о блокировке, лезет к диску… а диск занят! В итоге брутфорс-атака, которую нормальный сервер даже не заметит, превращает VDS в эпилептический припадок в режиме реального времени.
Грех четвертый: Архитектурный садизм
Самое смешное — это wineserver, который тоже висит в state:D. Представьте: вы пытаетесь запустить какое-то приложение через Wine, оно хочет прочитать конфиг, обращается к ядру, ядро обращается к гипервизору, гипервизор смотрит на пустой кошелек оперативной памяти, TTM плачет, буферы не очищаются, а systemd уже дважды переродился в индуистской мифологии за то время, пока ждал ответа от SSD.
Вердикт Phoenix901: Это не хостинг, это месть
У меня только один вопрос к инженерам Hostkey: как вам спится? Продавать услугу, где ядро системы вылетает с ошибками управления памятью из-за дичайшего перенаселения ноды — это высший пилотаж цинизма.
Клиент, который прислал мне эти логи, теперь знает: «премиальный» хостинг от Hostkey — это когда твой сервер проводит больше времени в коме, чем в работе. Если вы видите в своих логах Buffer eviction failed — бегите. Не открывайте тикеты (вам всё равно ответят через 48 часов, что «всё ок, это сигнал для нас»), не ждите исправлений. Просто эвакуируйтесь.
Hostkey образца 2026 года — это официально «Доска Позора» российского (и не только) хостинга. Логи не врут. Физику процессов не обманешь маркетинговыми слоганами.
P.S. Я ржал над этими логами два дня, но на самом деле это трагедия. Трагедия индустрии, где вместо инженеров остались только эффективные менеджеры, продающие пустоту в красивой обертке.