ตันของการเชื่อมต่อ TCP ในสถานะ TIME_WAIT บน windows 2008 - ทำงานบน amazon AWS

ระบบปฏิบัติการ: Windows Server 2008, SP2 (ทำงานบน EC2 Amazon)

เรียกใช้แอปพลิเคชันเว็บโดยใช้เซิร์ฟเวอร์ Apache httpd & tomcat 6.02 และเว็บเซิร์ฟเวอร์มีการตั้งค่าแบบต่อเนื่อง

มีประมาณ 69,250 (http พอร์ต 80) + 15000 (นอกเหนือจากพอร์ต 80) การเชื่อมต่อ TCP ในสถานะ TIME_WAIT (ใช้ netstat & tcpview) การเชื่อมต่อเหล่านี้ดูเหมือนจะไม่ปิดแม้หลังจากหยุดเว็บเซิร์ฟเวอร์ (รอ 24 ชั่วโมง)

เคาน์เตอร์ตรวจสอบประสิทธิภาพ:

• การเชื่อมต่อที่ใช้งาน TCPv4: 145K
• TCPv4 การเชื่อมต่อแบบพาสซีฟ: 475K
• การเชื่อมต่อ TCPv4 ล้มเหลว: 16K
• รีเซ็ตการเชื่อมต่อ TCPv4: 23K

HKEY_LOCAL_MACHINE\System \CurrentControlSet\Services\Tcpip\Parameters ไม่มีคีย์ TcpTimedWaitDelay ดังนั้นค่าควรเป็นค่าเริ่มต้น (2 * MSL, 4 นาที)

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

หลังจากผ่านไปสองสามวันเราจะหยุดการเชื่อมต่อใหม่ ๆ

เราได้จัดการกับปัญหานี้เช่นกัน ดูเหมือนว่า Amazon จะพบต้นเหตุและแก้ไขให้ถูกต้อง นี่คือข้อมูลที่พวกเขาให้ฉัน

สวัสดีฉันกำลังวางคำอธิบายด้านล่างว่าอะไรเป็นสาเหตุของปัญหานี้ ข่าวดีก็คือเรื่องนี้ได้รับการแก้ไขโดยทีมวิศวกรของเราเมื่อเร็ว ๆ นี้ ในการรับการแก้ไขสิ่งที่คุณต้องทำคือหยุด / เริ่มอินสแตนซ์ของ Windows Server 2008 ที่คุณเห็นปัญหานี้ อีกครั้งฉันไม่ได้พูดถึง REBOOT ซึ่งแตกต่าง STOP / START ทำให้อินสแตนซ์ย้ายไปที่โฮสต์ (เพื่อสุขภาพ) ที่แตกต่าง เมื่ออินสแตนซ์เหล่านี้เปิดขึ้นอีกครั้งพวกเขาจะทำงานบนโฮสต์ที่มีการแก้ไขเพื่อที่พวกเขาจะไม่มีปัญหานี้อีก ตอนนี้ด้านล่างคือคำอธิบายทางวิศวกรรมของปัญหานี้ หลังจากการตรวจสอบเชิงลึกเราพบว่าเมื่อใช้งาน Windows 2008 x64 บนอินสแตนซ์ส่วนใหญ่ที่มีให้เรา พบปัญหาซึ่งอาจส่งผลให้การเชื่อมต่อ TCP ที่เหลืออยู่ใน TIME_WAIT / CLOSE_WAIT เป็นเวลานานเกินไป (ในบางกรณียังคงอยู่ในสถานะนี้โดยไม่มีกำหนด) ในขณะที่อยู่ในสถานะเหล่านี้คู่ซ็อกเก็ตที่เฉพาะเจาะจงยังคงใช้งานไม่ได้และหากมีการสะสมเพียงพอจะส่งผลให้พอร์ตที่มีปัญหาหมดลง หากเหตุการณ์นี้เกิดขึ้นทางออกเดียวที่จะล้างซ็อกเก็ตคู่ที่มีปัญหาคือการรีบูตอินสแตนซ์ที่เป็นปัญหา เราได้พิจารณาสาเหตุที่เป็นค่าที่ผลิตโดยฟังก์ชั่นจับเวลาในเคอร์เนล Windows 2008 API ซึ่งบนแพลตฟอร์ม 64 บิตจำนวนมากของเราจะดึงค่าที่อยู่ไกลออกไปในอนาคต สิ่งนี้มีผลต่อสแต็ก TCP โดยทำให้การประทับเวลาของคู่ซ็อกเก็ต TCP ถูกประทับตราอย่างมีนัยสำคัญในอนาคต ตาม Microsoft มีตัวนับสะสมที่เก็บไว้ซึ่งจะไม่ได้รับการปรับปรุงเว้นแต่ค่าที่ผลิตโดยการเรียก API นี้จะใหญ่กว่าค่าสะสม ผลลัพธ์สุดท้ายคือซ็อกเก็ตที่สร้างขึ้นหลังจากจุดนี้ทั้งหมดจะถูกประทับตรามากเกินไปในอนาคตจนกว่าจะถึงเวลาในอนาคต ในบางกรณีเราได้เห็นคุณค่านี้หลายร้อยวันในอนาคตดังนั้นคู่ซ็อกเก็ตดูเหมือนจะติดอยู่ตลอดไป

คำตอบของไรอันเป็นคำแนะนำทั่วไปที่ดียกเว้นว่ามันจะไม่นำไปใช้กับเงื่อนไขที่ Ravi ประสบใน EC2 เราก็เคยเห็นปัญหานี้และด้วยเหตุผลใดก็ตามที่ Windows ไม่สนใจ TcpTimedWaitDelay อย่างสมบูรณ์และไม่เคยปล่อยซ็อกเก็ตออกจากสถานะ TIMED_WAIT

การรอไม่ช่วย ... เริ่มต้นแอปใหม่ไม่ได้ช่วย ... วิธีแก้ไขที่เราพบเท่านั้นคือรีสตาร์ทระบบปฏิบัติการ น่าเกลียดจริงๆ

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

ดังที่คนอื่น ๆ พูดถึงคุณต้องปรับ Windows Server ออกจากกล่อง อย่างไรก็ตามในลักษณะเดียวกับที่ StopWatch ไม่ทำงานในเธรดข้างต้นสแต็ค TCP / IP ยังใช้การQueryPerformanceCounterโทรเพื่อกำหนดว่าเมื่อใดควรใช้ช่วงเวลา TCP_TIME_WAIT ปัญหาคือใน EC2 พวกเขาได้พบและรู้เกี่ยวกับปัญหาที่QueryPerformanceCounterเกิดขึ้นยุ่งเหยิงและอาจย้อนเวลากลับไปไกลในอนาคต ไม่ใช่ว่าสถานะ TIME_WAIT ของคุณกำลังถูกเพิกเฉย แต่เป็นเวลาหมดอายุของ TIME_WAIT ที่อาจเกิดขึ้นในอนาคต เมื่อทำงานในการตั้งค่า httpd คุณสามารถดูว่าคุณจะสะสมซ็อกเก็ตซอมบี้เหล่านี้ได้อย่างรวดเร็วอย่างไรเมื่อพบสถานะ (โดยทั่วไปเราจะเห็นว่านี่เป็นเหตุการณ์ที่ไม่ต่อเนื่องไม่ใช่ว่าคุณสะสมซอมบี้อย่างช้าๆ)

สิ่งที่เราทำคือเรียกใช้บริการในพื้นหลังที่สอบถามจำนวนซ็อกเก็ตในสถานะ TIME_WAIT และเมื่อสิ่งนี้วนผ่านเกณฑ์ที่กำหนดเราจะดำเนินการ (รีบูตเซิร์ฟเวอร์) ในช่วง 45 วินาทีที่ผ่านมามีบางคนชี้ให้เห็นว่าคุณสามารถหยุด / เริ่มต้นเซิร์ฟเวอร์เพื่อแก้ไขปัญหาได้ - ฉันขอแนะนำให้คุณเข้าใกล้สองวิธีนี้

การตั้งค่าเริ่มต้นสำหรับสแต็ก TCP ใน Windows คือการพูดน้อยที่สุดไม่เหมาะสำหรับระบบที่กำลังโฮสต์เซิร์ฟเวอร์ HTTP

เพื่อให้ได้ประโยชน์สูงสุดจากเครื่อง windows ของคุณเมื่อใช้เป็นเซิร์ฟเวอร์ HTTP มีพารามิเตอร์บางอย่างที่คุณปรับแต่งตามปกติเช่น MaxUserPort TcpTimedWaitDelay, TcpAckFrequency, EnableDynamicBacklog, KeepAliveInterval และอื่น ๆ

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

ไม่เกี่ยวข้องกับ AWS เราเพิ่งพบปัญหานี้ดูเหมือนว่าเป็นผลมาจากบทความ KB นี้:

http://support.microsoft.com/kb/2553549/en-us

โดยทั่วไปจะเริ่มทำงานหากระบบใช้งานได้>> 497 วันและไม่มีการใช้งานโปรแกรมแก้ไขด่วน แน่นอนว่าการรีบูตได้ถูกล้างออกแล้ว - เราอาจไม่รู้ว่าในอีก 16 เดือนข้างหน้าหากการแก้ไขด่วนทำงานได้ แต่สิ่งนี้อาจช่วยทุกคนที่มีเซิร์ฟเวอร์ระยะเวลาทำงานนาน

ฉันพบสิ่งเดียวกันเกือบทุกกล่องด้วย Windows Server 2008 R2 x64 ที่ติดตั้ง SP1 ส่วนใหญ่เป็น CLOSE_WAIT (ซึ่งค่อนข้างแตกต่างจาก TIME_WAIT) ฉันชนเข้ากับคำตอบนี้ซึ่งอ้างอิงKB ที่ Microsoft และโปรแกรมแก้ไขด่วนถ้าเซิร์ฟเวอร์ที่ทำงานอยู่หลัง load balancer (ซึ่งเป็นของฉัน) หลังจากติดตั้งโปรแกรมแก้ไขด่วนและการรีบูตข้อมูล CLOSE_WAIT ทั้งหมดได้รับการแก้ไข