حوّلت مشكلة حديثة في تسجيل سجلات Codex قاعدةَ بيانات محلية هادئة إلى كاتب كثيف على أقراص SSD بشكل مفاجئ. ووفقًا للتقرير الأصلي على GitHub، كان بإمكان سجلات ملاحظات SQLite الخاصة بـ Codex كتابة نحو 640 تيرابايت سنويًا ضمن نمط الاستخدام المُبلَّغ عنه. وبالنسبة إلى قرص SSD استهلاكي مُصنَّف بحوالي 600 تيرابايت مكتوبة إجمالًا، فإن هذا الرقم ليس مجرد فوضى بسيطة؛ بل يقترب من قدرة تحمّل الكتابة المضمونة للقرص.

الجزء الغريب هو أن قاعدة بيانات السجل لم تكن تبدو ضخمة. فقد كان حجم الملف قد يستقر حول غيغابايت واحد، بينما كانت عمليات الكتابة التاريخية الفعلية تتراكم في الخلفية. ولهذا جذبت هذه العلة كل هذا الاهتمام: فهي لم تكن تملأ القرص بطريقة واضحة، لكنها مع ذلك كانت قادرة على استهلاك دورات الكتابة.

ملاحظة المصدر: تستند هذه المقالة إلى إعادة نشر BAAI Hub لتقرير Xinzhiyuan، مع التحقق المتقاطع من المشكلة العامة على GitHub ونقاش Hacker News. لم تُدرج شعارات العلامات التجارية، ورموز QR، ودعوات المتابعة، والصور الزخرفية غير ذات الصلة من الصفحة الأصلية.

كيف يمكن أن تحدث كتابة 640 تيرابايت على قرص SSD

يبدو الرقم مبالغًا فيه في البداية، لذا من المفيد البدء بالقياس.

في مشكلة GitHub، قال المُبلِّغ إنه بعد نحو 21 يومًا من التشغيل المتواصل، كان قرص SSD الرئيسي قد كتب حوالي 37 تيرابايت. وعند استقراء ذلك على مدار عام كامل، يصبح الرقم تقريبًا 640 تيرابايت. وكان المصدر الرئيسي المُشتبه به هو قاعدة بيانات سجلات الملاحظات المحلية لـ SQLite الخاصة بـ Codex.

كان Codex يكتب إلى ملفات ضمن دليل الإعدادات المحلي:

~/.codex/logs_2.sqlite
~/.codex/logs_2.sqlite-wal
~/.codex/logs_2.sqlite-shm

لم يكن السلوك ببساطة «ملف السجل يستمر في النمو إلى الأبد». بل بدا أشبه بحلقة إدراج وتشذيب: كان Codex يُدرج صفوفًا جديدة، ثم يحذف الصفوف القديمة للحفاظ على ثبات عدد الصفوف المحتفَظ بها. ظل حجم الملف المرئي هادئًا نسبيًا، لكن محرك الأقراص كان لا يزال مضطرًا إلى معالجة عمليات الكتابة المتكررة.

أظهرت عينة مدتها 15 ثانية من التقرير المشكلة بوضوح:

هذا يعني أنه تم إدراج نحو 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")

كانت النتيجة نظام تسجيل محليًا يمكنه الاستمرار في إعادة كتابة التخزين مع إعطاء المستخدمين إشارات مرئية قليلة جدًا إلى حدوث أي أمر غير معتاد.

لا يزال بإمكان ملف بحجم 1 غيغابايت أن ينتج مئات التيرابايت من عمليات الكتابة

الجزء الأكثر مخالفة للحدس في هذه الحادثة بسيط: تآكل أقراص SSD يتعلق بإجمالي عمليات الكتابة، وليس بحجم الملف الحالي.

يمكن لقاعدة بيانات محلية أن تبقى في حدود 1 غيغابايت بينما يكتب التطبيق أجزاءً منها ويقلّمها ويفهرسها وينشئ نقاط تحقق لها ويعيد كتابتها مرارًا. ومن منظور صحة التخزين، لا يهم فقط مدى كبر حجم الملف كما يبدو اليوم. ما يهم هو مقدار البيانات التي كُتبت بمرور الوقت.

تضمّن التقرير لقطة واحدة جعلت الفجوة أسهل في الملاحظة:

احتفظت قاعدة البيانات الحالية بنحو نصف مليون صف فقط، بينما كان معرّف الصف المتزايد تلقائيًا قد تجاوز بالفعل 5.5 مليار. وهذا هو جوهر قصة تضخيم الكتابة: يمكن أن تختفي الصفوف القديمة من العرض الحالي لقاعدة البيانات، لكن عمليات الكتابة على القرص التي أنشأتها كانت قد حدثت بالفعل.

كما أن سجل الكتابة المسبقة في SQLite، أو WAL، مهم هنا أيضًا. في وضع WAL، تُلحَق التغييرات بملف -wal منفصل قبل تنفيذ نقطة تحقق لإعادتها إلى قاعدة البيانات الرئيسية. يُعد WAL آلية عادية ومفيدة في SQLite، ولكن عندما ينفّذ تطبيق عمليات إدراج وحذف متكررة جدًا، يمكنه أن يضاعف مقدار نشاط القرص الذي يحدث خلف الكواليس.

بعبارة بسيطة: لا يزال الدفتر يبدو رقيقًا، لكن الصفحات نفسها كُتبت ومُحيت وأُعيدت كتابتها مرات عديدة.

السبب الجذري: إعداد RUST_LOG لم يتصرف كما توقع المستخدمون

أشار التقرير إلى تفصيل تكوين مهم للغاية في مسار تسجيل Codex:

Targets::new().with_default(Level::TRACE)

في منظومة tracing في Rust، غالبًا ما يتم التحكم في تصفية السجلات من خلال الأهداف والمستويات. قد يتوقع المستخدمون بشكل معقول أن يساعد متغير البيئة RUST_LOG في تقليل إسهاب السجلات إلى شيء مثل info أو warn أو أقل.

لكن في هذا المسار، استخدم مصرف سجل الملاحظات الراجعة SQLite مستوى افتراضيًا هو TRACE. يُعد TRACE المستوى الأكثر إسهابًا، ويمكنه التقاط تفاصيل منخفضة المستوى للتبعيات، ونشاط البروتوكول الخام، وغير ذلك من ضجيج التصحيح. وجادل تقرير المشكلة بأن هذا الإعداد الافتراضي يعني أن قاعدة بيانات السجل المحلية الدائمة ظلت تخزن أكثر بكثير مما ينبغي.

أظهر توزيع السجلات المحتفظ بها مدى هيمنة المحتوى على مستوى TRACE:

أشار التقرير أيضًا إلى أن مصدرَي سجلات مرتبطين بـ OpenTelemetry ومطابقين، وهما codex_otel.log_only وcodex_otel.trace_safe، شكّلا جزءًا كبيرًا آخر من بايتات السجلات المحتفَظ بها. وفي تلك العينة، قدّر صاحب التقرير أن تصفية هذه الفئات المزعجة قد تزيل معظم حجم السجلات المحتفَظ به دون تعطيل سجلات الملاحظات بالكامل.

لهذا السبب كان الخطأ محبطًا جدًا للمطورين. لم يكن الأمر مجرد «لقد نسيتَ تهيئة التسجيل». بل بدا أشبه بـ «لقد حاولتَ تقليل التسجيل، لكن هذا المسار ظلّ يحتفظ بسجلات مطوّلة على أي حال».

لم تكن هذه أول مشكلة ذات صلة

لم يتعامل التقرير مع هذا الأمر على أنه حادثة منفردة ومعزولة. فقد أدرج مجموعة من مشكلات Codex ذات الصلة بسجلات SQLite، ونمو WAL، والنشاط الكثيف للقرص، والتسجيل المحلي غير المحدود أو المفرط.

تضمنت بعض الأمثلة المذكورة في التقرير ما يلي:

الدرس الأكبر ليس أن SQLite سيئ، أو أن التسجيل سيئ. فكلاهما مفيد. الدرس هو أن الوكيل المحلي الذي يعمل لجلسات طويلة يحتاج إلى ميزانية موارد صريحة.

تُعامَل أدوات البرمجة بالذكاء الاصطناعي بشكل متزايد كشركاء تطوير يعملون دائمًا. فهي تقرأ الملفات، وتراقب المستودعات، وتُبقي الجلسات نشطة، وتجمع بيانات القياس عن بُعد، وتحافظ على السياق. وهذا يجعل ميزانيات القرص المحلي والذاكرة ووحدة المعالجة المركزية مهمة بقدر أهمية ميزانيات الرموز وجودة النموذج.

دُمجت الإصلاحات، لكن النقاش لم ينتهِ

أضافت مشكلة GitHub لاحقًا تحديثًا يفيد بأنه تم دمج ثلاثة طلبات سحب، وأن ملاحظات Codex الخاصة بالمبلّغ أشارت إلى انخفاض تقديري في السجلات بنسبة 85%.

سردت المشكلة الإصلاحات الثلاثة على النحو التالي:

يُعدّ انخفاضًا بنسبة 85% أمرًا كبيرًا، لكنه ليس مثل إثبات أن التسجيل المحلي أصبح لديه الآن حدّ صارم طويل الأمد لعمليات الكتابة. وهذا التمييز هو سبب استمرار النقاش. لم يكن المطورون يسألون فقط عمّا إذا كان هذا الخطأ المحدد قد تم تقليصه؛ بل كانوا يسألون عمّا إذا كان ينبغي لوكلاء البرمجة بالذكاء الاصطناعي أن تكون لديهم حدود أوضح للقياسات المحلية المستمرة.

تضمّنت مشكلة 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;"

استخدم الحلول البديلة مثل هذا بحذر. فقد تقلل من عمليات كتابة السجلات المحلية، لكنها قد تزيل أيضًا بيانات تشخيصية قد تحتاجها فرق الدعم أو المطورون لاحقًا. عمومًا، يُعد التحديث إلى إصدار تم إصلاحه والتحقق من سلوك السجل الحالي أكثر أمانًا من تعديل قاعدة بيانات تطبيق بصمت من دون فهم المفاضلة.

معركة أدوات البرمجة تحرق أكثر من أقراص SSD

انتقل النقاش بسرعة إلى ما هو أبعد من Codex وحده. على Hacker News، أثار المطورون أيضًا شكاوى أوسع بشأن أدوات البرمجة بالذكاء الاصطناعي: استخدام مرتفع لوحدة معالجة الرسومات، واستهلاك كبير للذاكرة، ونشاط في الخلفية، وسجلات تصحيح محلية كبيرة.

ردّ الفعل هذا منطقي. لم تعد مساعدات البرمجة الحديثة بالذكاء الاصطناعي مجرد أدوات بسيطة لسطر الأوامر. فكثير منها يتصرف أشبه بوكلاء محليين: يراقبون المشاريع، ويتواصلون مع نماذج بعيدة، ويديرون السياق، ويشغّلون الأوامر، ويحافظون على الحالة عبر المهام. هذه القوة مفيدة، لكنها تخلق أيضًا فئة جديدة من المسؤولية الهندسية.

قد تبدو الأداة “جيدة” في واجهة المستخدم بينما تستهلك الموارد بهدوء في الخلفية. يمكن لوحدات المعالجة المركزية السريعة، والذاكرة الكبيرة، وأقراص NVMe الحديثة أن تخفي المشكلات لفترة طويلة. قد لا يتجمّد التطبيق. وقد لا يمتلئ القرص. وقد تظل المحطة الطرفية تستجيب. لكن مؤشرات صحة العتاد قد تروي قصة مختلفة.

لهذا السبب أصبحت هذه الحادثة دراسة حالة مفيدة لأدوات المطورين المعتمدة على الذكاء الاصطناعي. قدرات النموذج مهمة، لكن جودة التشغيل المحلي مهمة أيضًا. يحتاج وكيل برمجة يعيش على جهاز المطور إلى إعدادات افتراضية معقولة، وحدود للاحتفاظ بالبيانات، وتدوير للسجلات، وطريقة تمكّن المستخدمين من فهم ما يفعله.

الأسئلة الشائعة

ما خطأ سجل SQLite في Codex؟

كان ذلك مشكلة مُبلّغًا عنها في تسجيل Codex، حيث كان من الممكن لسجلات الملاحظات المحلية المخزنة في SQLite أن تولّد كميات كبيرة جدًا من عمليات الكتابة على القرص. وقد قدّر تقرير GitHub نحو 640 تيرابايت من عمليات الكتابة سنويًا وفق نمط الاستخدام الذي قاسه مُقدّم التقرير.

لماذا يمكن أن يؤدي ملف logs_2.sqlite صغير إلى تآكل قرص SSD؟

تعتمد قدرة تحمّل أقراص SSD على إجمالي البيانات المكتوبة بمرور الوقت، وليس فقط على حجم الملف الحالي. يمكن لقاعدة البيانات أن تُدرج وتحذف وتكتب إلى WAL وتُجري نقاط تحقق وتحدّث الفهارس بشكل متكرر، بينما تظل صغيرة ظاهريًا على القرص.

ماذا يعني SQLite WAL في هذا السياق؟

يرمز WAL إلى التسجيل المسبق للكتابة. يكتب SQLite التغييرات أولًا في ملف منفصل باسم -wal ثم يضع لها نقاط تحقق لاحقًا لإعادتها إلى قاعدة البيانات الرئيسية، وهذا سلوك طبيعي لكنه قد يسبب نشاطًا كبيرًا عندما تحدث عمليات الإدراج والحذف بوتيرة عالية جدًا.

ما الدور الذي لعبه تسجيل TRACE؟

TRACE هو أكثر مستويات السجل تفصيلًا. في العينة المُبلّغ عنها، شكّل محتوى مستوى TRACE نحو 70.7% من بايتات السجل المحتفَظ بها، وذكرت المشكلة أن سجلات التبعيات والبروتوكولات المطوّلة كانت تُحفَظ افتراضيًا.

هل أصلحت OpenAI مشكلة تسجيل Codex؟

قال تحديث مشكلة GitHub إنه تم دمج ثلاثة طلبات سحب، وقدّر المُبلّغ أنه يمكنهم تجنّب نحو 85% من السجلات بناءً على الملاحظات من استخدامه لـ Codex. وقد أُدرج إصلاحان على أنهما صادرا في 0.142.0، بينما أُدرج الإصلاح الثالث على أنه مخطط له في 0.143.0.

هل ينبغي للمستخدمين حذف سجلات Codex أو حظرها يدويًا؟

ينبغي التعامل مع التغييرات اليدوية بحذر لأنها قد تزيل معلومات تشخيصية وقد تكون لها آثار جانبية. الخطوة الأولى الأكثر أمانًا هي تحديث Codex، وفحص ملفات السجل، ومراقبة عدادات الكتابة على SSD إذا كنت قلقًا.

هل هذه مشكلة تخص Codex فقط؟

ركّز هذا التقرير المحدد على Codex. ومع ذلك، ينطبق القلق الأوسع على وكلاء الذكاء الاصطناعي المحليين عمومًا: فالأدوات التي تعمل دائمًا تحتاج إلى ميزانيات موارد واضحة للقرص ووحدة المعالجة المركزية والذاكرة والقياسات عن بُعد والسجلات المحتفَظ بها.

الأدوات ذات الصلة

• مستودع OpenAI Codex على GitHub: المستودع العام لواجهة سطر أوامر Codex والشيفرة المصدرية ذات الصلة.

• SQLite: محرك قاعدة البيانات المضمّن المستخدم في العديد من التطبيقات والأدوات المحلية.

• توثيق SQLite لتسجيل الكتابة المسبقة: التوثيق الرسمي الذي يشرح كيفية عمل WAL وسبب أهمية نقاط التحقق.

• تتبّع Rust: إطار عمل التسجيل المنظّم والتشخيصات في Rust الذي نوقش في مشكلة Codex.

• smartmontools: مجموعة أدوات لفحص بيانات صحة التخزين SMART، بما في ذلك عدادات الكتابة على أقراص SSD في الأقراص المدعومة.

• Hacker News: منصة النقاش التي جذب فيها تقرير تسجيل Codex اهتمامًا أوسع من المطورين.

روابط ذات صلة

• مشكلة سجلات ملاحظات Codex SQLite رقم #28224: مشكلة GitHub الرئيسية التي توثق تقدير الكتابة المُبلّغ عنه البالغ 640 تيرابايت سنويًا والأدلة.

• إيقاف تسجيل كل حدث WebSocket في Responses #29432: أحد طلبات السحب المدمجة المدرجة كجزء من عمل تقليل التسجيل.

• تصفية الأهداف المزعجة من السجلات الدائمة #29457: طلب السحب الذي ركّز على تصفية أهداف التسجيل الدائم المزعجة.

• إيقاف الاحتفاظ بأحداث السجل الممرَّرة #29599: طلب السحب اللاحق الذي هدف إلى إيقاف الاحتفاظ بأحداث سجلات التبعيات الممرَّرة.

• نقاش Hacker News: نقاش مجتمعي حول تسجيل Codex، وعمليات الكتابة على SSD، وجودة أدوات البرمجة بالذكاء الاصطناعي.

• ملف README الخاص بواجهة سطر أوامر OpenAI Codex: ملف README الرسمي للمستودع لتثبيت وتشغيل واجهة سطر أوامر Codex.

• توثيق SQLite WAL: شرح رسمي لملفات WAL ونقاط التحقق واعتبارات الأداء.