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

บนเส้นทาง Linux ที่ใช้การติดตามการเชื่อมต่อ ตัวเลือกหนึ่งคือตาราง conntrack ตรวจสอบค่าที่มีอยู่บนเครื่องและในเนมสเปซเครือข่ายที่จัดการทราฟฟิก:

/proc/sys/net/netfilter/nf_conntrack_count
/proc/sys/net/netfilter/nf_conntrack_max

ค่าแรกแสดงรายการโฟลว์ที่จัดสรรไว้ ส่วนค่าที่สองจำกัดค่าเหล่านั้น ค่าเหล่านี้ไม่ใช่จำนวนผู้ใช้ Squid หรือคำขอ HTTP สถานะโฟลว์ของเคอร์เนลอาจอยู่ได้นานกว่างานที่แอปพลิเคชันกำลังทำอยู่

มองหาความสัมพันธ์ ไม่ใช่แค่ตัวเลขมาก

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

ตารางนี้อาจให้บริการมากกว่าพร็อกซี บริการอื่นในเครื่อง ทราฟฟิกที่ส่งต่อ หรือเส้นทางเครือข่ายอื่นที่คับคั่งอาจมีส่วนร่วม การที่รีสตาร์ตพร็อกซีแล้วอาการเปลี่ยนไม่ได้พิสูจน์ว่าแคชออบเจ็กต์ของ Squid เป็นสาเหตุ

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

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

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

บทความที่เกี่ยวข้อง