Score:1

เหตุใดแอปพลิเคชัน Tomcat Java ของเราจึงเปิดการเชื่อมต่อหลายร้อยรายการไปยังฐานข้อมูลของเราในทันใด

ธง it

เรามีแอปพลิเคชัน Tomcat ที่ทำงานบน Elastic Beanstalk และฐานข้อมูล MySQL ของเราโฮสต์อยู่บน AWS RDS (2 หรือ 3 อินสแตนซ์ t3.medium) นับตั้งแต่เราอัปเกรดจาก MySQL 5 เป็น MySQL 8 (ปัจจุบันคือ 8.0.23) เราประสบปัญหาที่เกิดขึ้นประมาณสัปดาห์ละครั้งส่วนใหญ่แล้วฐานข้อมูลปกติดี แต่จู่ๆ จำนวนการเชื่อมต่อก็พุ่งสูงขึ้นอย่างรวดเร็ว (บางครั้งอาจเกินขีดจำกัดการเชื่อมต่อ 307 รายการในช่วง 1 นาที ซึ่งเป็นสิ่งที่เราไม่เข้าใจเช่นกัน เป็นอย่างไร สามารถก้าวข้ามขีดจำกัดนั้นได้หรือไม่) และนั่นทำให้อินสแตนซ์ของ Elastic Beanstalk ลดลง บางครั้งฐานข้อมูลทั้งหมดจะล้มเหลวหลังจากการเชื่อมต่อเหล่านั้นถึงจุดสูงสุด

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

ฉันใช้ Googled มามากแล้ว พยายามหาคนที่เคยมีปัญหาคล้ายๆ กัน เพื่อที่จะอธิบายปัญหา เรายังได้พยายามวิเคราะห์การค้นหาที่แพงที่สุดและข้อมูลเชิงลึกเกี่ยวกับประสิทธิภาพของฐานข้อมูลอื่นๆ แต่ดูเหมือนจะไม่มีรูปแบบที่ชัดเจน

Wilson Hauck avatar
jp flag
การขัดขวางจะชัดเจนขึ้นในชั่วขณะหนึ่ง - นานแค่ไหน? คุณจะทำให้ระบบของคุณกลับมาออนไลน์ได้อย่างไร?
Helder Sérvio avatar
it flag
@WilsonHauck เมื่อการขัดขวางเกิดขึ้น การตรวจสอบความสมบูรณ์ของโหลดบาลานเซอร์เริ่มทำงานล้มเหลว ซึ่งทำให้ Elastic Beanstalk ดึงอินสแตนซ์ลงมาและแทนที่ ซึ่งจะช่วยแก้ปัญหาได้ในที่สุด
Score:1
ธง ua

เราควรมองหาต้นตอของปัญหาจากที่ใด

  • เปิดใช้งาน slowlog ใน MySQL และ (หลังจากการขัดขวาง) ตรวจสอบว่าข้อความค้นหาใดที่กำลังทำงานอยู่ในขณะนั้น หากสโลว์ล็อกไม่แสดงมากนัก ให้ลดลง long_query_time ก่อนการขัดขวางครั้งต่อไป
  • (ฉันไม่รู้ว่า Tomcat มีบันทึกหรือไม่)
  • มันเกิดขึ้นในเวลาเดียวกันทุกวันหรือทุกสัปดาห์หรือไม่?
  • Amazon จะสำรองข้อมูลเมื่อใด
  • หากคุณกำลังออนไลน์เมื่อสิ่งนี้เกิดขึ้น ให้ดูว่าคุณสามารถทำได้หรือไม่ แสดงรายการกระบวนการ;. เชื่อมต่อตัวเอง การเชื่อมต่ออาจทำได้ยากเมื่อคุณเห็นหนามแหลม
  • MySQL 'ตัวแปร' max_connections ควบคุม 307 การเพิ่มอาจทำให้ด้านบนของขัดขวาง แต่ทำให้แย่ลง (ฉันไม่เห็นว่านี่เป็น "วิธีแก้ปัญหา")
  • Tomcat สามารถ [อาจ] ระงับการเชื่อมต่อส่วนเกินโดยไม่ทำร้ายสิ่งต่าง ๆ มากเกินไป มีแนวโน้มว่าจะดีกว่าที่จะเค้น Tomcat มากกว่าเปลี่ยน 307 เมื่อ MySQL มี "การเชื่อมต่อที่ไม่ว่างจำนวนมาก" จะทำให้แต่ละคนสามารถเข้าถึงทรัพยากรได้อย่างเท่าเทียมกัน สิ่งนี้มีผลในการชะลอตัวลง ทั้งหมด การเชื่อมต่อ
Helder Sérvio avatar
it flag
เราได้ตรวจสอบบันทึกการสืบค้นที่ช้าแล้ว และเราสามารถลบ/จัดโครงสร้างข้อความค้นหาเต็มเวลาราคาแพงสองสามรายการเมื่อสถานการณ์เลวร้ายจริงๆ (DB หยุดทำงานตลอดเวลา) แต่ถึงกระนั้น ก็ไม่ได้อธิบายว่าทำไม ปัญหาเริ่มเกิดขึ้นหลังจากการเปลี่ยนไปใช้ MySQL 8 เท่านั้น Tomcat มีบันทึก แต่เราไม่ได้จัดเก็บไว้หลังจากที่อินสแตนซ์ถูกทำลาย เราจะทำอย่างนั้นในครั้งต่อไปและดูที่เธรด และไม่ มันแตกต่างกันมากในความถี่และเวลา ไม่ทับซ้อนกับข้อมูลสำรอง
Wilson Hauck avatar
jp flag
@HelderSérvio ขอข้อมูลเพิ่มเติมได้โปรด ประเภทอินสแตนซ์ AWS - ขนาด RAM, # คอร์, อุปกรณ์ SSD หรือ NVME ใดๆ บนเซิร์ฟเวอร์โฮสต์ MySQL โพสต์บน pastebin.com และแชร์ลิงก์ จากรูทการเข้าสู่ระบบ SSH ของคุณ ผลลัพธ์ข้อความของ: ก) เลือก COUNT(*) จาก information_schema.tables; B) แสดงสถานะทั่วโลก; หลังจาก UPTIME ขั้นต่ำ 24 ชั่วโมง C) แสดงตัวแปรทั่วโลก; D) แสดงรายการกระบวนการทั้งหมด; จ) สถานะ; ไม่แสดงสถานะเพียงสถานะ; สำหรับการวิเคราะห์การปรับแต่งเวิร์กโหลดของเซิร์ฟเวอร์เพื่อให้คำแนะนำ
Helder Sérvio avatar
it flag
@วิลสัน แฮค เซิร์ฟเวอร์มีอินสแตนซ์ 2-3 t4g.small (2 GiB, 2 vCPU) ในขณะที่ฐานข้อมูลเป็น (เดียว ฉันเข้าใจผิดเมื่อฉันบอกว่าเป็น 2-3) t3.medium (4 GiB, 2 vCPU) อินสแตนซ์ ด้วย gp2 SSD ฉันไม่มีสิทธิ์เข้าถึงฐานข้อมูลโดยตรง ดังนั้นฉันเกรงว่าจะไม่สามารถแสดงผลลัพธ์ของข้อความค้นหาเหล่านั้นให้คุณได้อย่างไรก็ตาม เจ้านายของฉันได้ทิ้งตารางคิวรีที่ช้าให้ฉัน โดยพื้นฐานแล้ว สิ่งที่เกิดขึ้นคือ ณ ช่วงเวลาหนึ่ง ข้อความค้นหาทั้งหมดจะเริ่มช้าลง (ความหนาแน่นของข้อความค้นหาที่ช้าจะเพิ่มขึ้นอย่างมาก) จนกระทั่งข้อความค้นหาบางรายการมีความยาวประมาณ 2 หรือ 3 นาที ข้อมูลเชิงลึกเกี่ยวกับประสิทธิภาพ RDS แสดงการรอ LOCK_table_cache ที่ยาวนาน
Wilson Hauck avatar
jp flag
@HelderSérvio คุณช่วยโพสต์ข้อมูลการสืบค้นช้าที่เจ้านายของคุณให้ไว้ได้ไหม เจ้านายของคุณสามารถเรียกใช้รายการด้านบน โพสต์ข้อมูลไปที่ pastebin.com และคุณแบ่งปันลิงก์กับเราสำหรับการวิเคราะห์ภาระงานของอินสแตนซ์ t3.medium ของคุณได้หรือไม่
ua flag
"ความหนาแน่นเพิ่มขึ้น" -- บ่อยครั้งที่ข้อความค้นหาเดียวทำให้เกิดความแออัด บางครั้ง `SHOW PROCESSLIST` อาจมองเห็นได้ แต่การทำให้ได้นั้นเป็นเรื่องยาก บันทึกช้าดิบบางครั้งสามารถแสดงว่าข้อความค้นหาใดเป็นข้อความค้นหาที่ซุกซน ("ย่อย" แบบสอบถามจะดีกว่าสำหรับการค้นหาว่าแบบสอบถามใดเป็นภาระมากที่สุดสำหรับระบบ)

โพสต์คำตอบ

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