عندما amavisdتصل نسبة استهلاك وحدة المعالجة المركزية (CPU) في عملية ما إلى 100% أو ما يقاربها، فإن الهدف ليس مجرد إيقاف تلك العملية. بل يجب أن يُعيد الحل الفعال تدفق البريد إلى وضعه الطبيعي، ويُقلل زمن الاستجابة، ويُحافظ على فعالية برامج مكافحة البريد العشوائي والفيروسات، ويمنع تزايد حجم قائمة انتظار Postfix.
في نظام زيمبرا، يقع برنامج Amavisd-New بين خادم نقل البريد (MTA) وبرامج فحص المحتوى. يصف دليل إدارة Daffodil الحالي لنظام زيمبرا برنامج Amavisd-New بأنه الواجهة بين خادم نقل البريد (MTA) الخاص بزيمبرا، وبرنامج ClamAV، وبرنامج SpamAssassin. هذا يعني أن ارتفاع استهلاك وحدة المعالجة المركزية (CPU) قد يكون ناتجًا عن برنامج Amavis نفسه، أو عن قواعد SpamAssassin أو محتوى الرسائل، أو عن فحص مكافحة الفيروسات، أو عن تراكم المهام الذي يُبقي جميع الموارد المتاحة مشغولة. راجع دليل إدارة Daffodil لنظام زيمبرا .
تتجلى النتائج الناجحة في أربعة مؤشرات: انخفاض استهلاك وحدة المعالجة المركزية (CPU) في برنامج Amavis إلى مستوى مستدام، وتوقف تراكم الرسائل المؤجلة والنشطة، ومرور الرسائل الجديدة دون تأخير غير معتاد، وبقاء خدمات مكافحة البريد العشوائي/الفيروسات فعّالة. أما إذا انخفض استهلاك وحدة المعالجة المركزية (CPU) فقط بسبب تعطيل خاصية التصفية، فهذا يعني أن المشكلة الأساسية لم تُحل.
ابدأ من مستوى نظام التشغيل. لا تفترض أن برنامج Amavis مسؤول عن بطء تسليم البريد. تحقق من العمليات الأكثر استهلاكًا للموارد وتأكد مما إذا كان واحد أو أكثر amavisdمن العاملين يستهلكون باستمرار نواة معالج كاملة.
top -c
ps -eo pid,user,pcpu,pmem,etime,cmd --sort=-pcpu | head -20
التعليق: عرض طرفي حيث يكون amavisd هو المستهلك الرئيسي لوحدة المعالجة المركزية، وهو الشرط الأول الذي يجب التحقق منه قبل تغيير إعدادات Zimbra.
قد يكون الارتفاع الطفيف في معدل نقل البيانات طبيعيًا أثناء فحص رسالة كبيرة أو مرفق مضغوط. تعامل مع المشكلة على أنها مستمرة إذا استمرت الأعراض نفسها مع ازدياد تأخيرات البريد أو عمق قائمة الانتظار. تحقق أيضًا من متوسط الحمل، والذاكرة المتاحة، ونشاط التبديل، ووقت انتظار الإدخال/الإخراج. قد يتطلب ارتفاع استهلاك وحدة المعالجة المركزية مع استخدام مكثف للتبديل أو التنافس على التخزين فحصًا شاملًا على مستوى النظام المضيف بدلًا من إجراء تغيير على برنامج Amavis فقط.
انتقل إلى حساب Zimbra واطلع على حالة الخدمة. تستخدم وثائق Zimbra zmcontrol statusهذه الطريقة كفحص قياسي للخدمات المُفعّلة.
su - zimbra
zmcontrol status
zmamavisdctl status
التعليق: حالة خدمة Zimbra تُظهر تشغيل مكونات Amavis ومكافحة البريد العشوائي ومكافحة الفيروسات وMTA قبل بدء عملية استكشاف الأخطاء وإصلاحها.
تُعدّ هذه الخطوة مهمة لأنّ "استهلاك وحدة المعالجة المركزية بنسبة 100%" و"توقف الخدمة" هما حالتا عطل مختلفتان. إذا لم يكن برنامج Amavis قيد التشغيل، فابحث عن أخطاء بدء التشغيل. أما إذا كان Amavis قيد التشغيل ولكنه مُحمّل بالكامل، فتابع تحليل قائمة الانتظار والسجلات.
يُشير عمق قائمة الانتظار إلى ما إذا كان ارتفاع استهلاك وحدة المعالجة المركزية يؤثر على التسليم. راجع وثائق استكشاف أخطاء قائمة الانتظار في Zimbra zmqstatلمعرفة عدد قوائم الانتظار، وأوامر قائمة انتظار Postfix لمعرفة تفاصيل الرسائل. شغّل عمليات الفحص بشكل متكرر بفارق بضع دقائق.
sudo /opt/zimbra/libexec/zmqstat
postqueue -p
التعليق: توفر إحصائيات قائمة الانتظار والرسائل المؤجلة مقياسًا أفضل لتأثير تدفق البريد من نسبة استخدام وحدة المعالجة المركزية وحدها.
ابحث عن الاتجاه العام، لا عن رقم معزول. يشير ازدياد حجم قائمة الانتظار مع كل عينة إلى أن معدل نقل البيانات أقل من معدل وصولها. أما انخفاض حجم قائمة الانتظار بشكل مطرد بعد إجراء تغيير ما، فهو من أقوى المؤشرات على أن هذا التغيير قد ساهم فعلاً في تحسين الأداء.
إذا كنت تستخدم نشرًا متعددًا لخوادم نقل البريد (MTA)، فتحقق من خادم MTA المتأثر تحديدًا. لا تفترض أن قائمة الانتظار على خادم آخر تعكس نفس الاختناق.
تُكتب رسائل استكشاف الأخطاء وإصلاحها الخاصة بـ Amavis و SpamAssassin إلى /var/log/zimbra.log. ابحث في وقت ذروة استخدام وحدة المعالجة المركزية وقم بربط معرفات الرسائل ومعرفات العمليات ومدة الفحص.
grep -iE 'amavis|spamassassin|clam' /var/log/zimbra.log | tail -n 200
التعليق: يمكن أن تكشف سجلات Amavis و SpamAssassin ما إذا كانت الرسائل الفردية أو مراحل المسح تستغرق وقتًا طويلاً بشكل غير عادي.
تشمل الأنماط المفيدة عمليات المسح المطولة المتكررة لبرنامج SpamAssassin، وإعادة المحاولات المتكررة لنفس معرّفات قائمة الانتظار، وأخطاء الاتصال ببرنامج ClamAV، وفشل عمليات فك الضغط، أو مجموعة صغيرة من الرسائل التي تستهلك موارد المعالج بشكل متكرر. توصي وثائق استكشاف الأخطاء وإصلاحها في Zimbra تحديدًا بتسجيل تصحيح أخطاء Amavis وSpamAssassin عندما تؤدي تأخيرات المسح إلى تعطيل تدفق البريد. راجع مرجع استكشاف أخطاء التسجيل وإصلاحها في Zimbra .
يُتيح Zimbra أدوات تحكم منفصلة لتسجيل الأحداث لكلٍ من Amavis و SpamAssassin. يتراوح نطاق Amavis الموثق من 0 إلى 5، بينما zimbraAmavisSALogLevelيستخدم SpamAssassin القيمتين 0 أو 1. ابدأ بمستوى Amavis 2 بدلاً من أعلى مستوى تفصيلي إلا إذا كنت بحاجة إلى تصحيح أخطاء أكثر دقة.
su - zimbra
zmprov mcf zimbraAmavisLogLevel 2
zmprov mcf zimbraAmavisSALogLevel 1
التعليق: التغييرات المؤقتة في التسجيل تجعل من السهل ربط توقيت الفحص وسلوك SpamAssassin بارتفاع استخدام وحدة المعالجة المركزية.
قم بإعادة إنتاج المشكلة أو مراقبتها لفترة كافية فقط لجمع بيانات مفيدة. زيادة مستوى التسجيل يؤدي إلى زيادة عمليات الكتابة على القرص، مما قد يزيد من ضجيج الخادم المشغول. بعد التحقيق، عد إلى قيمك السابقة؛ تشير وثائق Zimbra إلى أن مستوى تسجيل SpamAssassin الافتراضي هو 0، بينما يكون مستوى تسجيل Amavis منخفضًا عادةً.
zmprov mcf zimbraAmavisSALogLevel 0
zmprov mcf zimbraAmavisLogLevel 1إذا أشارت السجلات باستمرار إلى SpamAssassin، فتحقق مما إذا كانت المشكلة قد بدأت بعد تغيير القواعد، أو نشر قاعدة مخصصة، أو فشل تحديث القاعدة. قد تتسبب التعابير النمطية المصممة بشكل سيئ والقواعد الإشكالية في تكلفة عالية على بعض محتويات الرسائل.
توضح مواد استكشاف الأخطاء وإصلاحها الرسمية الخاصة بـ Zimbra Amavis أمر تحديث SpamAssassin المدمج لإصدار ZCS 8.8 والإصدارات الأحدث على النحو التالي:
su - zimbra
/opt/zimbra/common/bin/sa-update -D
التعليق: تحديث قواعد SpamAssassin المضمنة مناسب عندما تشير السجلات أو أخطاء بدء التشغيل إلى بيانات قواعد قديمة أو تالفة.
لا تعتبر هذه الطريقة sa-updateحلاً شاملاً لمشكلة وحدة المعالجة المركزية. إذا بدأ الارتفاع المفاجئ في استهلاك وحدة المعالجة المركزية مباشرةً بعد إضافة قاعدة مخصصة، فاختبر تلك القاعدة أولاً. يخزن Zimbra قواعد SpamAssassin المخصصة الحديثة في مجلد معين /opt/zimbra/data/spamassassin/localrules/. قم بإزالة أو تعطيل التخصيص المشتبه به فقط خلال فترة صيانة محددة، ثم قارن وقت الفحص وسلوك قائمة الانتظار.
تشير صفحة ويكي زيمبرا الرسمية أيضًا إلى تحديث القواعد التلقائي وإعدادات التجميع لإصدارات ZCS الأحدث. راجع استراتيجيات زيمبرا لمكافحة البريد العشوائي قبل تفعيل السلوك التلقائي على خادم قائم.
قد يؤدي إعادة التشغيل إلى حل مشكلة توقف العمليات وتحميل القواعد المحدثة، ولكن ينبغي أن يتم ذلك بعد التشخيص وليس كبديل له. أعد تشغيل Amavis فقط أولاً ما لم تشير الأدلة إلى وجود مشكلة في مجموعة MTA الأوسع.
su - zimbra
zmamavisdctl restart
التعليق: إعادة تشغيل Amavis تعيد تحميل الخدمة بعد تغيير القواعد أو التكوين المستهدف دون إعادة تشغيل جميع خدمات Zimbra بشكل غير ضروري.
إذا عاد استخدام وحدة المعالجة المركزية إلى 100% فورًا، فهذا دليل مفيد: لا يزال السبب قائمًا. ارجع إلى سجلات النظام وتحقق مما إذا كانت الرسالة أو الماسح الضوئي أو القاعدة نفسها تظهر مجددًا. قد يؤدي إعادة تشغيل الخدمة بشكل متكرر إلى تخفيف الأعراض مؤقتًا مع السماح لقائمة الانتظار بالنمو.
لا تعتبر المشكلة محلولة بمجرد رؤية انخفاض في استخدام وحدة المعالجة المركزية لمرة واحدة. تحقق من حمل العمليات، واتجاه قائمة الانتظار، وحالة الخدمة معًا.
top -c
sudo /opt/zimbra/libexec/zmqstat
zmcontrol status
التعليق: يكون التعافي أقوى عندما يتحسن استخدام وحدة المعالجة المركزية وعمق قائمة الانتظار وحالة خدمة Zimbra في نفس الوقت.
ثم أرسل رسالة اختبار عبر خادم البريد المتأثر وتأكد من وصولها ضمن نطاق زمن الاستجابة المعتاد. بالنسبة للرسائل التي يفترض أن تجتاز عملية التصفية، افحص رؤوسها بحثًا عن حقول فحص البريد العشوائي والفيروسات المتوقعة في Zimbra/Amavis. يوثق Zimbra رؤوسًا مثل هذه، X-Virus-Scannedويحدد X-Spam-Statusمتى تكون هذه الفحوصات نشطة.
| ما تلاحظه | أفضل إجراء تالٍ | لماذا |
|---|---|---|
| تتسبب رسالة واحدة بشكل متكرر في عمليات مسح طويلة | قم بعزل تلك الرسالة أو فحصها بأمان، واربط معرّف قائمة الانتظار الخاص بها بالسجلات. | قد يكون الاختناق مرتبطًا بالمحتوى وليس بالقدرة الاستيعابية |
| توقيت SpamAssassin هو المسيطر | مراجعة القواعد المخصصة، وتحديثات القواعد، ومخرجات تصحيح الأخطاء | قد تجعل مجموعات القواعد التي تعتمد بشكل كبير على التعبيرات النمطية أو التالفة عملية التسجيل مكلفة. |
| تسود أخطاء أو مهلات ClamAV | تحقق من حالة برنامج مكافحة الفيروسات وقم بتحديثها. | قد يكون برنامج أمافيس ينتظر ببساطة الماسح الضوئي الذي يستدعيه |
| استهلاك وحدة المعالجة المركزية مرتفع، لكن قوائم الانتظار تبقى قريبة من الصفر. | راقب الوضع لفترة أطول قبل إجراء تغييرات جذرية. | يمكن أن يكون الاستخدام العالي مقبولاً إذا ظل معدل نقل البيانات وزمن الاستجابة ضمن الحدود المقبولة. |
| تتزايد قوائم الانتظار حتى بعد إجراء الإصلاحات المستهدفة. | قم بالتصعيد إلى تحليل مستوى السعة أو نمط الرسائل أو مستوى الدعم | قد يكون الخادم صغير الحجم، أو يتعرض لهجوم، أو يعاني من خلل برمجي محدد. |
لا تُعطّل فحص مكافحة البريد العشوائي أو الفيروسات بشكل دائم لمجرد خفض استهلاك وحدة المعالجة المركزية. يدعم Zimbra سياسات التجاوز لحركة مرور محددة موثوقة/مصدرها، لكن هذا يُغيّر نموذج الأمان، ويجب أن يكون قرارًا مدروسًا ضمن سياسة البريد، وليس مجرد تحسين عام للأداء. توضح وثائق Zimbra الخاصة بتجاوز SpamAssassin المصدر أن هذا التجاوز مرتبط بالشبكات الداخلية الموثوقة.
تجنب أيضًا زيادة عدد عمال Amavis بشكل عشوائي. فزيادة عدد العمال قد تزيد من التزامن، ولكنها تزيد أيضًا من ضغط الذاكرة وقد تُفاقم مشكلة التنافس على وحدة المعالجة المركزية. تعتمد القيمة الصحيحة على مزيج الرسائل، وحجم المرفقات، وسلوك الماسح الضوئي، والأنوية المتاحة، والذاكرة، وعمليات الإدخال/الإخراج. اختبر التغييرات مقابل إنتاجية قائمة الانتظار وزمن الاستجابة بدلاً من افتراض أن زيادة عدد العمال أسرع.
صُمم هذا الإجراء للحالة الشائعة التي يكون فيها برنامج Amavis قيد التشغيل ولكنه يعاني من استهلاك مفرط لوحدة المعالجة المركزية. ولا يغني هذا الإجراء عن إرشادات دعم Zimbra الخاصة بكل إصدار في حالات وجود عيب مؤكد في المنتج، أو خادم مخترق، أو حملة حجب الخدمة باستخدام رسائل مشوهة، أو بنية متعددة العقد مع ماسحات ضوئية خارجية.
وثّقت المواد التقنية لمجتمع Zimbra حالات سابقة تسببت فيها رسائل مُصممة خصيصًا أو سلوك SpamAssassin في استهلاك موارد وحدة المعالجة المركزية (CPU) لخوادم Amavis لفترات طويلة. ولأن مستوى التعرض يعتمد على إصداري Zimbra وSpamAssassin المُثبتين، فلا تُطبّق وصفة ترقية قديمة دون تدقيق. سجّل أولًا إصدار Zimbra لديك zmcontrol -v، وقارنه بالإصدار المدعوم ومستوى التصحيح، ثم اتبع إرشادات المورّد الحالية للترقية.
قارن بين 10 أدوات مسح الشبكة المحلية (Ping) لاكتشاف الشبكات المحلية بسرعة، وإجراء مسح شامل للأنظمة الأساسية المختلفة، وإدارة عناوين IP. تعرّف على ما يمكن أن يكشفه لك المسح وما لا يمكنه كشفه.
قارن بين ست أدوات لإدارة الشبكة لمراقبة الأداء، بما في ذلك تغطية SNMP، ورسم الخرائط، والتنبيهات، ونماذج النشر، والمفاضلات المتعلقة بالتكلفة.
قارن بين أفضل برامج تحليل شبكة Wi-Fi لأنظمة Windows و iPhone و Android، بما في ذلك أدوات ازدحام القنوات وتغطية الإشارة والخرائط الحرارية واستكشاف أخطاء الشبكة وإصلاحها.
قارن بين سبعة برامج مراقبة زمن الاستجابة المجانية والمفتوحة المصدر، بدءًا من مجموعات الشبكة الكاملة وحتى مجسات زمن الاستجابة المركزة، واختر البرنامج المناسب من حيث التوافر وفقدان الحزم والسجل.
تعرف على معنى جودة الخدمة في الشبكات، وكيف تحدد علامات DSCP وقوائم انتظار حركة المرور أولويات تطبيقات الصوت والفيديو والأعمال، وما لا تستطيع جودة الخدمة إصلاحه.
قم ببناء نظام مراقبة شبكة عملي مع تغطية واضحة للأجهزة، ومقاييس أداء مفيدة، وتنبيهات قابلة للتنفيذ، ومقارنة بين SolarWinds NPM وPRTG وOpManager.
قارن بين برامج خوادم SFTP الموثوقة لأنظمة ويندوز ولينكس، بما في ذلك OpenSSH وBitvise وSolarWinds وSFTPGo. اعثر على الخيار الأمثل الذي يلبي احتياجاتك الأمنية واحتياجات نقل الملفات.
قارن بين سبع أدوات لإدارة عناوين IP لاكتشاف الشبكات الفرعية، وتنسيق DNS وDHCP، وجرد الشبكة، وIPAM مفتوح المصدر.
قارن بين أدوات فحص الشبكة لاكتشاف الأجهزة بسرعة، وعمليات فحص IP عبر الأنظمة الأساسية، وإدارة عناوين IP للمؤسسات، مع إرشادات حول مطابقة كل خيار مع شبكتك.
استخدم خيار --traceroute في Nmap لرسم خرائط القفزات إلى مضيف مصرح به، وفهم مخرجات القفزة وRTT، واستكشاف الأخطاء وإصلاحها في الاستجابات المفقودة دون الإفراط في المسح.
