บริการ AWS ELB Apache2 503 ไม่พร้อมใช้งาน: เซิร์ฟเวอร์แบ็คเอนด์มีความจุ


39

เราใช้งานเว็บไซต์สองแห่งจากโครงสร้างพื้นฐาน Amazons AWS เป็นเวลาประมาณสองปีแล้วและเมื่อประมาณสองวันที่ผ่านมาเว็บเซิร์ฟเวอร์เริ่มลงหนึ่งครั้งหรือสองครั้งต่อวันโดยมีข้อผิดพลาดเพียงอย่างเดียวที่ฉันสามารถทำได้:

HTTP/1.1 503 Service Unavailable: Back-end server is at capacity

ไม่มีสัญญาณเตือน (CPU / ดิสก์ IO / DB Conn) ถูกเรียกโดย CloudWatch ฉันพยายามไปที่ไซต์ผ่านทาง IP ที่ยืดหยุ่นเพื่อข้าม ELB และรับสิ่งนี้:

HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers. Retrying.

ฉันไม่เห็นอะไรผิดปกติในบันทึก apache และตรวจสอบว่ามีการหมุนอย่างถูกต้อง ฉันไม่มีปัญหาในการเข้าถึงเครื่องเมื่อ "ลง" ผ่าน SSH และดูรายการกระบวนการที่ฉันเห็นกระบวนการ 151 apache2 ที่ปรากฏตามปกติสำหรับฉัน การรีสตาร์ท apache เป็นการแก้ไขปัญหาชั่วคราว เครื่องนี้ทำงานเป็นเพียงเว็บเซิร์ฟเวอร์ด้านหลัง ELB ข้อเสนอแนะใด ๆ ที่จะได้รับการชื่นชมอย่างมาก.

การใช้งาน CPU โดยเฉลี่ย: 7.45%, ต่ำสุด: 0.00%, สูงสุด: 25.82%

การใช้งานหน่วยความจำเฉลี่ย: 11.04%, ต่ำสุด: 8.76%, สูงสุด: 13.84%

ค่าเฉลี่ยการใช้งานสว็อป: N / A, ขั้นต่ำ: N / A, สูงสุด: N / A

การใช้ประโยชน์พื้นที่ดิสก์สำหรับ / dev / xvda1 ที่ติดตั้งบน / เฉลี่ย: 62.18%, ขั้นต่ำ: 53.39%, สูงสุด: 65.49%

ฉันขอชี้แจงว่าฉันคิดว่าปัญหาเกิดขึ้นกับ EC2 แต่ละตัวไม่ใช่ ELB ที่ฉันไม่ต้องการออกกฎแม้ว่าฉันจะไม่สามารถเข้าถึง IP ที่ยืดหยุ่นได้ ฉันสงสัยว่า ELB เพิ่งส่งคืนผลลัพธ์ของการกด EC2 อินสแตนซ์ที่เกิดขึ้นจริง

อัปเดต: 2014-08-26 ฉันควรจะอัปเดตสิ่งนี้เร็วกว่านี้ แต่การ "แก้ไข" เพื่อถ่ายภาพอินสแตนซ์ "ไม่ดี" และเริ่ม AMI ที่เป็นผลลัพธ์ มันไม่ได้ลงไปตั้งแต่นั้นมา ฉันดูที่การตรวจสอบสุขภาพเมื่อฉันยังคงประสบปัญหาและสามารถไปที่หน้าตรวจสุขภาพ ( curl http://localhost/page.html) แม้ว่าฉันจะได้รับปัญหาด้านความจุจาก load balancer ฉันไม่เชื่อว่าเป็นปัญหาการตรวจสุขภาพ แต่เนื่องจากไม่มีใครรวมถึง Amazon สามารถให้คำตอบที่ดีกว่าฉันทำเครื่องหมายว่าเป็นคำตอบ ขอขอบคุณ.

ปรับปรุง: 2015-05-06 ฉันคิดว่าฉันจะกลับมาที่นี่และบอกว่าส่วนหนึ่งของปัญหาที่ฉันเชื่อมั่นในตอนนี้คือการตั้งค่าการตรวจสุขภาพ ฉันไม่ต้องการที่จะแยกแยะปัญหาของพวกเขากับ AMI เพราะมันดีกว่าแน่นอนหลังจากการเปิดตัว AMI ใหม่ แต่ฉันพบว่าการตรวจสุขภาพของเรานั้นแตกต่างกันสำหรับเครื่องโหลดบาลานซ์แต่ละเครื่องและเครื่องที่มีปัญหามากที่สุด มีขีด จำกัด ที่ไม่แข็งแรงเชิงรุกและหมดเวลาตอบสนอง ปริมาณการใช้ข้อมูลของเรามีแนวโน้มที่จะเพิ่มขึ้นอย่างคาดไม่ถึงและฉันคิดว่าระหว่างการตั้งค่าการตรวจสุขภาพที่ก้าวร้าวและการเพิ่มขึ้นของการจราจรเป็นพายุที่สมบูรณ์แบบ


ฉันพบข้อมูลเพิ่มเติมเกี่ยวกับที่: meta.discourse.org/t/…
Andre Mesquita

คำตอบ:


41

คุณจะได้รับ "เซิร์ฟเวอร์แบ็คเอนด์มีความจุ" เมื่อเครื่องชั่งโหลด ELB ทำการตรวจสอบสุขภาพและได้รับ "ไม่พบหน้า" (หรือข้อผิดพลาดทั่วไปอื่น ๆ ) เนื่องจากการกำหนดค่าผิดพลาด

ลอง grepping โฟลเดอร์แฟ้มบันทึกโดยใช้ตัวแทนผู้ใช้ "ELB-HealthChecker" เช่น

grep ELB-HealthChecker  /var/log/httpd/*

โดยทั่วไปจะทำให้เกิดข้อผิดพลาด 4x หรือ 5x ซึ่งแก้ไขได้ง่าย เช่น Flooding, MaxClients เป็นต้นทำให้ปัญหาเครดิตมากเกินไป

FYI Amazon: ทำไมไม่แสดงการตอบกลับจากคำขอ แม้แต่รหัสสถานะก็ช่วยได้


17

ฉันเพิ่งพบปัญหานี้ด้วยตัวเอง Amazon ELB จะส่งคืนข้อผิดพลาดนี้หากไม่มีอินสแตนซ์ที่ดีต่อสุขภาพ ไซต์ของเราได้รับการกำหนดค่าผิดพลาดดังนั้น ELB Healthcheck จึงล้มเหลวซึ่งทำให้ ELB ดึงเซิร์ฟเวอร์ทั้งสองออกจากการหมุน เมื่อไม่มีไซต์ที่มีประโยชน์ศูนย์ ELB จึงคืนค่าบริการ 503 ไม่พร้อมใช้งาน: เซิร์ฟเวอร์แบ็คเอนด์มีความจุ


5

[แก้ไขหลังจากเข้าใจคำถามได้ดีกว่า] ไม่มีประสบการณ์ใด ๆ ของ ELB ฉันยังคงคิดว่ามันฟังดูน่าสงสัยเหมือนข้อผิดพลาด 503 ซึ่งอาจถูกโยนทิ้งไปเมื่ออาปาเช่เผชิญกับ Tomcat และเชื่อมต่อกับน้ำท่วม

ผลกระทบคือถ้า Apache ให้การร้องขอการเชื่อมต่อมากกว่าที่สามารถประมวลผลได้โดยแบ็กเอนด์แบ็กเอนด์คิวจะเติมจนไม่มีการเชื่อมต่อที่สามารถยอมรับได้ เมื่อสิ่งนั้นเกิดขึ้นเอาต์พุตคิวที่สอดคล้องกันของ Apache จะเริ่มเติมเต็ม เมื่อคิวเต็มไปด้วย Apache โยน 503 มันจะเป็นไปตามนั้นอาจเกิดขึ้นเมื่อ Apache เป็นแบ็กเอนด์และส่วนหน้ามอบในอัตราที่ทำให้คิวเต็ม

วิธีการแก้ปัญหา (สมมุติฐาน) คือการกำหนดขนาดขั้วต่ออินพุตของขั้วต่อแบ็กเอนด์และเอาท์พุทของส่วนหน้า สิ่งนี้จะกลายเป็นการปรับสมดุลระหว่างระดับน้ำท่วมที่คาดไว้และ RAM ที่มีอยู่ของคอมพิวเตอร์ที่เกี่ยวข้อง

เช่นนี้เกิดขึ้นตรวจสอบการตั้งค่าสูงสุดของคุณและตรวจสอบคนงานไม่ว่างของคุณใน Apache (mod_status.) ทำสิ่งเดียวกันถ้าเป็นไปได้กับสิ่งที่ ELB มีซึ่งสอดคล้องกับ Backcats ของตัวเชื่อมต่อ Tomcats, maxthreads เป็นต้นโดยสรุปให้ดูทุกสิ่งที่เกี่ยวข้องกับอินพุตคิวของ Apache และเอาต์พุตคิวของ ELB

แม้ว่าฉันจะเข้าใจว่ามันไม่สามารถใช้งานได้โดยตรง แต่ลิงค์นี้มีคำแนะนำการปรับขนาดสำหรับตัวเชื่อมต่อ Apache คุณจะต้องทำการวิจัยด้านเทคนิคคิว ELB ที่เกี่ยวข้องจากนั้นทำการคำนวณ: http://www.cubrid.org/blog/dev-platform/maxclients-in-apache-and-its-effect-on-tomcat-during- เต็มรูปแบบ GC /

ดังที่สังเกตเห็นในความเห็นด้านล่างการเชื่อมต่อ Apache การขัดขวางการรับส่งข้อมูลนั้นไม่ได้เป็นเพียงความเป็นไปได้เท่านั้น หากคำขอบางรายการทำงานช้ากว่าคำขออื่นอัตราส่วนที่สูงกว่าก็อาจนำไปสู่คิวการเชื่อมต่อที่เติม นี่เป็นเรื่องจริงในกรณีของฉัน

นอกจากนี้เมื่อสิ่งนี้เกิดขึ้นกับฉันฉันรู้สึกงงงวยที่ฉันต้องเริ่มบริการ Apache เพื่อไม่ให้บริการ 503: s อีกครั้ง เพียงแค่รอให้น้ำท่วมขั้วต่อไม่เพียงพอ ฉันไม่เคยรู้เรื่องนี้มาก่อน แต่มีใครสามารถคาดเดาการให้บริการ Apache จากแคชของมันได้หรือ

หลังจากเพิ่มจำนวนของคนงานและการตั้งค่า pre-fork maxclients ที่สอดคล้องกัน (นี่คือ Apache แบบมัลติเธรดบน Windows ซึ่งมีคำสั่งอื่น ๆ อีกสองสามคำสำหรับคิวถ้าฉันจำได้ถูกต้อง) ปัญหา 503 หายไป จริง ๆ แล้วฉันไม่ได้ทำคณิตศาสตร์ แต่เพียงแค่ปรับค่าขึ้นจนกว่าฉันจะสังเกตเห็นขอบกว้างเพื่อการใช้ทรัพยากรคิวสูงสุด ฉันปล่อยให้มันเป็นอย่างนั้น

หวังว่านี่จะช่วยได้บ้าง


ฉันเพิ่งรู้ว่าคุณกำลังเขียน Apache เป็นแบ็กเอนด์ของคุณ แต่ถึงกระนั้นคนงานคนงานและคนอื่น ๆ ก็น่าจะเล่นกันฉันเดาว่าคำตอบของฉันจะปิดเกินไปและต้องการเขียนใหม่ทั้งหมด ฉันอาจลบมันแทน เรียนรู้บทเรียน: อ่านคำถามให้ถูกต้อง
ErikE

ขอขอบคุณ. เพื่อเป็นกรณีนี้จะต้องมีการขัดขวางการจราจรขนาดใหญ่? และเมื่อกล่าวว่าปริมาณการจราจรที่ปล่อยออกมาไม่ควรที่จะสามารถกู้คืนได้
JSP

ในทางทฤษฎีใช่ อย่างไรก็ตามเมื่อสิ่งนี้เกิดขึ้นกับฉันฉันต้องเริ่มบริการใหม่ สิ่งนี้ทำให้ฉันดูครั้งแรกในสถานที่ที่ไม่เกี่ยวข้องกับสิ่งที่เกิดขึ้นจริง แต่แม้หลังจากการวินิจฉัยและการรักษาที่เหมาะสมฉันยังไม่สามารถเข้าใจถึงความจำเป็นในการเริ่มบริการใหม่ได้ ฉันสงสัยอย่างเงียบ ๆ ว่าเป็นเพราะการใช้ Apache บน Windows เนื่องจากฉันพบข้อผิดพลาดอ้างอิงที่ไม่เกี่ยวข้องซึ่งเห็นได้ชัดว่าเกิดขึ้นกับคอมโบนั้นเท่านั้น แปลกมากในทุกกรณี
ErikE

และใช่มีการจราจรล้นหลามตัวเชื่อมต่อ - ไม่แหลม (สำหรับเรา) แต่มากเกินไป มันค่อนข้างคำขอบางอย่างที่ช้ากว่าที่จะรับใช้ซึ่งเพิ่งเกิดขึ้นมากเกินไปในบางโอกาส หลังจากตรวจสอบเพียงเล็กน้อยและเพียงแค่เพิ่มค่าที่เกี่ยวข้อง 503 ก็หายไปพร้อมกับความจำเป็นสำหรับการรีสตาร์ทครั้งต่อไป
ErikE

4

คุณสามารถเพิ่มค่าของตัวตรวจสอบความสมบูรณ์ของ elb ดังนั้นการตอบสนองช้าเดียวจะไม่ดึงเซิร์ฟเวอร์ออกจาก elb ดีกว่าที่จะมีผู้ใช้ไม่กี่รายที่ไม่สามารถใช้บริการได้กว่าไซต์จะปิดสำหรับทุกคน

แก้ไข: เราสามารถออกไปได้โดยไม่ต้องแคชล่วงหน้าก่อนโดยตรวจสุขภาพหมดเวลา 25 วินาที ...... หลังจาก 1-2 นาที ... ไซต์ตอบสนองเหมือนนรก

แก้ไข :: เพิ่งเปิดตัวเครือข่ายตามต้องการและเมื่อเครื่องมือตรวจสอบของคุณแสดงการจัดการคุณรวดเร็วแค่ไหนแล้วแค่ชำระล่วงหน้า RI amazon: P

แก้ไข: เป็นไปได้อินสแตนซ์ที่ลงทะเบียน elb แบ็กเอนด์เดียวไม่เพียงพอ เพิ่งเปิดตัวเพิ่มอีกไม่กี่ตัวแล้วลงทะเบียนด้วย elb และนั่นจะช่วยให้คุณ จำกัด ปัญหาให้แคบลง


0

มันไม่กี่ปีที่ผ่านมา แต่หวังว่าจะช่วยให้ใครบางคนออกมา

ฉันเห็นข้อผิดพลาดนี้เมื่ออินสแตนซ์ที่อยู่เบื้องหลัง ELB ไม่ได้กำหนด IP สาธารณะที่เหมาะสม ฉันต้องสร้าง Elastic IP ด้วยตนเองและเชื่อมโยงกับอินสแตนซ์หลังจากนั้นเวลาใดที่ ELB เลือกมันขึ้นมาเกือบจะในทันที

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.