ИИтог

Критический баг в Codex: лог пишет сотни терабайт в год и убивает SSD

инфраструктураРедакция ИИтогHacker News🔥99Рейтинг ИИтог99
Критический баг в Codex: лог пишет сотни терабайт в год и убивает SSD

Разработчик обнаружил, что Codex непрерывно пишет логи уровня TRACE в локальную базу SQLite, вызывая ненужную деградацию SSD. За 21 день обычной работы на диск был записан 37 ТБ данных. Проблема в том, что логирование включено на глобальном уровне TRACE по умолчанию для всех модулей, включая зависимости и сырые WebSocket-пакеты. Автор предложил сузить фильтрацию по умолчанию, отключив TRACE для низкоценных источников шума (inotify события, телеметрия) и хранив суммаризованные версии вместо полных payload'ов.

Ключевые факты

  • Codex пишет ~640 ТБ/год в SQLite логи, что исчерпывает TBW типичного SSD за 1 год вместо 5, 10
  • Корень проблемы: глобальный TRACE уровень логирования по умолчанию сохраняет шум от зависимостей и WebSocket трафика
  • TRACE логи составляют 70% объема, OpenTelemetry зеркала еще 25%, вместе это 96% лишних данных
  • Write amplification: 36k строк вставляются за 15 секунд, затем удаляются, создавая цикл записи без останова
  • Решение: сузить фильтр TRACE, исключить полные payload'ы, добавить глобальный cap на размер БД логов

Почему это важно

SSD имеют ограниченный ресурс по количеству записей (TBW). Большинство потребительских SSD рассчитаны на 600 ТБ записей, что дает примерно 5, 10 лет при обычной работе. Codex в текущем виде может исчерпать весь ресурс за год, превратив дорогой накопитель в яблочное пюре. Для компаний это означает ускоренный выход из строя серверов и локальных машин разработчиков.

Кому это важно

Пользователи Codex (редактор от OpenAI, встраивается в VS Code и другие IDE), особенно те, кто активно работает в нем по 8+ часов в день. Компании, которые развертывают Codex на корпоративных машинах разработчиков. DevOps и системные администраторы, которые должны заменять SSD чаще, чем планировалось. Все, кто полагается на стабильность локального диска.

Как это применить

Пока OpenAI не исправит баг: 1) отключить Codex логирование через переменную окружения или конфиг, если доступно. 2) Мониторить размер ~/.codex/logs_2.sqlite вручную, периодически чистить старые логи. 3) Хранить Codex кэш и логи на отдельном диске, чтобы изнашивание не затрагивало системный SSD. 4) Отключить полный TRACE логирование, если есть опции конфигурации. Предложенное решение (узкие фильтры TRACE, отключение сырых payload'ов, глобальный cap) должно быть применено в следующих версиях Codex.

Можно ли доверять

Отчет основан на конкретных данных из запущенной системы: замеры за 21 день, статистика по БД (уровни логирования, размеры записей), примеры частых записей с указанием количеств. Расчет экстраполяции (37 ТБ за 21 дней = 640 ТБ/год) математически верен. Предложенные решения логичны и опираются на анализ состава логов (TRACE 70%, OpenTelemetry 25%). Таким образом, это технически обоснованный отчет разработчика, а не спекуляция.

Риски и подводные камни

Отключение логирования полностью может усложнить отладку проблем в Codex. Требуется аккуратный баланс между детализацией и производительностью. OpenAI может долго не торопиться с исправлением, если это нечасто поступающая жалоба. На машинах с быстрыми SSD (например, PCIe 5.0) изнашивание будет менее заметно, но все равно значительно. Пользователи Windows WSL2 сообщают похожие проблемы с I/O, что указывает на системную природу проблемы. Также есть риск того, что исправление может нарушить функционал сбора feedback для улучшения модели.

«На моей машине после примерно 21 дня работы основной SSD записал около 37 ТБ. На SSD объемом 1 ТБ это означает около 640 полных записей диска в год. Некоторые потребительские SSD рассчитаны примерно на 600 TBW, поэтому это может исчерпать весь гарантированный ресурс за менее чем год.»

— Автор issue на GitHub, разработчик, использующий Codex