เมื่อamavisdกระบวนการใดกระบวนการหนึ่งใช้ CPU สูงถึง 100% หรือใกล้เคียง 100% เป้าหมายไม่ใช่แค่การทำให้กระบวนการนั้นหายไป การแก้ไขที่มีประสิทธิภาพควรจะช่วยคืนค่าการไหลของอีเมลให้เป็นปกติ ลดความล่าช้าในการประมวลผล รักษาการทำงานของระบบป้องกันสแปมและไวรัส และป้องกันไม่ให้คิวของ Postfix เพิ่มขึ้นเรื่อยๆ
ใน Zimbra นั้น Amavisd-New อยู่ระหว่าง MTA และตัวสแกนเนื้อหา คู่มือการดูแลระบบ Daffodil ฉบับปัจจุบันของ Zimbra อธิบายว่า Amavisd-New เป็นตัวเชื่อมระหว่าง Zimbra MTA, ClamAV และ SpamAssassin นั่นหมายความว่าการใช้งาน CPU ที่สูงขึ้นอาจมาจาก Amavis เอง จากกฎของ SpamAssassin หรือเนื้อหาข้อความ จากการสแกนไวรัส หรือจากงานที่ค้างอยู่ซึ่งทำให้ตัวประมวลผลทุกตัวทำงานอยู่ตลอดเวลา โปรดดูคู่มือผู้ดูแลระบบ Zimbra Daffodil
ผลลัพธ์ที่ประสบความสำเร็จมีสัญญาณสี่ประการ ได้แก่: การใช้งาน CPU ของ Amavis ลดลงสู่ระดับที่ควบคุมได้ คิวที่ถูกเลื่อนและคิวที่ใช้งานอยู่หยุดเพิ่มขึ้น ข้อความใหม่ส่งผ่านได้โดยไม่ล่าช้าผิดปกติ และบริการป้องกันสแปม/ป้องกันไวรัสยังคงทำงานได้ดี หากการใช้งาน CPU ลดลงเพียงเพราะปิดใช้งานการกรอง แสดงว่าปัญหาพื้นฐานยังไม่ได้รับการแก้ไข
เริ่มต้นที่ระดับระบบปฏิบัติการ อย่าเพิ่งคิดว่า Amavis เป็นสาเหตุเพียงเพราะการส่งอีเมลช้า ตรวจสอบกระบวนการที่ใช้ทรัพยากรมากที่สุดและยืนยันว่ามีamavisdกระบวนการใดกระบวนการหนึ่งหรือมากกว่านั้นที่ใช้ CPU เต็มคอร์อย่างต่อเนื่อง หรือไม่
top -c
ps -eo pid,user,pcpu,pmem,etime,cmd --sort=-pcpu | head -20
คำบรรยายภาพ: ภาพหน้าจอเทอร์มินัลที่แสดงว่า amavisd เป็นโปรแกรมที่ใช้ CPU มากที่สุด ซึ่งเป็นเงื่อนไขแรกที่ต้องตรวจสอบก่อนเปลี่ยนแปลงการตั้งค่า Zimbra
การใช้งาน CPU ที่เพิ่มขึ้นอย่างรวดเร็วในช่วงสั้นๆ อาจเป็นเรื่องปกติในขณะที่กำลังสแกนข้อความขนาดใหญ่หรือไฟล์แนบที่ถูกบีบอัด ให้ถือว่าปัญหานี้เกิดขึ้นอย่างต่อเนื่องหากอาการเดียวกันยังคงเกิดขึ้นพร้อมกับความล่าช้าในการรับส่งอีเมลหรือปริมาณคิวที่เพิ่มขึ้น นอกจากนี้ ให้ตรวจสอบค่าเฉลี่ยโหลด หน่วยความจำว่าง การทำงานของสวอป และการรอ I/O ด้วย การใช้งาน CPU สูงร่วมกับการแย่งใช้สวอปหรือพื้นที่จัดเก็บข้อมูลจำนวนมาก อาจต้องตรวจสอบในระดับโฮสต์โดยรวมมากกว่าการเปลี่ยนแปลงเฉพาะใน Amavis เท่านั้น
สลับไปใช้บัญชี Zimbra และตรวจสอบสถานะบริการ เอกสารของ Zimbra ใช้zmcontrol statusการตรวจสอบนี้เป็นมาตรฐานสำหรับบริการที่เปิดใช้งานอยู่
su - zimbra
zmcontrol status
zmamavisdctl status
คำบรรยายภาพ: สถานะการให้บริการของ Zimbra แสดงให้เห็นว่า Amavis, ระบบป้องกันสแปม, ระบบป้องกันไวรัส และส่วนประกอบ MTA กำลังทำงานอยู่ ก่อนที่จะเริ่มการแก้ไขปัญหา
ขั้นตอนนี้สำคัญเพราะ “CPU 100%” และ “บริการล่ม” เป็นโหมดความล้มเหลวที่แตกต่างกัน หาก Amavis ไม่ทำงาน ให้ตรวจสอบข้อผิดพลาดในการเริ่มต้นระบบแทน หาก Amavis ทำงานอยู่แต่มีการใช้งาน CPU มากเกินไป ให้ดำเนินการวิเคราะห์คิวและบันทึกต่อไป
ความลึกของคิวจะบอกคุณว่าการใช้งาน CPU สูงส่งผลกระทบต่อการส่งข้อความหรือไม่ เอกสารการแก้ไขปัญหาคิวของ Zimbra zmqstatจะแสดงจำนวนคิว และคำสั่งคิวของ Postfix จะแสดงรายละเอียดข้อความ ตรวจสอบซ้ำๆ โดยเว้นระยะห่างกันสองสามนาที
sudo /opt/zimbra/libexec/zmqstat
postqueue -p
คำบรรยายภาพ: สถิติคิวและข้อความที่ถูกเลื่อนออกไปนั้นให้ข้อมูลที่เป็นประโยชน์ในการประเมินผลกระทบของการไหลเวียนของอีเมลมากกว่าการดูเปอร์เซ็นต์การใช้งาน CPU เพียงอย่างเดียว
จงมองหาทิศทาง ไม่ใช่แค่ตัวเลขโดดๆ ตัวเดียว คิวที่เพิ่มขึ้นทุกครั้งที่มีการสุ่มตัวอย่างหมายความว่าปริมาณงานต่ำกว่าอัตราการมาถึง คิวที่ลดลงอย่างต่อเนื่องหลังจากมีการเปลี่ยนแปลงเป็นหนึ่งในสัญญาณที่ชัดเจนที่สุดว่าการเปลี่ยนแปลงนั้นได้ผลจริง
หากคุณใช้งานระบบ MTA หลายตัว โปรดตรวจสอบโหนด MTA ที่ได้รับผลกระทบโดยเฉพาะ อย่าสันนิษฐานว่าคิวบนโหนดอื่นแสดงถึงปัญหาคอขวดเดียวกัน
ข้อความแก้ไขปัญหาของ Amavis และ SpamAssassin จะถูกเขียนไปยัง/var/log/zimbra.log. ค้นหาในช่วงเวลาที่มีการใช้งาน CPU สูงผิดปกติ และเชื่อมโยงรหัสข้อความ รหัสกระบวนการ และระยะเวลาการสแกนเข้าด้วยกัน
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 ในขณะที่ SpamAssassin zimbraAmavisSALogLevelใช้ค่า 0 หรือ 1 ควรเริ่มต้นด้วยระดับ 2 ของ Amavis แทนที่จะใช้ระดับการบันทึกข้อมูลสูงสุด เว้นแต่คุณต้องการการดีบักที่ละเอียดกว่านั้น
su - zimbra
zmprov mcf zimbraAmavisLogLevel 2
zmprov mcf zimbraAmavisSALogLevel 1
คำบรรยายภาพ: การเปลี่ยนแปลงการบันทึกข้อมูลชั่วคราวทำให้สามารถเชื่อมโยงเวลาการสแกนและพฤติกรรมของ SpamAssassin กับการใช้งาน CPU ที่พุ่งสูงขึ้นได้ง่ายขึ้น
จำลองหรือสังเกตปัญหาเพียงระยะเวลาสั้นๆ เพื่อเก็บข้อมูลที่เป็นประโยชน์เท่านั้น การบันทึกข้อมูลในระดับที่สูงขึ้นจะเพิ่มการเขียนลงดิสก์และอาจทำให้เซิร์ฟเวอร์ที่มีการใช้งานมากส่งเสียงดังขึ้น หลังจากตรวจสอบเสร็จแล้ว ให้กลับไปใช้ค่าเดิม 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นี่เป็นการแก้ไขปัญหา CPU แบบครอบคลุม หากการใช้งาน CPU พุ่งสูงขึ้นทันทีหลังจากเพิ่มกฎที่กำหนดเอง ให้ทดสอบกฎนั้นก่อน Zimbra จัดเก็บกฎ SpamAssassin ที่กำหนดเองสมัยใหม่ไว้ใน/opt/zimbra/data/spamassassin/localrules/. ลบหรือปิดใช้งานเฉพาะการปรับแต่งที่สงสัยในระหว่างช่วงเวลาการบำรุงรักษาที่ควบคุมได้ จากนั้นเปรียบเทียบเวลาการสแกนและพฤติกรรมของคิว
เว็บไซต์วิกิอย่างเป็นทางการของ Zimbra ยังระบุถึงการตั้งค่าการอัปเดตและการคอมไพล์กฎอัตโนมัติสำหรับ ZCS เวอร์ชันใหม่กว่าด้วย โปรดตรวจสอบกลยุทธ์การป้องกันสแปมของ Zimbraก่อนเปิดใช้งานพฤติกรรมอัตโนมัติบนเซิร์ฟเวอร์ที่ใช้งานอยู่
การรีสตาร์ทสามารถล้างเวิร์กเกอร์ที่ค้างอยู่และโหลดกฎที่อัปเดตแล้วได้ แต่ควรทำหลังจากวินิจฉัยปัญหาแล้ว ไม่ใช่ทำแทนที่ระบบ ควรรีสตาร์ทเฉพาะ Amavis ก่อน เว้นแต่จะมีหลักฐานชี้ไปที่ระบบ MTA ที่กว้างกว่านั้น
su - zimbra
zmamavisdctl restart
คำบรรยายภาพ: การรีสตาร์ท Amavis จะโหลดบริการใหม่หลังจากมีการเปลี่ยนแปลงกฎหรือการกำหนดค่าที่ต้องการ โดยไม่ต้องรีสตาร์ทบริการ Zimbra ทั้งหมดโดยไม่จำเป็น
หาก CPU กลับมาทำงานที่ 100% ทันที นั่นเป็นหลักฐานที่มีประโยชน์: สาเหตุยังคงอยู่ กลับไปตรวจสอบบันทึกและระบุว่าข้อความ สแกนเนอร์ หรือกฎเดียวกันปรากฏขึ้นอีกหรือไม่ การรีสตาร์ทบริการซ้ำๆ อาจช่วยลดอาการลงได้ชั่วคราว แต่จะทำให้คิวเพิ่มขึ้น
อย่าสรุปว่าปัญหาได้รับการแก้ไขแล้วหลังจากเห็นตัวเลขการใช้งาน CPU ลดลงเพียงครั้งเดียว ตรวจสอบภาระงานของกระบวนการ ทิศทางของคิว และสถานะของบริการไปพร้อมกัน
top -c
sudo /opt/zimbra/libexec/zmqstat
zmcontrol status
คำบรรยายภาพ: การกู้คืนระบบจะมีประสิทธิภาพมากขึ้นเมื่อการใช้งาน CPU ความลึกของคิว และสถานะบริการของ Zimbra ดีขึ้นพร้อมกัน
จากนั้นส่งข้อความทดสอบผ่าน MTA ที่ได้รับผลกระทบ และยืนยันว่าข้อความนั้นถูกส่งถึงภายในช่วงเวลาแฝงปกติของคุณ สำหรับข้อความที่ควรผ่านการกรอง ให้ตรวจสอบส่วนหัวของข้อความเพื่อหาฟิลด์การสแกนสแปมและไวรัสของ Zimbra/Amavis ที่คาดไว้ Zimbra จะระบุส่วนหัวต่างๆ เช่นX-Virus-ScannedและX-Spam-Statusเมื่อใดที่การตรวจสอบเหล่านั้นทำงานอยู่
| สิ่งที่คุณสังเกตเห็น | การดำเนินการที่ดีที่สุดถัดไป | ทำไม |
|---|---|---|
| ข้อความหนึ่งข้อความทำให้เกิดการสแกนที่ใช้เวลานานซ้ำๆ | กักกันหรือตรวจสอบข้อความนั้นอย่างปลอดภัย และเชื่อมโยงรหัสคิวของข้อความนั้นกับบันทึกต่างๆ | ปัญหาคอขวดอาจเกิดจากเนื้อหาโดยเฉพาะ มากกว่าจากความจุที่มีอยู่ |
| จังหวะเวลาในการโจมตีของ SpamAssassin เป็นสิ่งสำคัญ | ตรวจสอบกฎที่กำหนดเอง การอัปเดตกฎ และผลลัพธ์การแก้ไขข้อผิดพลาด | ชุดกฎที่มี Regex มากหรือเสียหายอาจทำให้การคิดคะแนนมีค่าใช้จ่ายสูง |
| ข้อผิดพลาดหรือการหมดเวลาของ ClamAV เป็นปัญหาหลัก | ตรวจสอบสถานะการทำงานของโปรแกรมป้องกันไวรัสและอัปเดตสถานะ | Amavis อาจกำลังรอเครื่องสแกนที่มันเรียกใช้อยู่ |
| การใช้งาน CPU สูง แต่คิวงานยังคงใกล้ศูนย์ | สังเกตการณ์ให้นานขึ้นก่อนที่จะทำการเปลี่ยนแปลงครั้งใหญ่ | การใช้งานในระดับสูงอาจเป็นที่ยอมรับได้หากปริมาณงานและเวลาแฝงยังคงอยู่ในระดับที่เหมาะสม |
| คิวยังคงเพิ่มขึ้นแม้ว่าจะมีการแก้ไขปัญหาเฉพาะจุดแล้วก็ตาม | ยกระดับการวิเคราะห์ไปสู่ระดับความจุ รูปแบบข้อความ หรือการสนับสนุน | เซิร์ฟเวอร์อาจมีขนาดเล็กเกินไป กำลังถูกโจมตี หรือกำลังพบข้อบกพร่องเฉพาะด้านซอฟต์แวร์ |
อย่าปิดใช้งานการสแกนป้องกันสแปมหรือไวรัสอย่างถาวรเพียงเพื่อลดการใช้งาน CPU Zimbra รองรับนโยบายการบายพาสสำหรับทราฟฟิกที่เชื่อถือได้/ต้นทางเฉพาะ แต่การทำเช่นนั้นจะเปลี่ยนรูปแบบความปลอดภัยและควรเป็นการตัดสินใจด้านนโยบายอีเมลอย่างรอบคอบ ไม่ใช่การปรับแต่งประสิทธิภาพทั่วไป เอกสารของ Zimbra เกี่ยวกับการบายพาส SpamAssassin ต้นทางระบุไว้อย่างชัดเจนว่าการบายพาสนั้นเชื่อมโยงกับเครือข่ายภายในที่เชื่อถือได้
นอกจากนี้ ควรหลีกเลี่ยงการเพิ่มจำนวนเวิร์กเกอร์ของ Amavis โดยไม่พิจารณาให้รอบคอบ เวิร์กเกอร์ที่มากขึ้นอาจเพิ่มการทำงานพร้อมกันได้ แต่ก็เพิ่มภาระด้านหน่วยความจำและอาจทำให้การแย่งใช้ CPU แย่ลง ค่าที่เหมาะสมขึ้นอยู่กับส่วนผสมของข้อความ ขนาดไฟล์แนบ พฤติกรรมของสแกนเนอร์ คอร์ที่มีอยู่ หน่วยความจำ และ I/O ควรทดสอบการเปลี่ยนแปลงโดยพิจารณาจากปริมาณงานของคิวและเวลาแฝง แทนที่จะสันนิษฐานว่ากลุ่มเวิร์กเกอร์ที่ใหญ่กว่าจะเร็วกว่าเสมอไป
ขั้นตอนนี้นั้นออกแบบมาสำหรับกรณีทั่วไปที่ Amavis ทำงานอยู่แต่มีการใช้งาน CPU อย่างหนักหน่วงอย่างต่อเนื่อง ขั้นตอนนี้นั้นไม่สามารถใช้แทนคำแนะนำจากฝ่ายสนับสนุนของ Zimbra ที่เฉพาะเจาะจงกับเวอร์ชันสำหรับข้อบกพร่องของผลิตภัณฑ์ที่ได้รับการยืนยันแล้ว เซิร์ฟเวอร์ที่ถูกบุกรุก การโจมตีแบบปฏิเสธการให้บริการด้วยข้อความผิดรูปแบบ หรือสถาปัตยกรรมแบบหลายโหนดที่มีสแกนเนอร์ภายนอกได้
เอกสารทางเทคนิคของชุมชน Zimbra ได้บันทึกกรณีในอดีตที่ข้อความที่สร้างขึ้นเป็นพิเศษหรือพฤติกรรมของ SpamAssassin อาจทำให้เครื่อง Amavis ทำงานหนักจน CPU ค้างเป็นเวลานาน เนื่องจากความเสี่ยงที่เกิดขึ้นนั้นขึ้นอยู่กับเวอร์ชันของ Zimbra และ SpamAssassin ที่ติดตั้งไว้ จึงไม่ควรนำวิธีการอัปเกรดแพ็กเกจเก่ามาใช้โดยไม่ตรวจสอบ ควรตรวจสอบเวอร์ชันของ Zimbra ก่อนzmcontrol -vเปรียบเทียบกับเวอร์ชันและระดับแพทช์ที่รองรับ และใช้คำแนะนำของผู้จำหน่ายในปัจจุบันสำหรับการอัปเกรด
เปรียบเทียบเครื่องมือสแกน Ping 10 ตัว สำหรับการค้นหาเครือข่าย LAN อย่างรวดเร็ว การสแกนข้ามแพลตฟอร์ม และการจัดการที่อยู่ IP เรียนรู้ว่าการสแกน Ping สามารถบอกอะไรคุณได้บ้าง และบอกอะไรไม่ได้บ้าง
เปรียบเทียบเครื่องมือบริหารจัดการเครือข่าย 6 ชนิดสำหรับการตรวจสอบประสิทธิภาพ รวมถึงการครอบคลุมของ SNMP, การทำแผนที่, การแจ้งเตือน, รูปแบบการใช้งาน และข้อดีข้อเสียด้านต้นทุน
เปรียบเทียบแอปวิเคราะห์ Wi-Fi สำหรับ Windows, iPhone และ Android ซึ่งรวมถึงเครื่องมือสำหรับตรวจสอบความแออัดของช่องสัญญาณ การครอบคลุมสัญญาณ แผนที่ความร้อน และการแก้ไขปัญหาเครือข่าย
เปรียบเทียบโปรแกรมตรวจสอบค่า Ping แบบโอเพนซอร์สฟรี 7 ตัว ตั้งแต่ชุดโปรแกรมเครือข่ายแบบครบวงจรไปจนถึงโปรแกรมตรวจสอบความหน่วงแฝงโดยเฉพาะ และเลือกโปรแกรมที่เหมาะสมที่สุดตามความพร้อมใช้งาน การสูญเสียแพ็กเก็ต และประวัติการใช้งาน
เรียนรู้ความหมายของ QoS ในระบบเครือข่าย วิธีที่การกำหนดค่า DSCP และคิวการรับส่งข้อมูลจัดลำดับความสำคัญของเสียง วิดีโอ และแอปพลิเคชันทางธุรกิจ และสิ่งที่ QoS แก้ไขไม่ได้
เปรียบเทียบเครื่องมือจัดการที่อยู่ IP เจ็ดแบบ สำหรับการค้นหาซับเน็ต การประสานงาน DNS และ DHCP การสำรวจเครือข่าย และ IPAM แบบโอเพนซอร์ส
สร้างระบบตรวจสอบเครือข่ายที่ใช้งานได้จริง พร้อมการครอบคลุมอุปกรณ์ที่ชัดเจน ตัวชี้วัดประสิทธิภาพที่เป็นประโยชน์ การแจ้งเตือนที่นำไปปฏิบัติได้จริง และการเปรียบเทียบระหว่าง SolarWinds NPM, PRTG และ OpManager
เปรียบเทียบเครื่องมือสแกนเครือข่ายสำหรับการค้นหาอุปกรณ์อย่างรวดเร็ว การสแกน IP ข้ามแพลตฟอร์ม และระบบจัดการ IP ระดับองค์กร พร้อมคำแนะนำในการเลือกใช้แต่ละตัวเลือกให้เหมาะสมกับเครือข่ายของคุณ
ใช้ตัวเลือก --traceroute ของ Nmap เพื่อแมปฮอปไปยังโฮสต์ที่ได้รับอนุญาต ทำความเข้าใจเอาต์พุตของฮอปและ RTT และแก้ไขปัญหาการตอบสนองที่หายไปโดยไม่ต้องสแกนมากเกินไป
เปรียบเทียบเครื่องมือสแกนและวิเคราะห์เครือข่ายไร้สาย 10 รายการสำหรับ Windows, iOS และ Android พร้อมคำอธิบายที่ชัดเจนเกี่ยวกับช่องสัญญาณ Wi-Fi แผนที่ครอบคลุม การตรวจสอบ LAN และข้อจำกัดของแต่ละแพลตฟอร์ม
