
Jul 4, 2026
2026년 AI 검색 가시성을 위한 최고의 AI 웹사이트 빌더: Wix, Framer, Webflow, We0 비교
2026년에는 AI 웹사이트 빌더를 선택하는 일이 더 이상 단순히 페이지를 더 빠르게 생성하는 것만을 의미하지 않습니다. 중요한 것은 웹사이트가 Google, AI Overviews, ChatGPT 스타일 검색 및 기타 AI 발견 채널에서 이해되고, ...

Понятное объяснение ошибки в журнале обратной связи Codex SQLite: почему небольшая локальная база данных журналов всё равно могла создавать ...
Недавняя проблема с журналированием в Codex превратила тихую локальную базу данных в неожиданно активный источник записей на SSD. Согласно исходному отчету на GitHub, журналы обратной связи Codex в SQLite могли записывать примерно 640 ТБ в год при описанном сценарии использования. Для потребительского SSD с ресурсом около 600 TBW это число не просто немного неаккуратно; оно близко к гарантированному ресурсу записи накопителя.
Странность в том, что база данных журнала не выглядела огромной. Файл мог занимать около одного гигабайта, тогда как фактический объем исторических записей продолжал накапливаться в фоновом режиме. Именно поэтому эта ошибка привлекла столько внимания: она не заполняла диск очевидным образом, но все равно могла быстро расходовать циклы записи.
Примечание об источниках: эта статья основана на репосте отчета Xinzhiyuan на BAAI Hub и сверена с публичным issue на GitHub и обсуждением на Hacker News. Логотипы брендов, QR-коды, призывы подписаться и несвязанные декоративные изображения с исходной страницы не включены.
Сначала это число кажется преувеличенным, поэтому стоит начать с измерения.
В issue на GitHub автор сообщил, что примерно после 21 дня работы без перезагрузки основной SSD записал около 37 ТБ. При экстраполяции на полный год это дает примерно 640 ТБ. Предполагаемым основным источником была локальная база данных журналов обратной связи Codex в SQLite.
Codex выполнял запись в файлы в локальном каталоге конфигурации:
~/.codex/logs_2.sqlite
~/.codex/logs_2.sqlite-wal
~/.codex/logs_2.sqlite-shmПоведение заключалось не просто в том, что «файл журнала бесконечно растёт». Скорее это было похоже на цикл вставки и очистки: Codex вставлял новые строки, а затем удалял старые, чтобы сохранять стабильным количество удерживаемых строк. Видимый размер файла оставался относительно спокойным, но накопителю всё равно приходилось обрабатывать повторяющиеся операции записи.
15-секундный фрагмент из отчёта ясно показал проблему:
Метрика | До | После |
Удерживаемые строки | 681,774 | 681,774 |
Максимальный ID строки | 5,003,347,015 | 5,003,383,226 |
Это означает, что примерно 36 211 строк были вставлены за 15 секунд, хотя количество сохранённых строк вообще не увеличилось. Снаружи база данных выглядела стабильной, но внутри продолжалась активная перезапись.
Частые записи в журнале также не всегда были ценными событиями приложения. Примеры включали повторяющийся шум на уровне файловой системы и зависимостей, например события inotify:
128,764x TRACE log: inotify event: ... name: Some("ld.so.cache")
37,982x TRACE log: inotify event: ... name: Some("locale.alias")
23,843x TRACE log: inotify event: ... name: Some("passwd")В результате локальная система журналирования могла продолжать перезаписывать хранилище, почти не подавая пользователям видимых признаков того, что происходит что-то необычное.
Самая контринтуитивная часть этого инцидента проста: износ SSD зависит от общего объёма записей, а не от текущего размера файла.
Локальная база данных может оставаться в пределах примерно 1 ГБ, в то время как приложение постоянно записывает, удаляет, индексирует, создаёт контрольные точки и перезаписывает её части. С точки зрения состояния накопителя важно не только то, насколько большим выглядит файл сегодня. Важно то, сколько данных было записано с течением времени.
Метрика | Значение |
Текущий размер файла | 1,2 ГиБ |
Текущее количество сохранённых строк | 506 149 |
Общее количество выделенных идентификаторов строк | 5 543 677 486 |
Текущая база данных содержала всего около полумиллиона строк, тогда как автоматически увеличиваемый идентификатор строки уже превысил 5,5 миллиарда. В этом и заключается суть истории с усилением записи: старые строки могут исчезнуть из текущего представления базы данных, но записи на диск, в результате которых они были созданы, уже произошли.
WAL в SQLite, или журналирование с упреждающей записью, здесь тоже имеет значение. В режиме WAL изменения сначала добавляются в отдельный файл -wal, прежде чем через контрольную точку записываются обратно в основную базу данных. WAL — это обычный и полезный механизм SQLite, но когда приложение выполняет очень частые вставки и удаления, он может многократно увеличить объём дисковой активности, происходящей в фоновом режиме.
Проще говоря: блокнот всё ещё выглядит тонким, но одни и те же страницы были написаны, стёрты и переписаны много раз.
В отчёте указывалось на одну особенно важную деталь конфигурации в пути журналирования Codex:
Targets::new().with_default(Level::TRACE)В экосистеме tracing Rust фильтрация журналов часто управляется через цели и уровни. Пользователи вполне могут ожидать, что переменная окружения RUST_LOG поможет снизить подробность журналирования до уровня вроде info, warn или ниже.
Но в этом пути приёмник журнала обратной связи SQLite использовал значение по умолчанию TRACE. TRACE — это самый подробный уровень, и он может захватывать низкоуровневые детали зависимостей, необработанную активность протокола и другой отладочный шум. В отчёте о проблеме утверждалось, что из-за этого значения по умолчанию локальная постоянная база данных журналов сохраняла гораздо больше, чем следовало.
Распределение сохранённых журналов показало, насколько доминирующим было содержимое уровня TRACE:
Уровень | Оценка, МиБ | Доля байтов |
TRACE | 732.5 | 70.7% |
INFO | 266.5 | 25.7% |
DEBUG | 30.6 | 3.0% |
WARN | 5.9 | 0.6% |
В отчёте также отмечалось, что два зеркальных источника журналов, связанных с OpenTelemetry, codex_otel.log_only и codex_otel.trace_safe, составляли ещё одну значительную часть сохранённых байтов журналов. В этом образце автор отчёта оценил, что фильтрация этих «шумных» категорий могла бы удалить большую часть сохранённого объёма журналов без полного отключения журналов обратной связи.
Именно поэтому эта ошибка так раздражала разработчиков. Дело было не просто в том, что «вы забыли настроить логирование». Это больше походило на ситуацию: «вы попытались сократить объём логирования, но этот путь всё равно сохранял подробные журналы».
В отчёте это не рассматривалось как единичный изолированный инцидент. В нём был перечислен ряд связанных проблем Codex, касающихся журналов SQLite, роста WAL, высокой дисковой активности, а также неограниченного или чрезмерного локального логирования.
Некоторые примеры, упомянутые в отчёте, включали:
Проблема | Заявленная тема |
| Чрезмерные записи SQLite WAL во время потоковой передачи, поскольку журналы TRACE игнорировали |
| Рост настольного |
| Файлы WAL остаются выделенными или неожиданно увеличиваются |
| Рост журнала отзывов SQLite без достаточного срока хранения или ротации |
| Усиление записи в небольшой базе данных SQLite |
| Высокая нагрузка ввода-вывода от простаивающих процессов Codex |
| 100% активного времени диска в Windows / WSL2 |
В issue эти три исправления были перечислены так:
Pull Request | Назначение | Примечание к выпуску в Issue |
| Прекратить логирование каждого события Responses WebSocket | Выпущено в |
| Отфильтровать шумные цели из постоянных логов | Выпущено в |
| Прекратить сохранение перенаправленных событий логов | Запланировано для |
Сокращение на 85% — это существенно, но это не то же самое, что доказать наличие у локального логирования жесткого долгосрочного лимита на запись. Именно из-за этого различия обсуждение продолжилось. Разработчики спрашивали не только о том, была ли уменьшена именно эта ошибка; они спрашивали, должны ли AI-агенты для программирования иметь более четкие ограничения для постоянной локальной телеметрии.
В issue на GitHub также был приведен простой обходной путь, которым поделился один из комментаторов. Он блокирует вставки в таблицу logs путем создания триггера SQLite:
sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS
block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE);
END;"Используйте такие обходные пути осторожно. Они могут сократить локальные записи логов, но также могут удалить диагностические данные, которые позже могут понадобиться службам поддержки или разработчикам. В целом обновление до исправленной версии и проверка текущего поведения логирования безопаснее, чем незаметное изменение базы данных приложения без понимания компромисса.
Обсуждение быстро вышло за рамки одного лишь Codex. На Hacker News разработчики также подняли более широкие претензии к AI-инструментам для программирования: высокая загрузка GPU, большое потребление памяти, фоновая активность и крупные локальные отладочные логи.
Инструмент может казаться «нормальным» в пользовательском интерфейсе, при этом незаметно потребляя ресурсы в фоновом режиме. Быстрые процессоры, большой объём памяти и современные NVMe-накопители могут долго скрывать проблемы. Приложение может не зависать. Диск может не заполняться. Терминал может по-прежнему отвечать. Но счётчики состояния оборудования могут показывать совсем другую картину.
Именно поэтому этот инцидент стал полезным кейсом для инструментов разработчика на базе ИИ. Возможности модели важны, но качество локальной эксплуатации тоже имеет значение. Агент для программирования, работающий на компьютере разработчика, нуждается в разумных настройках по умолчанию, ограничениях хранения, ротации логов и способе, позволяющем пользователям понимать, что он делает.
Это была заявленная проблема логирования в Codex, при которой локальные SQLite-логи обратной связи могли создавать очень большие объёмы записей на диск. В отчёте на GitHub оценивалось около 640 ТБ записей в год при измеренном автором отчёта сценарии использования.
logs_2.sqlite всё равно мог изнашивать SSD?WAL означает Write-Ahead Logging (журналирование с упреждающей записью). SQLite сначала записывает изменения в отдельный файл -wal, а позже переносит их обратно в основную базу данных через контрольные точки; это нормальное поведение, но оно может создавать большую активность, когда вставки и удаления происходят очень часто.
TRACE — самый подробный уровень журналирования. В приведенном примере содержимое уровня TRACE составляло около 70,7% сохраненных байтов журналов, а в отчете утверждалось, что подробные журналы зависимостей и протоколов сохранялись по умолчанию.
В обновлении issue на GitHub говорилось, что были объединены три PR, при этом автор отчета оценил, что на основе отзывов о своем использовании Codex они могут избежать примерно 85% журналов. Два исправления были указаны как выпущенные в 0.142.0, тогда как третье было указано как запланированное для 0.143.0.
Этот конкретный отчет был посвящен Codex. Однако более широкая проблема относится к локальным ИИ-агентам в целом: постоянно работающим инструментам нужны четкие бюджеты ресурсов для диска, CPU, памяти, телеметрии и сохраняемых журналов.
Репозиторий OpenAI Codex на GitHub: Публичный репозиторий для Codex CLI и связанного исходного кода.
SQLite: Встраиваемый движок баз данных, используемый многими локальными приложениями и инструментами.
Документация SQLite по журналированию с упреждающей записью: Официальная документация, объясняющая, как работает WAL и почему важны контрольные точки.
Rust tracing: Фреймворк структурированного логирования и диагностики для Rust, обсуждавшийся в issue Codex.
smartmontools: Набор инструментов для проверки данных о состоянии накопителей SMART, включая счетчики записи SSD на поддерживаемых дисках.
Hacker News: Дискуссионная платформа, где отчет о логировании Codex привлек более широкое внимание разработчиков.
Проблема с журналами обратной связи Codex SQLite #28224: Основная проблема на GitHub, документирующая заявленную оценку записи в 640 ТБ/год и доказательства.
Прекратить логирование каждого события Responses WebSocket #29432: Один из объединённых PR, перечисленных в рамках работы по сокращению логирования.
Отфильтровать шумные цели из постоянных логов #29457: PR, сосредоточенный на фильтрации шумных целей постоянного логирования.
Прекратить сохранять события мостовых логов #29599: Последующий PR, направленный на прекращение сохранения событий логов от транзитивных зависимостей.
Обсуждение на Hacker News: Обсуждение в сообществе логирования Codex, записей на SSD и качества инструментов для кодирования с ИИ.
README OpenAI Codex CLI: Официальный README репозитория по установке и запуску Codex CLI.
Документация SQLite WAL: Официальное объяснение файлов WAL, контрольных точек и соображений производительности.

Jul 4, 2026
2026년에는 AI 웹사이트 빌더를 선택하는 일이 더 이상 단순히 페이지를 더 빠르게 생성하는 것만을 의미하지 않습니다. 중요한 것은 웹사이트가 Google, AI Overviews, ChatGPT 스타일 검색 및 기타 AI 발견 채널에서 이해되고, ...

Jul 4, 2026
Trae Work는 더 이상 단순한 AI 코딩 도구가 아닙니다. 이 We0 글에서는 Trae Work를 AI 오피스 플랫폼과 비교하고, AI 코딩이 창업자, 개발자, 마케터, 크리에이터를 위한 팀 전체의 워크플로가 될 수 있는 이유를 설명합니다.

Jul 4, 2026
Google Search Console은 새로운 검색 생성형 AI 성과 보고서를 도입했습니다. 이 글은 기업 웹사이트 관점에서 어떤 데이터를 볼 수 있는지, 어떤 데이터는 볼 수 없는지, 페이지가 AI 개요/AI 모드에 진입했는지 판단하는 방법, 그리...