問題
コーデックは、ローカル SQLite フィードバック ログ データベースに大量のデータを継続的に書き込みます。
~/.codex/logs_2.sqlite~/.codex/logs_2.sqlite-wal~/.codex/logs_2.sqlite-shm
私のマシンでは、この後 21日間の稼働時間主にSSDについて書いています。 37TB。プロセス/ファイル レベルの調査により、コーデックが SQLite ログの主な永続的な書き込みであることがわかりました。
これは大まかに推定します 640TB/年。 1つで 1TB SSDそれはそれについてです 年間 640 回のフルドライブ権。一部のコンシューマー向け SSD は次のように評価されています。 600TBWしたがって、ドライブに必要な書き込み耐久性のほぼ全体が 1 年以内に使い果たされる可能性があります。
証拠
現在保持されている行 logs_2.sqlite: :
| メトリック | 価格 |
|---|---|
| 保持される行数 | 681,774 |
| アーカイブされたログの推定内容 | 1,035.6 MiB |
レベル分布:
| レベル | 推定MIB | バイト％ |
|---|---|---|
| トレース | 732.5 | 70.7% |
| 情報 | 266.5 | 25.7% |
| デバッグ | 30.6 | 3.0% |
| 警告する | 5.9 | 0.6% |
ターゲットとレベルの最大の組み合わせ:
| ターゲット | レベル | 推定MIB |
|---|---|---|
codex_api::endpoint::responses_websocket |
トレース | 527.4 |
codex_otel.log_only |
情報 | 141.2 |
codex_otel.trace_safe |
情報 | 121.2 |
log |
トレース | 97.4 |
codex_client::transport |
トレース | 60.1 |
codex_core::stream_events_utils |
デバッグ | 27.5 |
codex_api::sse::responses |
トレース | 19.1 |
上位のソースは、ほとんどがグローバル TRACE ログ、ミラーリングされたテレメトリ ログ、および生の WebSocket/SSE ペイロード ログです。 TRACE ほぼ一人です 70.7% そのままのバイト数。 codex_otel.log_only + codex_otel.trace_safe 別のを追加します 25.3%。これらのカテゴリはフィルタリングして広範囲に削除する必要があります 96% このサンプルでフィードバック ログを完全に無効にせずに作成されたログのバイト数。
最も頻繁に表示される TRACE ソースからクリーンアップされた例: target=log
これらは高周波で作成されたサンプルです。未処理の WebSocket/SSE ペイロード本体にはプライベートな会話コンテンツが含まれる可能性があるため、意図的に含まれていません。
128,764x TRACE log: inotify event: ... mask: OPEN, name: Some("ld.so.cache")
37,982x TRACE log: inotify event: ... mask: OPEN, name: Some("locale.alias")
23,843x TRACE log: inotify event: ... mask: OPEN, name: Some("passwd")
3,639x TRACE log: /src/compat.rs:131 AllowStd.with_context
3,505x TRACE log: /src/lib.rs:245 WebSocketStream.with_context
3,362x TRACE log: /src/compat.rs:154 Read.read
3,356x TRACE log: /src/compat.rs:157 Read.with_context read -> poll_read
3,230x TRACE log: /src/lib.rs:294 Stream.poll_next
3,227x TRACE log: /src/lib.rs:304 Stream.with_context poll_next -> read()
3,213x TRACE log: inotify event: ... mask: OPEN, name: Some("nsswitch.conf")
2,001x TRACE log: WouldBlock
1,217x TRACE log: Masked: false
1,169x TRACE log: Opcode: Data(Text)
1,169x TRACE log: First: 11000001
頻繁に使用される情報源からのクリーンな例
主な情報源は、主に頻繁に繰り返される OpenTelemetry ミラー イベントです。 IDが変更されました。
843x INFO codex_client::custom_ca:
using system root certificates because no CA override environment variable was selected ...
334x INFO codex_otel.trace_safe:
session_loop{thread_id=}:submission_dispatch{otel.name="op.dispatch.user_input" submission.id= codex.op="user_input"}:turn{otel.name="session_task.turn" thread.id= ...}
333x INFO codex_otel.log_only:
session_loop{thread_id=}:submission_dispatch{otel.name="op.dispatch.user_input" submission.id= codex.op="user_input"}:turn{otel.name="session_task.turn" thread.id= ...}
332x INFO codex_otel.log_only:
session_loop{thread_id=}:submission_dispatch{otel.name="op.dispatch.user_input_with_turn_context" submission.id= codex.op="user_input_with_turn_context"}:turn{otel.name="session_task.turn" thread.id= ...}
332x INFO codex_otel.trace_safe:
session_loop{thread_id=}:submission_dispatch{otel.name="op.dispatch.user_input_with_turn_context" submission.id= codex.op="user_input_with_turn_context"}:turn{otel.name="session_task.turn" thread.id= ...}
書き込み増幅
保持される DB サイズにより、実際の書き込みボリュームが隠蔽されます。 15 秒のサンプルでは次のようになります。
| メトリック | 初め | 後 |
|---|---|---|
| 保持される行数 | 681,774 | 681,774 |
| 最大行ID | 5,003,347,015 | 5,003,383,226 |
これについて 15 秒間に 36,211 行が挿入されました一方、保持される行番号は一定のままです。これは、継続的な挿入とソートの書き込み増幅を示唆しています。つまり、行が挿入され、インデックスが付けられ、ウォールに書き込まれ、その後切り捨てられます。
考えられる原因
SQLite フィードバック ログ同期は、グローバル TRACE デフォルトでインストールされます。
Targets::new().with_default(Level::TRACE)
デフォルトでは、依存関係/内部ログや大規模な生のプロトコル ペイロードを含むすべてのターゲットを TRACE レベルで維持します。
提案された解決策
フィードバック ログを有効にしたままにしますが、デフォルトで保持される内容を制限します。
- SQLite フィードバック ログ同期にはグローバル TRACE を使用しないでください。
- 特に低値の依存性ノイズに対してしきい値を下げるか上げる
target=log、hyper_utilTokyo-Tungstenite の内部情報、Inotify スパム、および低レベルの OpenTelemetry SDK ログ。 - デフォルトでは、完全な生の WebSocket/SSE ペイロードを永続化することは避けてください。代わりに、イベントの種類、期間、成功/エラー、トークンの使用状況、ペイロードのバイト長などの概要を保存します。
- 常に反省を避ける
codex_otel.log_only/codex_otel.trace_safeフィードバックのデバッグに明らかに役立つ場合を除いて、イベント。 - グローバル ログ DB サイズ/書き込み制限を追加します。複数のスレッド/プロセスが存在する場合、スレッドごとの上限では不十分です。
オプションの避難ハッチ。 sqlite_logs_enabled = false これでも便利ですが、主な改善点はデフォルトのフィルタリングが改善されることです。
Leave a Reply