ฉันกำลังทดสอบว่าทำไมบางครั้งสคริปต์ PHP ของฉันจึงใช้เวลานานในการโหลดผ่านเครือข่าย (>30 วินาที) บนเซิร์ฟเวอร์ Apache 2.4 Ubuntu ของฉันด้วย PHP-FPM 7.4 โดยใช้ mpm_event เซิร์ฟเวอร์ทำงานได้ตามปกติในช่วงสองสามเดือนที่ผ่านมา สิ่งนี้เริ่มเกิดขึ้นเมื่อสองสามวันก่อน และฉันไม่ได้เปลี่ยนแปลงอะไรเลย ฉันรีบูทแล้ว มันไม่ช่วยอะไร

test.phpผมได้ทำง่ายๆ บางครั้งโหลดได้ตามปกติ (<100ms) แต่บางครั้งใช้เวลาโหลด 1 นาที:

<?php echo "test\n"; ?>

ใส่คำอธิบายภาพที่นี่

  • CPU, RAM และ IO ของเซิร์ฟเวอร์เป็นปกติ (ตรวจสอบด้วยhtop)
  • ไฟล์ HTML แบบคงที่จะถูกโหลดโดยไม่ชักช้า
  • การเรียกใช้สคริปต์ในเครื่องผ่านคอนโซล SSH นั้นเร็วมาก
  • บันทึกข้อผิดพลาด Apache ไม่แสดงสิ่งผิดปกติ
  • ฉันตรวจสอบว่ามีการโจมตี DDOS หรือไม่โดยตรวจสอบจำนวน IP ที่เชื่อมต่อจากซับเน็ต /16 เดียวกัน และไม่พบสิ่งแปลกปลอม (เช่น >100 การเชื่อมต่อ)

ฉันจะดีบักสิ่งนี้เพิ่มเติมเพื่อดูว่าเหตุใดจึงเกิดขึ้น


เอาต์พุตการดีบักบางอย่างที่อาจช่วยได้:

sudo service php7.4-fpm status

ใส่คำอธิบายภาพที่นี่

answer

อาจมีสาเหตุหลายประการสำหรับพฤติกรรมนี้:

  1. หากเว็บเซิร์ฟเวอร์นี้ประมวลผลคำขอจากเครือข่ายภายนอก เมื่อปริมาณการรับส่งข้อมูลเพิ่มขึ้น โหลดอาจเพิ่มขึ้น ซึ่งทำให้เวลาตอบสนองของเซิร์ฟเวอร์เพิ่มขึ้น
  2. หากสคริปต์ของคุณใช้การเรียกทรัพยากรภายนอก ในกรณีนี้ เวลาตอบสนองของเซิร์ฟเวอร์ของคุณอาจเพิ่มขึ้นเนื่องจากความเร็วในการตอบสนองต่ำของทรัพยากรภายนอก

ข้อความบันทึก:

[30-Sep-2021 03:36:46] WARNING: [pool www] server reached pm.max_children setting (5), consider raising it

เป็นเพียงข้อพิสูจน์ถึงภาระที่เพิ่มขึ้น

ในทั้งสองกรณี คุณควรระบุสาเหตุของการโหลดโดยการวิเคราะห์จำนวนคำขอไปยังสคริปต์ และหากมีการเรียกไปยังทรัพยากรภายนอก ตรวจสอบให้แน่ใจว่าคำขอทำงานอย่างถูกต้อง

ฉันคิดว่าฉันพบวิธีแก้ปัญหาแล้ว แต่หากคุณมีข้อเสนอแนะใด ๆ โปรดแจ้งให้เราทราบหรือโพสต์คำตอบอื่น

ฉันตรวจสอบ/var/log/php7.4-fpm.logและเห็นรายการมากมายเช่นนี้:

[30-Sep-2021 03:36:46] WARNING: [pool www] server reached pm.max_children setting (5), consider raising it

ใส่คำอธิบายภาพที่นี่

ดังนั้นฉันจึงเพิ่มเป็นmax_children15 และดูเหมือนว่าจะช่วยได้

ดังที่คุณเห็นในเอาต์พุตสถานะของ ใส่คำอธิบายภาพที่นี่ คุณ คุณมีงานที่รอการเริ่มต้น (5 งาน, 0 ไม่ได้ใช้งาน, 6 งาน) ตามที่คุณโพสต์ในคำตอบของคุณเอง (และฉันดีใจที่มันได้ผล) การเพิ่มจำนวนเด็กที่ได้รับอนุญาตอาจเป็นทางออกที่ดี - แต่มีหลายอย่างที่นำไปสู่การเพิ่มประสิทธิภาพ php-fpm และแน่นอนว่าควรให้ความคิดกับทุกคนมากกว่านี้ ระบบก่อนทำการเปลี่ยนแปลงการกำหนดค่าเหล่านี้

คู่มือที่เป็นของแข็งที่นี่

แต่ไม่ว่าคุณจะควรรู้อะไรเมื่อใช้ค่าคงที่:
if (ประมวลผลการใช้หน่วยความจำ * max_children > RAM)
{ [crash apache] }

ถ้า (ข้อกำหนดในการประมวลผล * start_servers > CPU)
{ [crash apache] }

และรู้จักฮาร์ดแวร์ของคุณเสมอก่อนที่จะปรับแต่งการตั้งค่าเหล่านี้ โดยเฉพาะอย่างยิ่งในไดนามิก/ตามความต้องการ (imo ง่ายต่อการทำผิดพลาด)

หากคุณกำลังทำสิ่งนี้สำหรับเว็บเซิร์ฟเวอร์ธุรกิจที่มีความสำคัญต่อภารกิจประเภทใดก็ตาม ฉันจะตั้งเป้าหมายที่จะปัดเศษขึ้น จากนั้นจึงเพิ่มการประมาณการทั้งหมดเป็นสองเท่า นั่นคือกระบวนการที่ใหญ่ที่สุดที่สามารถเรียกได้ใช้ 178mb ดังนั้น 200mb และ VM ปัจจุบันของคุณบน [ใส่ผู้ให้บริการโฮสต์ / ตนเอง] มี RAM เพียง 1gb เท่านั้น - ฉันจะตั้งค่า max_children เป็น2 - จากนั้นเมื่อคุณอัพเกรด VM ของคุณ (อะไรคือ คุณทำอะไรกับ 1gb ในปี 2021 ??) และคุณมี RAM 8gb บนเซิร์ฟเวอร์ของคุณ คุณสามารถใช้ max_children = 18ข้อสังเกตในทั้งสองตัวอย่างการปัดเศษเป็นการสนับสนุนทรัพยากรเพิ่มเติม และหลังจากเพิ่มเป็นสองเท่าสำหรับจุดประสงค์ของ fpm ทิ้งไว้เบื้องหลัง หน่วยความจำสำหรับระบบปฏิบัติการ และกระบวนการพื้นหลังอื่นๆ ที่จะใช้

การปรับการตั้งค่าเหล่านี้มีประโยชน์อย่างมาก และใครก็ตามที่ใช้ apache ควรทราบวิธี - โปรดตรวจสอบให้แน่ใจว่าฮาร์ดแวร์ของคุณสามารถจัดการกับการกำหนดค่าซอฟต์แวร์ที่คุณตั้งค่าได้

เราเกือบจะมีปัญหาเดียวกันนี้ในปีที่แล้ว

การเพิ่มจำนวนลูกสูงสุดจะชดเชยปัญหาในภายหลังเท่านั้น

กลายเป็นฐานข้อมูล MySQL ที่ช้าซึ่งโฮสต์บนเซิร์ฟเวอร์เฉพาะบนเครือข่ายของเราสำหรับบล็อก

PHP ของเราได้รับการกำหนดค่าให้ลองเชื่อมต่อเป็นเวลา 30 วินาที และเมื่อใดก็ตามที่ฐานข้อมูลนี้ตัดสินใจที่จะดำเนินการ มันก็จะเคี้ยวลูก PHP 100 ตัว

เราลดเหลือ 1 วินาทีและปัญหาก็หมดไป ฉันจำไม่ได้ว่าปัญหาฐานข้อมูลเกี่ยวข้องกับเครือข่ายหรือถ้าเราต้องปรับฐานข้อมูลให้เหมาะสม

คุณควรตรวจสอบบันทึกการเข้าถึง Apache สำหรับกรอบเวลา 2:30-3:30 น. และดูว่าเป็นหน้าที่เชื่อมต่อกับฐานข้อมูลหรือไม่ ตรวจสอบบันทึกข้อผิดพลาด 500 ข้อที่นำไปสู่การล่มสลายของเซิร์ฟเวอร์