ตามที่ระบุไว้ในชื่อเรื่อง เรากำลังมีปัญหากับคลัสเตอร์ Cassandra ของเรา มี 9 โหนด กับ ปัจจัยการจำลองของ 3 โดยใช้ กลยุทธ์โทโพโลยีเครือข่าย. ทั้งหมดใน DC และ Rack เดียวกัน เวอร์ชั่นแคสแซนดราคือ 3.11.4 (วางแผนที่จะย้ายไป 3.11.10) มีอินสแตนซ์ 4 ซีพียู และ แรม 32GB. (วางแผนที่จะย้ายไปที่ 8 CPU)
เมื่อใดก็ตามที่เราพยายามเรียกใช้การซ่อมแซมในคลัสเตอร์ของเรา (โดยใช้ Cassandra Reaper บนโหนดใดโหนดหนึ่งของเรา) เราจะสูญเสียโหนดหนึ่งไปที่ไหนสักแห่งในกระบวนการ เราหยุดการซ่อมแซมอย่างรวดเร็ว รีสตาร์ทบริการ Cassandra บนโหนดและรอให้เข้าร่วมวงแหวน ดังนั้นเราจึงไม่สามารถดำเนินการซ่อมแซมได้ในทุกวันนี้
ฉันสังเกตเห็นปัญหาและตระหนักว่าปัญหานี้เกิดจากการใช้งาน CPU สูงในบางโหนดของเรา (ตรง 3). คุณอาจเห็นกราฟช่วงเวลา 1 สัปดาห์ด้านล่าง การขึ้นและลงเกิดจากการใช้งานแอพช่วงเช้าจะลดต่ำลงมาก
กราฟการใช้งาน CPU
ฉันเปรียบเทียบกระบวนการทำงานในแต่ละโหนดและไม่มีอะไรพิเศษในโหนดที่มี CPU สูง ฉันเปรียบเทียบการกำหนดค่า พวกเขาเหมือนกัน ไม่พบความแตกต่าง
ฉันยังตระหนักว่าโหนดเหล่านี้เป็นโหนดที่รับทราฟฟิกมากที่สุด ดูกราฟช่วงเวลา 1 สัปดาห์ด้านล่าง ทั้งไบต์ที่ส่งและรับ
กราฟไบต์ที่ส่งและรับ
ฉันได้ทำการวิจัยบางอย่าง ฉันพบ นี้ เธรดและในตอนท้ายขอแนะนำให้ตั้งค่า dynamic_snitch: เท็จ
ในการกำหนดค่าของ Cassandra ฉันดูที่กลยุทธ์ลูกสนิชของเราซึ่งก็คือ Gossiping PropertyFileSnitch. ในทางปฏิบัติ กลยุทธ์นี้ควรทำงานได้อย่างถูกต้อง แต่ฉันคิดว่าไม่เป็นเช่นนั้น
งานของลูกสนิชคือการให้ข้อมูลเกี่ยวกับโทโพโลยีเครือข่ายของคุณ เพื่อให้ Cassandra สามารถกำหนดเส้นทางคำขอได้อย่างมีประสิทธิภาพ
ข้อสังเกตเดียวของฉันที่อาจเป็นสาเหตุของปัญหานี้คือมีไฟล์ที่เรียกว่า Cassandra-topology.properties ซึ่งโดยเฉพาะ บอกให้ถอด หากใช้ GossipingPropertyFileSnitch
ชั้นวางและศูนย์ข้อมูลสำหรับโลคัลโหนดถูกกำหนดใน cassandra-rackdc.properties และเผยแพร่ไปยังโหนดอื่นผ่านการซุบซิบ หากมี cassandra-topology.properties อยู่ จะใช้เป็นทางเลือก อนุญาตให้โอนย้ายจาก PropertyFileSnitch
ฉันไม่ได้ลบไฟล์นี้เนื่องจากไม่พบข้อพิสูจน์ที่แน่ชัดว่านี่เป็นสาเหตุของปัญหา หากคุณมีความรู้ในเรื่องนี้หรือเห็นสาเหตุอื่นใดของปัญหาของฉัน ฉันขอขอบคุณสำหรับความช่วยเหลือของคุณ