لم يكن السلوك الأصلي المتمثل في ارتفاع استخدام وحدة المعالجة المركزية مجرد «فهرسة عادية قد تستمر إلى ما لا نهاية». فبعد نقل كبير، searchd ظل عند استخدام وحدة المعالجة المركزية بنسبة 100% لساعات — وأفاد بعض المستخدمين بأنه استمر لعدة أيام — مما أدى إلى ارتفاع حرارة النظام وأجبرهم على الاختيار بين إيقاف البحث أو ترك وحدة المعالجة المركزية مشغولة.
قدمت IceWhale لاحقًا تفسيرًا دقيقًا: إذ قد تتسبب حالة طرفية عرضية في منطق تقسيم الصفحات في مشكلة الاستخدام المطول لوحدة المعالجة المركزية. وقد أُصلحت وحُسّنت في ZimaOS 1.3.2-beta2. وأضاف التحديث نفسه دمج محرك البحث بعد فترة من الخمول، وحافظ على دقة فهرسة أسماء الملفات وفي الوقت الفعلي، ونقل فهرسة محتوى الملفات إلى منتصف الليل مع خفض استهلاك الموارد. وقد تطورت وثائق بحث ZimaOS الحالية أكثر، إذ تتضمن حدودًا صريحة للاستخدام وعددًا أقل بكثير من الذاكرة والخدمات أثناء الخمول.
searchd مهيمنًا على استخدام وحدة المعالجة المركزية بعد اكتمال النقل بالفعل.يتطلب البحث فهرسًا
أوضح Zima-Giorgio في البداية أن وظيفة البحث في الملفات تحتاج إلى فهرسة الملفات. وكان ذلك صحيحًا، لكنه لم يفسر سبب بقاء استخدام وحدة المعالجة المركزية عند أقصى حد لفترات طويلة على نحو غير معتاد.
حددت IceWhale لاحقًا حالة طرفية في منطق تقسيم الصفحات
في 11 فبراير 2025، قال orca-zhang إن مشكلة ارتفاع استخدام وحدة المعالجة المركزية لفترة طويلة قد تنتج أحيانًا عن خطأ في منطق تقسيم الصفحات، وإن المشكلة أُصلحت وحُسّنت في 1.3.2-beta2.
وهذا هو الاستنتاج الأقوى من المصدر، وينبغي أن يحل محل التفسير السابق المبهم «إنه يقوم بالفهرسة».
أُضيف في الإصدار 1.3.2 دمج خدمة البحث أثناء الخمول
ذكرت IceWhale أنه عند عدم الحاجة إلى البحث، searchd سيتم تحريرها بعد نحو ثلاث دقائق من الخمول، مع الإبقاء على الخدمة الخفيفة فقط zimaos-search الخدمة بأقل من 100 ميغابايت من الذاكرة ونحو 0–1% من وحدة المعالجة المركزية.
نُقلت فهرسة المحتوى إلى منتصف الليل
وقد فصل الرد نفسه بين مهمتين:
- فهرس أسماء الملفات — يُحافَظ عليه بأكبر قدر ممكن من الدقة وفي الوقت الفعلي؛
- فهرس محتوى الملفات — يُؤجَّل حتى منتصف الليل ويُشغَّل مع استهلاك منخفض للموارد.
لا يزال هذا التمييز قائمًا في بنية البحث الحالية.
يضيف بحث ZimaOS الحالي حدودًا واضحة للموارد
تصف وثائق IceWhale الحالية ما يلي:
- مراقبة تغييرات الملفات وفهرسة أسماء الملفات في الوقت الفعلي؛
- فهرسة المحتوى عند منتصف الليل؛
- حد أقصى 100,000 مستند لكل نوع معالجة/جلسة؛
- حد أقصى خمس دقائق من وقت المعالجة لكل نوع؛
- حماية حاجز الكتابة من ارتفاعات استخدام المعالج؛
- طي الخدمة/الذاكرة بعد فترة من عدم النشاط.
استخدم بنية بحث ZimaOS الحالية.
كان من الممكن تعطيل البحث من ZimaOS 1.3.2
قال orca-zhang إن الاستمرارية المضافة إلى /etc في الإصدار 1.3.2، تمكّن المستخدمون الذين لا يحتاجون إلى البحث من تشغيل:
systemctl disable zimaos-searchيعني إيقاف البحث أو تعطيله أن البحث في الملفات سيُظهر أن الخدمة غير متاحة. ينبغي للمستخدمين الحاليين التحقق أولًا من سلوك البحث الحالي قبل تعطيل خدمة أساسية لمجرد وجود خطأ تاريخي.
كانت لقطة الشاشة التي تعرض “امتلاء” /dev/root بنسبة 100% تتعلق بمشكلة مختلفة
لاحظ مشارك آخر /dev/root أظهر استخدامًا بنسبة 100% وحاول تكبيره. أوضحت IceWhale أن تمثيل جذر SquashFS للقراءة فقط هذا مقصود للحفاظ على سلامة النظام، ولا ينبغي التعامل معه كقسم جذر تقليدي قابل للكتابة يحتاج إلى مساحة حرة.
لا تغيّر حجم أقسام نظام ZimaOS أو تحذفها لأن صورة SquashFS تُبلغ عن امتلائها.
إذا استخدم البحث معالجًا مرتفعًا في ZimaOS الحالية
- تأكد من أن النظام يعمل بأحدث إصدار مستقر من ZimaOS؛
- تحقق مما إذا كان قد تم استيراد ملف كبير للتو؛
- اسمح بانتهاء نافذة الفهرسة الموثقة؛
- راقب ما إذا كان استخدام المعالج ينخفض بعد فترة خمول الخدمة؛
- اجمع البيانات الحالية
zimaos-searchالسجلات إذا ظل استخدام المعالج مرتفعًا بعد الفترة المتوقعة بفترة طويلة.
الأسئلة الشائعة حول ارتفاع استخدام المعالج من searchd
هل اعتُبر استخدام المعالج بنسبة 100% لعدة أيام أمرًا طبيعيًا؟
لا. حدّدت IceWhale لاحقًا حالة طرفية في منطق ترقيم الصفحات وأصلحتها في 1.3.2-beta2.
متى تُجري ZimaOS الحالية فهرسة المحتوى؟
تشير الوثائق الحالية إلى أن فهرسة المحتوى تُجرى خلال ساعات انخفاض النشاط عند منتصف الليل، بينما تُفهرس تغييرات أسماء الملفات في الوقت الفعلي.
هل يعني وصول /dev/root إلى 100% أن قرص النظام نفدت مساحته الحرة؟
ليست في الحالة المصدرية. أوضحت IceWhale أن تمثيل جذر النظام SquashFS للقراءة فقط، ومن المتوقع أن يظهر ممتلئًا.
