Codex günlükleme hatası, yerel SSD'de TB düzeyinde yazmaya yol açarak SSD ömrünü hızla tüketebilir

 (github.com/openai)
1 puan yazan GN⁺ 3 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Codex, yerel SQLite geri bildirim günlük DB'sine sürekli olarak büyük miktarda veri yazıyor ve bir kullanıcı ortamında 21 gün çalıştıktan sonra ana SSD'ye yaklaşık 37TB yazıldığı görüldü
  • Bu, yıllık yaklaşık 640TB'ye denk geliyor; 1TB SSD bazında yılda yaklaşık 640 tam sürücü yazımına karşılık geliyor ve bazı tüketici SSD'lerinin garanti ömrünü (yaklaşık 600 TBW) 1 yıl dolmadan tüketebilir
  • Saklanan satır sayısı yalnızca yaklaşık 500 bin olmasına rağmen AUTOINCREMENT sayacı 5,5 milyar ID'yi aştı; saklanan satırlar ile kümülatif ekleme ID'leri arasında yaklaşık 10 bin kat fark bulunuyor
  • Bunun nedeni, SQLite geri bildirim günlük senkronizasyonunun global TRACE varsayılanı (Targets::new().with_default(Level::TRACE)) ile ayarlanmış olması; bu da bağımlılıkların iç günlükleri ve büyük hacimli ham protokol payload'ları dahil her şeyi kalıcı olarak kaydediyor
  • 22 Haziran 2026'da iki PR birleştirildi ve günlüklerin yaklaşık %85'i engellenerek sorun kapatıldı

Temel belirtiler ve etki kapsamı

  • Codex aşağıdaki dosyalara sürekli yoğun yazım yapıyor
    • ~/.codex/logs_2.sqlite
    • ~/.codex/logs_2.sqlite-wal
    • ~/.codex/logs_2.sqlite-shm
  • 21 günlük çalışmanın ardından ana SSD'ye yaklaşık 37TB yazıldı; süreç/dosya bazlı incelemede Codex SQLite günlüklerinin başlıca sürekli yazım kaynağı olduğu doğrulandı
  • Yıllık yaklaşık 640TB'ye denk geliyor; 1TB SSD için yılda yaklaşık 640 tam sürücü yazımı seviyesinde
  • Bazı tüketici SSD'leri yaklaşık 600 TBW derecesine sahip olduğundan, garanti kapsamındaki yazma ömrü 1 yıldan kısa sürede tükenebilir

Kanıt verileri

  • Evidence1 — yazma amplifikasyonu (write amplification)

    • Mevcut logs_2.sqlite dosya boyutu: 1.2 GiB
    • Mevcut saklanan satır: 506,149
    • Kümülatif tahsis edilmiş row id: 5,543,677,486
    • Saklanan satırlar (yaklaşık 0.5M) ile kümülatif ekleme ID'leri (5,5 milyar+) arasında yaklaşık 10 bin kat fark var; WAL, indeksler, budama, checkpoint, sayfa yeniden yazımı ve cihaz düzeyi amplifikasyonu hariç tutsak bile geçmiş günlük churn'ünün 10TB+ ölçeğinde olduğu tahmin ediliyor

  • Evidence2 — seviye/hedef dağılımı

    • Saklanan satır sayısı 681,774, tahmini saklanan günlük içeriği yaklaşık 1,035.6 MiB
    • Seviyelere göre oran: TRACE %70,7, INFO %25,7, DEBUG %3,0, WARN %0,6
    • En büyük target+level çiftleri
      • codex_api::endpoint::responses_websocket (TRACE) 527.4 MiB
      • codex_otel.log_only (INFO) 141.2 MiB
      • codex_otel.trace_safe (INFO) 121.2 MiB
      • log (TRACE) 97.4 MiB
    • Üst kaynakların çoğu global TRACE günlükleri, yansıtılmış telemetri günlükleri ve ham websocket/SSE payload kayıtlarından oluşuyor
    • codex_otel.log_only + codex_otel.trace_safe ek olarak %25,3 pay alıyor; bu kategoriler filtrelendiğinde örnek bazında saklanan günlük baytlarının yaklaşık %96'sı kaldırılabiliyor
    • En sık TRACE kaynağı (target=log) içinde inotify event (ör. ld.so.cache 128,764 kez), tokio-tungstenite iç çağrıları, WouldBlock gibi düşük seviyeli kalemler çok sayıda bulunuyor

  • Yazma amplifikasyonu ölçümü

    • 15 saniyelik örnekte saklanan satır sayısı 681,774 olarak değişmeden kalırken yaklaşık 36,211 satır eklendi
    • Tekrarlanan insert-and-prune modeli, yani ekleme → indeksleme → WAL yazımı → budama döngüsü, yazma amplifikasyonuna yol açıyor

Tahmini neden

  • SQLite geri bildirim günlük sink'i global TRACE varsayılanı (Targets::new().with_default(Level::TRACE)) ile kurulmuş
  • Bu nedenle bağımlılık/iç günlükler ve büyük hacimli ham protokol payload'ları dahil tüm hedefler TRACE seviyesinde kalıcı olarak saklanıyor

Önerilen düzeltme yönü

  • Geri bildirim günlükleri korunsun, ancak varsayılan kalıcı saklama kapsamı daraltılsın
    • SQLite geri bildirim günlük sink'inde global TRACE kullanılmamalı
    • target=log, hyper_util, tokio-tungstenite iç kısımları, inotify spam'i, düşük değerli OpenTelemetry SDK günlükleri gibi gürültü kaynakları için eşik yükseltilmeli veya bunlar kaldırılmalı
    • Ham websocket/SSE payload'larının tamamı yerine özet bilgiler saklanmalı: olay türü, süre, başarı/başarısızlık, token kullanımı, payload bayt uzunluğu
    • codex_otel.log_only / codex_otel.trace_safe yansıtılmış olayları, yalnızca hata ayıklamada gerçekten yararlı olduğu durumlar dışında saklanmamalı
    • İş parçacığı düzeyindeki sınırlar tek başına yeterli olmadığından global günlük DB boyutu/yazma üst sınırı eklenmeli
  • sqlite_logs_enabled = false gibi bir seçenek de yararlı olabilir, ancak asıl çözüm daha iyi varsayılan filtreleme

Çoklu platform yeniden üretim raporları

  • macOS

    • macOS 15.7.7 / Codex 26.616.51431 ortamında logs_2.sqlite 113M, MAX(id)=34,277,360, saklanan satır 31,405; 60 saniyelik iki örnekte yaklaşık saniyede 60 yazım doğrulandı
    • 1-2 saatlik oturum sırasında codex sürecinin yaklaşık 50GB yazdığı vakalar bildirildi

  • Windows

    • Windows Codex Desktop (codex.exe app-server --analytics-default-enabled) ortamında RUST_LOG=warn ve açık bir trace ayarı olmamasına rağmen TRACE satırları sürekli ekleniyor
    • Saklanan satır yaklaşık 71k, sqlite_sequence içindeki logs değeri 18,5 milyonu aşmış durumda; bu da geçmişte çok sayıda insert/prune churn olduğunu gösteriyor
    • 10 dakikalık dağılımda TRACE 1,812 satır; üst TRACE hedefleri arasında codex_api::endpoint::responses_websocket (3.5MB+), codex_api::sse::responses yer alıyor
    • Beklenen davranış: RUST_LOG=warn iken bağımlılık/iç TRACE ve büyük payload'lar sürekli olarak saklanmamalı

Ek riskler ve geçici hafifletmeler

  • Veri kaybı riski

    • Disk dolu durumdayken yeniden başlatma sonrası Linux oturum açma başarısız olabilir
    • Codex /goal modu disk alanı açmaya çalışırken dosya/klasör silerek veri kaybına yol açabilir

  • Geçici hafifletme betikleri

    • Çalışan WAL'ı kırpmak için trim-codex-wal.sh (PRAGMA wal_checkpoint(TRUNCATE) kullanır); cron ile her 15 dakikada bir çalıştırılabilir
    • Günlük/WAL dosyalarını sildikten sonra Codex ile ilgili süreçlere SIGTERM→SIGKILL göndererek disk alanını anında açan fix-codex-wal.sh
    • SQLite trigger'ı (block_log_inserts) eklenip logs tablosuna eklemeler yok sayılırsa WAL büyümesi durur; geri almak için DROP TRIGGER IF EXISTS block_log_inserts
      • VACUUM, DB'yi yeniden yazdığı için büyük dosyalarda tek seferlik büyük yazımlara yol açabilir; bu nedenle trigger eklendikten ve WAL büyümesinin durduğu doğrulandıktan sonra DELETE/VACUUM çalıştırılması önerilir
      • Bu, özel bir SQLite şema değişikliği olduğundan ilerideki Codex güncellemeleri/migrasyonları tabloyu yeniden oluşturarak veya trigger'ı kaldırarak davranışı değiştirebilir
    • Kalıcı düzeltme gelene kadar SSD hasarını önlemek için ilgili DB'nin bir ramdisk üzerinde tutulması da önerildi

Çözüm ve kapanış

  • 22 Haziran 2026'da iki PR'nin birleştirilmesiyle yaklaşık %85 günlük azalması sağlandı ve sorun tamamlandı olarak işaretlendi
    • Tüm Responses WebSocket olaylarının günlüklenmesi durduruldu (#29432)
    • Kalıcı günlüklerde gürültü hedefleri filtrelendi (#29457)
  • Ayrı bir öneri yamasında global TRACE yerine varsayılan saklama INFO+, codex_otel.log_only·codex_otel.trace_safe·hyper_util·log·opentelemetry_sdk vb. için eşik WARN+ olarak yükseltildi
  • Düzeltmeler rust-v0.142.0 ile yayımlandı

İlgili okumalar

1 yorum

 
GN⁺ 3 시간 전
Hacker News yorumları

  • Codex'in slopware'ın kötü şöhretli örneklerinden biri olduğunu düşünüyorum
    macOS'ta sadece pencereyi görünür bırakmak bile spinner mesajını göstermek için GPU'yu %100 kullanıyor
    MBP M5'te yalnızca spinner mesajıyla GPU %100 görünüyor ve modeli beklediği sürenin çoğunda fanlar yüksek sesle döndüğü için bataryada kullanırken dikkat etmek gerekiyor
    Bu issue GitHub'a neredeyse 6 ay önce açılmıştı; muhtemelen vibe coding ile yapılmış bu ıvır zıvır yayımlandığından beri vardır
    İnsan kendisi düzeltmek istese de, nedenini bilmiyorum ama kaynak kod kapalı olduğu için mümkün değil
    Hangi modelin daha iyi olduğu, vibe coding yapılıp yapılamayacağı konusunda çok tartışma var; ama fon, insan gücü ve model yeteneği açısından en zengin şirketlerden birinin vibe coding ile yapabildiği seviye buysa durum bu demektir
    CEO zaten “kodlamaya odaklandığını” söylemişken, böyle ciddi bir hata şirkette içeride gerçekten bir şeylerin bozuk olduğunun işareti gibi görünüyor ve Polymarket'te de OpenAI'nin yakında lider bir model çıkaracağını düşünen pek kimse yok
    Dünyanın Anthropic'e bir rakibe ihtiyacı olduğu için bu trajik

    • Hemen yanında Claude Code da dururken, slopware örnekleri arasında onu atlamamak gerekir
    • Yapay zeka ile 10 kat üretkenlik elde ediliyorsa ve AGI ya da ASI'ye yaklaşılıyorsa, Codex veya Claude Code CLI gibi ürünlerin nasıl hâlâ bu kadar berbat olabildiğini anlamıyorum
      “Ajan tipi yapay zeka devrimi” bu sorunları çoktan çözmüş olmalıydı diye düşünüyorum
      Yoksa içeride gerçekten “işleniyor, lütfen bekleyin” ya da “görev çok zor” mu deniyor
    • Temelde her şeyi açık kaynak olarak yayımlayan bir organizasyonda çalışırken, yan projeler dahil bir şeyi kapalı kaynak bırakmanın tek bir nedeni vardı: utanç
      Kimse berbat bir kod tabanının kamusal yüzü olmak istemez
      O kodla absürt bir fiyatlandırmayı haklı çıkarmaya çalışıyorsan, bu yük herhalde üç katına çıkar
    • Sadece Codex değil, macOS'taki ChatGPT uygulaması da birkaç saat açık kalınca zamanla 60 GB RAM yiyip diğer uygulamaların hepsini öldürüyor
      Anlamıyorum
      Tarayıcıda Google AI Studio kullanmaya çalışınca da CPU'yu %100 kullanıyor
      Sonunda her şeyi kendimiz uygulama olarak mı yazacağız diye düşündürüyor
    • İlk zamanlarda dünyanın ChatGPT'ye rakip olarak Anthropic'e ihtiyacı olduğu söylenirdi; şimdi tam tur atmış durumdayız

  • X'te bu sorun için bir geçici çözüm paylaşılmış[1]
    sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"
    Ayrıca bir dizüstünde ilgili sqlite dosyasına VACUUM FULL çalıştırılınca 27 GB'tan 73 MB'a düştüğü söylenmiş[2]
    [1]: https://xcancel.com/bdsqlsz/status/2067964486615810369
    [2]: https://xcancel.com/jeethu/status/2068087449469780434

    • Yine bir kez daha veritabanı düzeyi kuralı günü kurtarmış
    • Asıl çözüm kullanmayı bırakıp Pi'ye geçmek

  • Herkes OpenAI'yi eleştiriyor ve bunda haklılar ama, Claude Code'un aksine Codex'in resmen özelleştirilebilir olduğunu hatırlatmakta fayda var: https://github.com/openai/codex
    Patchlemek de oldukça kolay

    • O, CLI; burada bahsedilen şey tekelci Codex uygulaması değil

  • Şok edici
    Issue açılalı bir hafta olmuş ama benim gördüğüm kadarıyla OpenAI sadece sessiz kalıyor
    Bu tür satıcıların bu tip sorunlara karşı aşırı hassas olacağını sanırdım, anlamıyorum
    Herhalde GitHub'daki potansiyel issue'ları izleyip düzeltme öneren bir sürü ajan bağlamışlardır, değil mi? …değil mi?
    Kendi araçlarını çalıştırıp GitHub issue'larını gerçek zamanlı düzeltmek tabii ki önemsiz bir iş olmalıydı

    • OpenAI issue düzeltme konusunda epey zayıf görünüyor
      Benim kişisel favori örneğim #2472; GPT-5 lansman sahnesinde “düzeltildi” diye gösterdiler ama ticket hâlâ açık ve o “düzeltme” de merge edilmedi
      Buna dikkat çeken asıl yazı https://blog.tymscar.com/posts/openaiunmergeddemo/ ve issue da https://github.com/openai/openai-python/issues/2472
    • Aynı sorunla ilgili bir GitHub issue'su nisandan beri vardı
      Codex'i çok kullanıyorum ve performansından (UX ve çıktı) gayet memnunum ama bu sorunun hâlâ düzeltilmemiş olması anlaşılır değil

  • Bu sorun düzeltilmiş gibi görünüyor[0] ve muhtemelen bir sonraki sürüme girecek
    [0] https://github.com/openai/codex/commit/e98d43ac372ddf7f513c0...

  • Vibe coding, “hızlı hareket et ve bir şeyleri boz” anlayışını tamamen başka bir seviyeye taşıyor

    • Şu anda şirketimizde birinin vibe coding ile ürettiği çöp ciddi biçimde ters gittiği için büyük bir arızayı çözmeye çalışıyoruz
    • Artık bozacak şeyler de giderek tükeniyor
    • Teknik borç yoksa vibe coding genel olarak prototipleme için faydalı
      Gerçek ürünlerde gerçek yazılım mühendislerinin yerini asla almayacak

  • Konudan biraz sapıyor ama bu şirketler depo kök klasörünü Claude.md ya da copilot.md ile kirletmeyi bırakmalı
    Bir odada toplanıp docs/llm/* gibi iyi bilinen bir klasör yapısında anlaşmalılar

  • Geçen yılın sonunda Claude Code gecikmeler yüzünden perişanken OpenAI neredeyse eline geçen zaferi kaçırdı
    Bu günlerde Codex daha başlar başlamaz yazma gecikmesi yaratıyor; Claude Code ise bazen takılsa da genel olarak ben tuşa bastığımda… kelimenin tam anlamıyla… bastığım şeyi gösteriyor

    • Bende tam tersi oluyor
    • Claude Code bana neredeyse kullanılamaz geliyor
      Birkaç kelimeden fazla yazacaksam her zaman neovim'de yazmak zorunda kalıyorum

  • Bu aslında çok tipik bir hata
    Her şeyde izleme/debug logları açıkken ürün yayımlamışlar; komik olan, etkisinin alışılmış şekilde ortaya çıkmaması
    Eskiden bir geliştirici trace seviyesinde loglamayı açardı, uygulama felaket derecede yavaşlardı ve bir sonraki güncellemede hemen düzeltilirdi; şimdi ise bellek, CPU ve disk hızları o kadar baskın şekilde arttı ki, bunun o şekilde hemen görünmediği bir noktaya gelmiş olmamız çılgınca

    • Ajan işi sunucu tarafında yapıldığı için, ince istemcinin yerel kaynakların hepsini tüketebilmesi de bunda pay sahibi

  • Keşke biri bu girişken startup'a biraz token bağışlasa. Yardıma ihtiyaçları var gibi görünüyor.