Как шесть ИИ-агентов положили мой рабочий сервер. Каждый из них всё делал правильно
25 сентября в 19:01 мой сервер перестал отвечать. Сайт, админка, очередь публикаций: замерло всё сразу. Через семнадцать минут я перезагрузил его принудительно.
Взлома не было, наплыва читателей тоже. Я дал Claude Code список из шести задач, и он запустил шесть агентов одновременно. Каждый добросовестно поставил зависимости, проверил типы, прогнал тесты и собрал проект. На том же сервере, где работает сайт.
Представьте шесть грузчиков, которые одновременно несут шкафы по одной лестнице. Каждый несёт аккуратно, а лестница стоит.
Арифметика, которую никто не посчитал
Возьмём круглые числа, близкие к моим. На сервере 10 ГБ памяти, рабочие сервисы занимают около трёх. Остаётся семь.
Одна проверка типов или сборка проекта такого размера берёт от полутора до трёх гигабайт. Шесть одновременно дают от девяти до восемнадцати. В семь свободных это не помещается ни при каком раскладе.
Сложить эти числа мог кто угодно. Не сложил никто: ни я, ни модель.
Почему сервер не спас себя сам
Я ждал, что в такой ситуации Linux убьёт самый прожорливый процесс, и остальные продолжат работу. Этого не произошло. В журнале нет ни одной записи об убитом процессе.
Есть другое. Системные службы сообщили, что работают «under memory pressure». Docker написал, что не смог отправить контейнеру сигнал завершения. Дальше записи обрываются до самой перезагрузки.
Виновата подкачка. Когда память кончается, система начинает перекладывать данные на диск и обратно, и на это уходит всё время процессора. Формально память ещё есть, поэтому убивать никого не надо. Фактически машина занята только собой. Сервер не упал, он завис, а это хуже: упавший сервис перезапустится сам, зависший ждёт человека.
Почему агент так поступил
Параллельность у агентов считается достоинством. Шесть независимых задач логично раздать шести исполнителям, у каждого своя копия кода, никто никому не мешает. В коде так и было.
Мешали они друг другу в памяти, а про неё им никто не сказал. Модель не знает, сколько на машине памяти и что рядом крутится рабочий сайт, пока не проверит сама или пока ей не скажут. А привычка «доведи до конца и убедись, что собирается» обычно полезная. В шести экземплярах на маленьком сервере она его и добила.
Что я поменял
- Не больше двух тяжёлых задач одновременно. Тяжёлая задача здесь означает сборку, проверку типов всего проекта или сборку образа Docker.
- Агент проверяет только свой кусок. Типы и тесты только для пакета, который он менял, без полной сборки.
- Полные сборки идут по очереди, через главную сессию, а не в каждом агенте.
- Правило записано в заметки проекта, которые Claude читает в начале каждой сессии. С тех пор он сам напоминает о нём, когда задач набирается много.
Как посчитать для своей машины
Формула простая: из общей памяти вычесть то, что уже занято, оставить гигабайт запаса и поделить на пиковое потребление одной задачи. В моих круглых числах выходит (10 − 3 − 1) / 3, то есть две задачи.
Пик одной задачи не нужно угадывать, его можно замерить:
Первая команда показывает, сколько памяти свободно сейчас. Вторая запускает сборку и печатает её пик.
И два предохранителя на случай, если расчёт подведёт. Первый: не собирать на рабочем сервере вообще, если есть отдельная машина или облачная сборка. Второй: поставить службу вроде earlyoom, которая убивает самый прожорливый процесс заранее, не дожидаясь, пока система утонет в подкачке.
Второй предохранитель я поставил не сразу, и зря. Через три недели сервер завис снова, уже без агентов: ночная автоматическая проверка обновлений собрала образ Docker и запустила вторую копию сервиса рядом с рабочими. Та же арифметика, только считать её было некому. Теперь earlyoom стоит, и первыми под нож у него идут сборки и браузер, а база данных и Docker в списке неприкасаемых.
Самое обидное в этой истории то, что каждый из шести действовал правильно. Неправильным было только их количество.
Такие находки про Claude я каждый день собираю в канале Claude News.