บั๊กการล็อกของ Codex อาจทำให้เกิดการเขียนข้อมูลระดับ TB ลง SSD ภายในเครื่อง และเร่งการเสื่อมอายุของ SSD ได้

 (github.com/openai)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Codex เขียนข้อมูลปริมาณมากลงใน SQLite feedback log DB ภายในเครื่องอย่างต่อเนื่อง โดยในสภาพแวดล้อมของผู้ใช้รายหนึ่ง หลังทำงาน 21 วัน มีการเขียนลง SSD หลักประมาณ 37TB
  • เมื่อนำมาเทียบรายปีจะอยู่ที่ราว 640TB หรือเทียบเท่าการเขียนเต็มไดรฟ์ประมาณ 640 ครั้งต่อปีสำหรับ SSD ขนาด 1TB และอาจใช้หมดอายุการรับประกันด้านการเขียนของ SSD ผู้บริโภคบางรุ่น (ประมาณ 600 TBW) ได้ภายในไม่ถึง 1 ปี
  • แม้แถวข้อมูลที่คงเหลือจะมีเพียงประมาณ 500,000 แถว แต่ตัวนับ AUTOINCREMENT กลับเกิน 5.5 พันล้าน ID ทำให้เกิดช่องว่างประมาณ 10,000 เท่า ระหว่างจำนวนแถวที่คงอยู่กับ ID การแทรกสะสม
  • สาเหตุมาจาก feedback log sink ของ SQLite ถูกตั้งค่าเป็น global TRACE default (Targets::new().with_default(Level::TRACE)) จึงบันทึกถาวรทั้งล็อกภายใน dependency และ raw protocol payload ขนาดใหญ่ทั้งหมด
  • เมื่อวันที่ 22 มิถุนายน 2026 มี PR สองรายการถูก merge ซึ่งช่วยตัดล็อกออกไปได้ราว 85% ส่งผลให้ issue นี้ถูกปิด

อาการหลักและขอบเขตผลกระทบ

  • Codex เขียนข้อมูลจำนวนมากอย่างต่อเนื่องลงไฟล์ต่อไปนี้
    • ~/.codex/logs_2.sqlite
    • ~/.codex/logs_2.sqlite-wal
    • ~/.codex/logs_2.sqlite-shm
  • หลังทำงาน 21 วัน มีการเขียนลง SSD หลักประมาณ 37TB และจากการตรวจสอบในระดับโปรเซส/ไฟล์ ยืนยันว่า SQLite log ของ Codex เป็นแหล่งเขียนต่อเนื่องหลัก
  • คิดเป็นประมาณ 640TB ต่อปี หรือระดับการเขียนเต็มไดรฟ์ราว 640 ครั้งต่อปีสำหรับ SSD ขนาด 1TB
  • SSD ผู้บริโภคบางรุ่นมีเรตประมาณ 600 TBW จึงอาจใช้หมดอายุการรับประกันด้านการเขียนได้ภายใน ไม่ถึง 1 ปี

ข้อมูลหลักฐาน

  • Evidence1 — การขยายการเขียน (write amplification)

    • ขนาดไฟล์ logs_2.sqlite ปัจจุบัน: 1.2 GiB
    • จำนวนแถวที่คงอยู่ปัจจุบัน: 506,149 แถว
    • row id ที่ถูกจัดสรรสะสม: 5,543,677,486
    • มีช่องว่างประมาณ 10,000 เท่า ระหว่างแถวที่คงอยู่ (ราว 0.5M) กับ ID การแทรกสะสม (5.5 พันล้าน+) และแม้ไม่นับ WAL, index, pruning, checkpoint, page rewrite และการขยายระดับอุปกรณ์ ก็ยังประเมินได้ว่ามี historical log churn ระดับ 10TB+

  • Evidence2 — การกระจายตาม level/target

    • แถวที่คงอยู่ 681,774 แถว, คาดว่าคอนเทนต์ล็อกที่คงอยู่มีขนาดราว 1,035.6 MiB
    • สัดส่วนตามระดับ: TRACE 70.7%, INFO 25.7%, DEBUG 3.0%, WARN 0.6%
    • คู่ target+level ที่ใหญ่ที่สุด
      • 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
    • แหล่งข้อมูลอันดับต้น ๆ ส่วนใหญ่เป็น global TRACE log, telemetry log ที่ถูก mirror และการบันทึก raw websocket/SSE payload
    • codex_otel.log_only + codex_otel.trace_safe กินสัดส่วนเพิ่มอีก 25.3% และหากกรองหมวดนี้ออก จะสามารถตัดไบต์ของล็อกที่คงอยู่ในตัวอย่างได้ราว 96%
    • แหล่ง TRACE ที่พบบ่อยที่สุด (target=log) มีรายการระดับต่ำจำนวนมาก เช่น inotify event (เช่น ld.so.cache 128,764 ครั้ง), การเรียกภายในของ tokio-tungstenite, WouldBlock เป็นต้น

  • การวัด write amplification

    • ในตัวอย่าง 15 วินาที จำนวนแถวที่คงอยู่ไม่เปลี่ยนที่ 681,774 แถว แต่มีการ แทรกประมาณ 36,211 แถว
    • เกิด write amplification จากแพตเทิร์น insert-and-prune ที่ทำซ้ำระหว่างการแทรก→ทำดัชนี→เขียน WAL→pruning

สาเหตุที่คาดไว้

  • feedback log sink ของ SQLite ถูกติดตั้งด้วยค่า global TRACE default (Targets::new().with_default(Level::TRACE))
  • ส่งผลให้ทุก target ถูกเก็บถาวรที่ระดับ TRACE รวมถึงล็อกของ dependency/ภายใน และ raw protocol payload ขนาดใหญ่

แนวทางแก้ไขที่เสนอ

  • ยังคงเก็บ feedback log ไว้ แต่ลดขอบเขตการเก็บถาวรโดยค่าเริ่มต้น
    • ห้ามใช้ global TRACE กับ SQLite feedback log sink
    • ปรับ threshold ให้สูงขึ้นหรือตัด noise ที่มูลค่าต่ำออก เช่น target=log, hyper_util, รายการภายในของ tokio-tungstenite, inotify spam, และล็อกระดับต่ำของ OpenTelemetry SDK
    • แทนที่จะเก็บ raw websocket/SSE payload ทั้งหมด ให้เก็บเฉพาะสรุป (ชนิด event, เวลาที่ใช้, สำเร็จ/ล้มเหลว, ปริมาณ token ที่ใช้, ความยาวเป็นไบต์ของ payload)
    • หลีกเลี่ยงการเก็บ mirror event ของ codex_otel.log_only / codex_otel.trace_safe ยกเว้นกรณีที่มีประโยชน์ต่อการดีบัก
    • การจำกัดเฉพาะระดับ thread ไม่เพียงพอ จึงควรเพิ่ม เพดานขนาด/ปริมาณการเขียนของ global log DB
  • ตัวเลือกอย่าง sqlite_logs_enabled = false ก็มีประโยชน์ แต่การแก้หลักคือการกรองค่าเริ่มต้นให้ดีขึ้น

รายงานการทดสอบซ้ำได้หลายแพลตฟอร์ม

  • macOS

    • ในสภาพแวดล้อม macOS 15.7.7 / Codex 26.616.51431 พบ logs_2.sqlite ขนาด 113M, MAX(id)=34,277,360, แถวที่คงอยู่ 31,405 แถว และจากการเก็บตัวอย่าง 60 วินาที 2 ครั้ง พบการ เขียนประมาณ 60 ครั้งต่อวินาที
    • มีรายงานว่าระหว่างเซสชัน 1–2 ชั่วโมง โปรเซส codex เขียนข้อมูลประมาณ 50GB

  • Windows

    • บน Windows Codex Desktop (codex.exe app-server --analytics-default-enabled) แม้ไม่มีการตั้ง RUST_LOG=warn และไม่มีการตั้ง trace แบบ explicit ก็ยังมีการแทรกแถว TRACE อย่างต่อเนื่อง
    • มีแถวที่คงอยู่ราว 71k แถว และค่า logs ใน sqlite_sequence เกิน 18.5 ล้าน สะท้อนว่ามี insert/prune churn ในอดีตจำนวนมาก
    • จากการกระจาย 10 นาที พบ TRACE 1,812 แถว โดย target TRACE อันดับต้น ๆ มี codex_api::endpoint::responses_websocket (3.5MB+), codex_api::sse::responses
    • พฤติกรรมที่คาดหวังคือ เมื่อ RUST_LOG=warn ไม่ควรมีการเก็บ dependency/inner TRACE และ payload ขนาดใหญ่แบบถาวร

ความเสี่ยงเพิ่มเติมและวิธีบรรเทาชั่วคราว

  • ความเสี่ยงต่อการสูญหายของข้อมูล

    • หากดิสก์เต็มแล้วรีบูต อาจทำให้ล็อกอิน Linux ไม่ได้
    • โหมด /goal ของ Codex อาจพยายามคืนพื้นที่ดิสก์ด้วยการลบไฟล์/โฟลเดอร์ จนเกิด การสูญหายของข้อมูล

  • สคริปต์บรรเทาชั่วคราว

    • มี trim-codex-wal.sh สำหรับตัด WAL ระหว่างรัน (PRAGMA wal_checkpoint(TRUNCATE)), และสามารถรันผ่าน cron ทุก 15 นาทีได้
    • มี fix-codex-wal.sh ที่ลบไฟล์ log/WAL แล้วส่ง SIGTERM→SIGKILL ไปยังโปรเซสที่เกี่ยวข้องกับ Codex เพื่อคืนพื้นที่ดิสก์ทันที
    • หากเพิ่ม SQLite trigger (block_log_inserts) เพื่อเพิกเฉยต่อการแทรกในตาราง logs การเติบโตของ WAL จะหยุดลง และเมื่อต้องการย้อนกลับให้ใช้ DROP TRIGGER IF EXISTS block_log_inserts
      • เนื่องจาก VACUUM จะเขียน DB ใหม่ จึงอาจทำให้เกิดการเขียนครั้งใหญ่แบบครั้งเดียวในไฟล์ขนาดใหญ่ ดังนั้นจึงแนะนำให้เพิ่ม trigger แล้วตรวจสอบก่อนว่าการเติบโตของ WAL หยุดลง จากนั้นค่อยรัน DELETE/VACUUM
      • เพราะเป็นการแก้ไข private SQLite schema การอัปเดต/migration ของ Codex ในอนาคตอาจสร้างตารางใหม่ ลบ trigger หรือมีผลต่อการทำงานได้
    • มีการเสนอให้นำ DB นี้ไปไว้บน ramdisk จนกว่าจะมีการแก้ถาวร เพื่อป้องกันความเสียหายต่อ SSD

การแก้ไขและการปิดเรื่อง

  • เมื่อวันที่ 22 มิถุนายน 2026 การ merge PR สองรายการช่วยลดล็อกลงประมาณ 85% ทำให้ issue นี้ถูกทำเครื่องหมายว่าเสร็จสิ้น
    • หยุดการล็อกทุก Responses WebSocket event (#29432)
    • กรอง target ที่เป็น noise ออกจาก persistent log (#29457)
  • ในแพตช์ที่เสนอแยกต่างหาก มีการเปลี่ยนจาก global TRACE ไปเป็นการเก็บค่าเริ่มต้นแบบ INFO+ และยกระดับ codex_otel.log_only, codex_otel.trace_safe, hyper_util, log, opentelemetry_sdk เป็นต้น เป็น WARN+
  • การแก้ไขถูกรวมอยู่ในรีลีส rust-v0.142.0

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 3 시간 전
ความคิดเห็นจาก Hacker News

  • มองว่า Codex เป็นหนึ่งในตัวอย่างฉาวโฉ่ของ slopware
    บน macOS แค่เปิดหน้าต่างทิ้งไว้ก็ใช้ GPU 100% เพื่อแสดงข้อความ spinner
    บน MBP M5 แค่ข้อความ spinner ก็ทำให้ GPU ขึ้น 100% และพัดลมจะหมุนดังเกือบตลอดช่วงที่รอโมเดล จึงต้องระวังหากใช้งานด้วยแบตเตอรี่
    ปัญหานี้ถูกเปิดไว้บน GitHub มาเกือบ 6 เดือนแล้ว และน่าจะเป็นมาตั้งแต่หลังปล่อยของพะรุงพะรังที่ทำด้วย vibe coding ออกมา
    ต่อให้อยากแก้เองก็ทำไม่ได้ เพราะไม่รู้ทำไมถึงเป็นซอร์สปิด
    มีการถกเถียงกันมากว่าโมเดลไหนดีกว่าและ vibe coding ใช้ได้จริงแค่ไหน แต่ถ้าดูจากระดับที่บริษัทซึ่งมีทั้งเงิน คน และความสามารถของโมเดลมากที่สุดแห่งหนึ่งยังทำได้ด้วย vibe coding แค่นี้
    ในเมื่อ CEO ก็ประกาศแล้วว่าโฟกัสที่ “การเขียนโค้ด” ความผิดพลาดร้ายแรงแบบนี้จึงดูเป็นสัญญาณว่ามีบางอย่างภายในบริษัทพังจริง ๆ และใน Polymarket ก็แทบไม่มีใครคิดว่า OpenAI จะออกโมเดลชั้นนำได้ในเร็ว ๆ นี้
    น่าเศร้า เพราะโลกนี้ต้องการคู่แข่งของ Anthropic

    • ก็ต้องไม่ลืมว่า Claude Code ที่อยู่ข้าง ๆ กันก็เป็นอีกตัวอย่างของ slopware เช่นกัน
    • ถ้า AI ทำให้ผลิตภาพเพิ่ม 10 เท่าและเข้าใกล้ AGI หรือ ASI จริง ก็ไม่เข้าใจว่าทำไมผลิตภัณฑ์อย่าง Codex หรือ Claude Code CLI ยังห่วยได้ขนาดนี้
      รู้สึกว่า “การปฏิวัติ AI แบบเอเจนต์” น่าจะแก้ปัญหาพวกนี้ไปแล้วสิ
      คงไม่ถึงขั้นที่ภายในยังพูดกันว่า “กำลังประมวลผล กรุณารอสักครู่” หรือ “งานนี้ยากเกินไป” หรอกนะ
    • ตอนที่ทำงานในองค์กรที่ปกติเปิดซอร์สทุกอย่างเป็นพื้นฐาน เหตุผลเดียวที่ปล่อยให้บางอย่างเป็นซอร์สปิด แม้แต่โปรเจกต์ข้างเคียง ก็คือ ความอับอาย
      ไม่มีใครอยากเป็นหน้าสาธารณะของ codebase ขยะ
      ถ้ายังต้องเอาโค้ดนั้นไปใช้ตั้งราคาสูงลิ่ว ภาระนั้นก็คงหนักขึ้นราวสามเท่า
    • ไม่ใช่แค่ Codex แต่ แอป ChatGPT บน macOS ก็เหมือนกัน ถ้าเปิดทิ้งไว้หลายชั่วโมง RAM จะค่อย ๆ กินไปถึง 60GB แล้วทำให้แอปอื่นตายหมด
      ไม่เข้าใจเลย
      แม้แต่จะใช้ Google AI Studio บนเบราว์เซอร์ก็ยังกิน CPU 100%
      สุดท้ายก็ชวนให้คิดว่าต้องทำทุกอย่างเป็นแอปเองหรือไง
    • ตอนแรกผู้คนพูดกันว่าโลกนี้ต้องการ Anthropic มาเป็นคู่แข่งของ ChatGPT แต่ตอนนี้เหมือนทุกอย่างหมุนกลับมาครบรอบแล้ว

  • มี วิธีเลี่ยงชั่วคราว ของปัญหานี้โพสต์ไว้บน X[1]
    sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"
    และมีคนรัน VACUUM FULL กับไฟล์ sqlite นั้นบนโน้ตบุ๊กแล้วขนาดลดจาก 27GB เหลือ 73MB[2]
    [1]: https://xcancel.com/bdsqlsz/status/2067964486615810369
    [2]: https://xcancel.com/jeethu/status/2068087449469780434

    • คราวนี้ก็เป็น กฎระดับฐานข้อมูล ที่ช่วยกู้วันไว้ได้อีกแล้ว
    • วิธีแก้จริงคือเลิกใช้แล้วเปลี่ยนไปใช้ Pi

  • ทุกคนกำลังวิจารณ์ OpenAI ซึ่งก็สมควรแล้ว แต่ก็ควรจำไว้ว่า ต่างจาก Claude Code ตรงที่ Codex สามารถปรับแต่งได้อย่างเป็นทางการ: https://github.com/openai/codex
    และแพตช์ก็ทำได้ค่อนข้างง่าย

    • นั่นคือ CLI ไม่ใช่ แอป Codex แบบปิดที่กำลังพูดถึงกันอยู่ที่นี่

  • น่าตกใจมาก
    ประเด็นนี้เปิดมาเป็นสัปดาห์แล้ว แต่เท่าที่เห็น OpenAI แค่นิ่งเงียบ
    ไม่เข้าใจ เพราะคิดว่าผู้ขายแบบนี้น่าจะอ่อนไหวกับปัญหาประเภทนี้มาก
    แน่นอนว่าคงมีเอเจนต์หลายตัวคอยเฝ้าดู potential issue บน GitHub และเสนอแพตช์อยู่แล้วใช่ไหม? …ใช่ไหม?
    การให้เครื่องมือของตัวเองวิ่งไปแก้ GitHub issue แบบเรียลไทม์ก็น่าจะเป็นเรื่องเล็กน้อยสิ

    • ดูเหมือน OpenAI จะค่อนข้างอ่อนเรื่องการแก้ issue
      กรณีที่ชอบเป็นการส่วนตัวคือ #2472 ซึ่งสาธิตบนเวทีเปิดตัว GPT-5 ว่า “แก้แล้ว” แต่ ticket ยังเปิดอยู่ และ “แพตช์” นั้นก็ยังไม่ได้ merge
      โพสต์ต้นทางที่ชี้เรื่องนี้คือ https://blog.tymscar.com/posts/openaiunmergeddemo/ และ issue คือ https://github.com/openai/openai-python/issues/2472
    • มี GitHub issue เรื่องเดียวกันนี้มาตั้งแต่ เดือนเมษายน
      ใช้ Codex หนักมากและพอใจกับประสิทธิภาพของมันมาก (ทั้ง UX และผลลัพธ์) แต่ก็ยังยากจะเข้าใจว่าทำไมถึงยังไม่แก้ปัญหานี้

  • ปัญหานี้ ดูเหมือนจะแก้แล้ว[0] และน่าจะเข้ารีลีสถัดไป
    [0] https://github.com/openai/codex/commit/e98d43ac372ddf7f513c0...

  • vibe coding พาแนวคิด “move fast and break things” ไปอีกระดับจริง ๆ

    • ตอนนี้ที่บริษัทของเรา มี ขยะที่เขียนแบบ vibe coding ของใครสักคนพังหนักจนกำลังทำให้เกิด incident ใหญ่
    • ตอนนี้ของที่จะพังได้ก็กำลังเหลือน้อยลงเรื่อย ๆ แล้ว
    • ถ้าไม่มี technical debt, vibe coding ก็โดยรวมยังมีประโยชน์สำหรับการทำ prototype
      แต่ในผลิตภัณฑ์จริง วิศวกรซอฟต์แวร์ตัวจริงคงไม่มีวันถูกแทนที่

  • ออกจะนอกประเด็นนิดหน่อย แต่บริษัทพวกนี้ควรเลิกทำให้โฟลเดอร์รากของ repository รกด้วย Claude.md หรือ copilot.md ได้แล้ว
    น่าจะตกลงกันให้จบทีเดียวไปเลยกับโครงสร้างโฟลเดอร์มาตรฐานอย่าง docs/llm/*

  • ตอนปลายปีที่แล้ว ตอน Claude Code แย่เพราะอาการหน่วง OpenAI เคยเกือบคว้าโอกาสชนะไว้ได้แล้วแต่กลับปล่อยหลุดมือ
    ช่วงนี้ Codex มีอาการหน่วงตอนพิมพ์ตั้งแต่เริ่มใช้งาน ส่วน Claude Code แม้จะค้างเป็นบางครั้ง แต่โดยรวมเวลาเรากดปุ่ม… มันก็แสดงตามที่กดจริง ๆ

    • สำหรับผม มันตรงกันข้ามเป๊ะ
    • รู้สึกว่า Claude Code แทบใช้งานไม่ได้
      ถ้าจะพิมพ์เกินไม่กี่คำ ต้องไปพิมพ์ใน neovim ตลอด

  • ที่จริงนี่เป็นความผิดพลาดที่คลาสสิกมาก
    คือปล่อยโปรดักต์ออกมาโดยเปิด trace/debug log ทุกอย่างไว้ และที่น่าขำคือผลกระทบไม่ได้แสดงออกมาแบบเดิม ๆ
    แต่ก่อนถ้านักพัฒนาเปิด logging ระดับ trace แอปก็จะช้าจนน่าหายนะและแก้ในอัปเดตถัดไปทันที ทว่าตอนนี้ทั้งหน่วยความจำ ความเร็ว CPU และความเร็วดิสก์ดีขึ้นมหาศาลจนเราไปอยู่ในจุดที่ปัญหาไม่โผล่มาให้เห็นทันทีในแบบนั้นแล้ว ซึ่งบ้ามาก

    • อีกส่วนหนึ่งคือ งานแบบเอเจนต์รันอยู่ฝั่งเซิร์ฟเวอร์ เลยทำให้รู้สึกว่า thin client จะกิน ทรัพยากรในเครื่อง ไปหมดก็ไม่เป็นไร

  • อยากให้มีใครสักคนบริจาค โทเค็น ให้สตาร์ทอัปใจสู้รายนี้หน่อย ดูเหมือนพวกเขาจะต้องการความช่วยเหลือ