แก้ไขปัญหาความหน่วงและการเข้าร่วมห้องช้าของ Matrix Synapse Federation

เริ่มจากการหาสาเหตุของความล่าช้า

เมื่อห้อง Matrix ใช้เวลานานในการเปิดหรือเข้าร่วม ให้ตรวจสอบก่อนว่าความล่าช้านั้นส่งผลกระทบต่อโฮมเซิร์ฟเวอร์ระยะไกลเครื่องใดเครื่องหนึ่ง ห้องใดห้องหนึ่ง หรืออินสแตนซ์ Synapse ทั้งหมดของคุณ ความแตกต่างนี้มีความสำคัญ: การเชื่อมต่อแบบเฟเดอเรชั่นเป็นการแลกเปลี่ยนข้อมูลสองทางระหว่างโฮมเซิร์ฟเวอร์ และการเข้าร่วมห้องอาจเกี่ยวข้องกับเซิร์ฟเวอร์หลายเครื่อง การเข้าร่วมที่ช้าอาจเกิดจากกระบวนการ Synapse ของคุณ เซิร์ฟเวอร์ระยะไกล การกำหนดเส้นทาง DNS หรือ TLS ฐานข้อมูล หรือขนาดและสถานะของห้อง ไม่มีตัวเลือก "ความล่าช้าในการเชื่อมต่อแบบเฟเดอเรชั่น" เพียงตัวเดียวที่แก้ไขปัญหาทั้งหมดนี้ได้

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

ตรวจสอบว่าสามารถเชื่อมต่อกับสหพันธ์ได้หรือไม่

ใช้เครื่องมือทดสอบ Matrix Federation Tester อย่างเป็นทางการ โดยใช้ชื่อเซิร์ฟเวอร์ Matrix ของโฮมเซิร์ฟเวอร์ของคุณ เครื่องมือนี้สามารถเปิดเผยปัญหาทั่วไปเกี่ยวกับ DNS, การมอบหมายสิทธิ์, ใบรับรอง และการเข้าถึงได้ ชื่อเซิร์ฟเวอร์ในรหัสผู้ใช้อาจแตกต่างจากเครื่องหรือพร็อกซีที่ให้บริการ Synapse ดังนั้นควรตรวจสอบปลายทางของ Federation และการมอบหมายสิทธิ์ที่กำหนดค่าไว้ แทนที่จะสันนิษฐานว่าโดเมนของรหัสผู้ใช้จะต้องโฮสต์ Synapse โดยตรง

เอกสารประกอบการใช้งาน Federation ของ Synapse ระบุว่าพอร์ต Federation เริ่มต้นคือ TCP 8448 ในขณะที่การใช้งานแบบ Delegated หรือ Reverse Proxy สามารถใช้ HTTPS บนพอร์ต 443 ได้ พอร์ตที่เกี่ยวข้องต้องสามารถเข้าถึงได้จาก Home Server อื่นๆ และไฟร์วอลล์ขาออกอาจต้องอนุญาตการรับส่งข้อมูล Federation ด้วย ตรวจสอบกฎไฟร์วอลล์ขาเข้าและขาออกที่ตรงกัน จากนั้นทดสอบอีกครั้งจาก Federation Tester อย่าเปิดทั้งสองพอร์ตโดยไม่เลือกปฏิบัติหากการใช้งานของคุณถูกกำหนดค่าให้ใช้เพียงพอร์ตเดียว

ผลลัพธ์ที่แสดงข้อผิดพลาดเกี่ยวกับใบรับรอง DNS หรือการกำหนดเส้นทาง ชี้ให้เห็นถึงปัญหาด้านการกำหนดค่าหรือการเข้าถึงเครือข่าย ไม่ใช่ความจุของเซิร์ฟเวอร์ ตรวจสอบบันทึก DNS และการมอบหมายสิทธิ์สำหรับชื่อเซิร์ฟเวอร์ Matrix, ห่วงโซ่ใบรับรอง TLS ของพร็อกซีแบบย้อนกลับ และตรวจสอบว่าพร็อกซีส่งต่อเส้นทางการรวมระบบไปยัง Synapse หรือไม่ เอกสารของ Synapse ระบุว่าการเปลี่ยนเส้นทางถาวร 308 อาจไม่ได้รับการปฏิบัติตามโดยเซิร์ฟเวอร์ที่รวมระบบในบางการตั้งค่า ดังนั้นควรตรวจสอบการเปลี่ยนเส้นทางที่ไม่คาดคิดด้วย แก้ไขการตรวจสอบที่ล้มเหลวเฉพาะจุดและทดสอบอีกครั้งก่อนที่จะเปลี่ยนจำนวนผู้ปฏิบัติงานหรือขีดจำกัดอัตรา

อ้างอิง: การตั้งค่าและการแก้ไขปัญหา Synapse federationและ คำแนะนำ เกี่ยวกับไฟร์วอลล์ Synapse

ตรวจสอบว่าเซิร์ฟเวอร์ระยะไกลเครื่องใดเครื่องหนึ่งอยู่ในช่วงเวลาคูลดาวน์การลองใหม่หรือไม่

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

ผู้ดูแลระบบสามารถตรวจสอบ Synapse Federation Admin API ซึ่งมีเอกสารอธิบายGET /_synapse/admin/v1/federation/destinationsไว้ ใช้โทเค็นการเข้าถึงผู้ดูแลระบบเซิร์ฟเวอร์และเก็บรักษาไว้เป็นส่วนตัว ตรวจสอบบันทึกปลายทางและฟิลด์การลองใหม่สำหรับโฮมเซิร์ฟเวอร์ที่เกี่ยวข้องในห้องที่ได้รับผลกระทบ บันทึกเหล่านี้ช่วยระบุว่าปลายทางกำลังลองใหม่เมื่อใด แต่ไม่ได้พิสูจน์สาเหตุที่การเชื่อมต่อล้มเหลวโดยตัวมันเอง ให้เชื่อมโยงข้อมูลเหล่านี้กับบันทึกของ Synapse บันทึกพร็อกซี การทดสอบ DNS/TLS และเวลาที่ผู้ใช้รายงานปัญหา

เอกสารระบุว่า Federation Admin API ยังอยู่ในระหว่างการทดลองและอาจมีการเปลี่ยนแปลงได้ โปรดหลีกเลี่ยงการเขียนสคริปต์เพื่อใช้งานราวกับว่าเป็น API ไคลเอ็นต์สาธารณะที่เสถียร Synapse ยังได้ระบุการดำเนินการ reset-connection-timeout ซึ่งอาจกระตุ้นให้เกิดการพยายามเชื่อมต่อในเบื้องหลังอีกครั้งสำหรับปลายทางที่อยู่ในช่วงเวลาคูลดาวน์แล้ว โปรดดำเนินการดังกล่าวเพื่อการวินิจฉัยหรือแก้ไขปัญหาหลังจากแก้ไขหรือทำความเข้าใจความล้มเหลวที่เกิดขึ้นแล้วเท่านั้น การล้างคูลดาวน์ซ้ำๆ ไม่สามารถทำให้เซิร์ฟเวอร์ระยะไกลที่ไม่สมบูรณ์ตอบสนองได้ การตอบสนอง HTTP ที่สำเร็จจากปลายทางรีเซ็ตไม่ได้หมายความว่าการพยายามเชื่อมต่อในเบื้องหลังเสร็จสมบูรณ์แล้ว

อ้างอิง: Synapse Federation Admin APIสถานะการทดลองใช้งานและฟิลด์ที่มีให้ใช้งานของ API อาจเปลี่ยนแปลงไปตามการออกเวอร์ชันของ Synapse ดังนั้น โปรดตรวจสอบเอกสารประกอบสำหรับเวอร์ชันที่คุณใช้งานก่อนที่จะดำเนินการใดๆ

วัดประสิทธิภาพของ Synapse และฐานข้อมูลก่อนที่จะขยายขนาด

เปิดใช้งานเอนด์พอยต์เมตริก Prometheus ของ Synapse เฉพาะบนเครือข่ายภายในที่เชื่อถือได้ หรืออยู่เบื้องหลังการควบคุมการเข้าถึงเท่านั้น คู่มือการตรวจสอบอย่างเป็นทางการจะอธิบาย/_synapse/metricsและแสดงวิธีการเปิดเผยผ่านตัวรับฟังเมตริกหรือตัวรับฟัง HTTP ที่มีอยู่ เมตริกอาจรวมถึงรายละเอียดการดำเนินงาน อย่าเผยแพร่เอนด์พอยต์นี้อย่างเปิดเผย หากคุณรวบรวมเมตริกอยู่แล้ว ให้เปรียบเทียบเวลาของการเข้าร่วมที่ช้ากับ CPU หน่วยความจำ ความหน่วงของคำขอ ระยะเวลาการทำธุรกรรมฐานข้อมูล และกิจกรรมการรวมระบบขาเข้าและขาออก

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

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

เอกสารอ้างอิง: การตรวจสอบ Synapse Prometheusและการทำความเข้าใจ Synapse ผ่านกราฟ Grafana

ตรวจสอบการจำกัดปริมาณการรับส่งข้อมูลและการส่งข้อมูลแบบเป็นช่วงๆ เมื่อเข้าร่วมห้อง

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

อย่าเพิ่มขีดจำกัดอัตราการเข้าร่วม (rate limits) เพื่อแก้ไขปัญหาความเร็วโดยทั่วไป การเพิ่มขีดจำกัดอาจเพิ่มภาระให้กับเซิร์ฟเวอร์ของคุณและโฮมเซิร์ฟเวอร์อื่นๆ และอาจลดการป้องกันการโจมตีแบบ join floods หากการย้ายข้อมูลหรือการเริ่มต้นใช้งานจำนวนมากเกินขีดจำกัดที่กำหนดไว้ ให้ระบุขีดจำกัดที่แน่นอนและตรวจสอบค่าที่บันทึกไว้ในปัจจุบันสำหรับเวอร์ชัน Synapse ของคุณ พิจารณาแบ่งการทำงานแบบ join flood ออกเป็นช่วงๆ เปลี่ยนค่าที่เกี่ยวข้องทีละค่า รักษาการกำหนดค่าก่อนหน้าไว้ และตรวจสอบอัตราข้อผิดพลาดและการใช้ทรัพยากรหลังจากโหลดใหม่หรือรีสตาร์ทตามที่การใช้งานของคุณกำหนด

อ้างอิง: การตั้งค่า Synapse:rc_joinsและการตั้งค่า Synapse:rc_joins_per_roomค่าเริ่มต้นและตัวเลือกที่รองรับอาจแตกต่างกันไปในแต่ละเวอร์ชัน โปรดเปรียบเทียบกับเวอร์ชันที่ติดตั้งไว้ก่อนทำการแก้ไข

ใช้การทดสอบการเชื่อมต่อแบบควบคุม

1. เลือกห้องที่มีปัญหาหนึ่งห้อง แล้วบันทึกชื่อห้องหรือรหัสห้อง โฮมเซิร์ฟเวอร์ของผู้ใช้ที่เข้าร่วม เวลา และข้อผิดพลาดของไคลเอ็นต์ที่เกิดขึ้นอย่างแม่นยำ ห้ามบันทึกโทเค็นการเข้าถึงลงในบันทึกการสนับสนุนเด็ดขาด
2. ตรวจสอบชื่อเซิร์ฟเวอร์ของคุณใน Federation Tester และยืนยันปลายทางการเชื่อมต่อเครือข่าย (federation endpoint) ใบรับรอง และเส้นทางพร็อกซีที่กำหนดค่าไว้
3. ตรวจสอบบันทึก Synapse ในช่วงเวลาดังกล่าวเพื่อหาข้อผิดพลาดในการเชื่อมต่อเครือข่าย ข้อผิดพลาดปลายทางระยะไกล การหมดเวลา หรือการตอบสนองที่เกินขีดจำกัดอัตรา ค้นหาบันทึกของพร็อกซีแบบย้อนกลับและฐานข้อมูลเพื่อหาความล่าช้าที่ตรงกัน
4. ตรวจสอบ API ผู้ดูแลระบบสหพันธ์เพื่อดูสถานะการลองใหม่ที่เกี่ยวข้องกับปลายทางระยะไกลที่เกี่ยวข้อง เปรียบเทียบห้องที่ได้รับผลกระทบกับห้องควบคุมที่เข้าร่วมได้อย่างรวดเร็ว
5. เปรียบเทียบเมตริกของ Prometheus และโฮสต์ในช่วงเวลาเดียวกัน สังเกตหาค่าความหน่วงในการร้องขอที่สูงขึ้น ระยะเวลาในการทำธุรกรรมฐานข้อมูล การใช้งาน CPU และหน่วยความจำ หรือกิจกรรมการเชื่อมต่อเครือข่ายที่เพิ่มขึ้นอย่างผิดปกติ
6. ทำการแก้ไขเฉพาะจุดหนึ่ง เช่น แก้ไขปัญหา DNS/TLS/พร็อกซี แก้ปัญหาคอขวดของฐานข้อมูล หรือปรับข้อจำกัดอัตราการใช้งานที่ได้รับการยืนยันแล้ว จากนั้นทำการทดสอบซ้ำและเปรียบเทียบผลลัพธ์

ข้อสันนิษฐานทั่วไปที่ควรหลีกเลี่ยง

• “การเข้าร่วมช้าหมายความว่าพอร์ต 8448 ของเซิร์ฟเวอร์ของฉันปิดอยู่”ไม่จำเป็นเสมอไป การมอบหมายหรือพร็อกซีแบบย้อนกลับอาจใช้พอร์ต 443 ตรวจสอบปลายทางของเฟเดอเรชันที่กำหนดค่าไว้จริงและทดสอบดู
• “การทดสอบการเชื่อมต่อระบบเครือข่ายที่ประสบความสำเร็จพิสูจน์ได้ว่าการเข้าร่วมห้องทุกห้องจะรวดเร็ว”แต่การทดสอบนี้ตรวจสอบเฉพาะการตั้งค่าและการเชื่อมต่อระบบเครือข่ายทั่วไปเท่านั้น สุขภาพของเซิร์ฟเวอร์ระยะไกล สถานะของห้อง โหลดในเครื่อง และประสิทธิภาพของฐานข้อมูลยังคงส่งผลต่อการเข้าร่วมได้ ควรทดสอบห้องที่ได้รับผลกระทบและตรวจสอบบันทึกการทำงาน
• “ความล่าช้าในการเชื่อมต่อเครือข่ายมักเกิดจากอินสแตนซ์ Synapse ของฉันเอง”เอกสารการตั้งค่าของ Synapse เองก็เตือนว่า ความล่าช้าในการเชื่อมต่อเครือข่ายที่สังเกตได้นั้น อาจเกิดจากปลายทางใดปลายทางหนึ่ง หรือจากเครือข่ายระหว่างปลายทางทั้งสองก็ได้ ควรเปรียบเทียบปลายทางและรวบรวมหลักฐานจากทั้งสองฝั่งหากเป็นไปได้
• “การเพิ่มจำนวนพนักงานหรือการเพิ่มขีดจำกัดอัตราการส่งข้อมูลเป็นวิธีแก้ปัญหาเบื้องต้น” การเปลี่ยนแปลงเหล่านี้จะมีประโยชน์ก็ต่อเมื่อการวัดผลชี้ให้เห็นถึงปัญหาด้านความจุหรือการจำกัดปริมาณข้อมูลเท่านั้น ขั้นแรกให้ระบุว่าปัญหาเกิดจากการเชื่อมต่อ การลองเชื่อมต่อใหม่จากระยะไกล ความอิ่มตัวของระบบในพื้นที่ ความล่าช้าของฐานข้อมูล หรือการจำกัดอัตราการเข้าร่วมข้อมูล

ตรวจสอบว่าการแก้ไขได้ผลหรือไม่

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

หากการตรวจสอบเมตริกและการเชื่อมต่อเครือข่ายภายในของคุณอยู่ในเกณฑ์ดี แต่มีเพียงโฮมเซิร์ฟเวอร์ระยะไกลเครื่องเดียวที่ยังคงล้มเหลว โปรดแชร์เวลาที่เกิดเหตุ ปลายทาง ข้อผิดพลาดที่กรองแล้ว และรหัสคำขอที่เกี่ยวข้องให้กับผู้ดูแลระบบของเซิร์ฟเวอร์นั้น หากมีหลายห้องและปลายทางที่ได้รับผลกระทบพร้อมกับคำขอภายในที่ช้า โปรดตรวจสอบความจุของ Synapse และ PostgreSQL ก่อนที่จะปรับแต่งพฤติกรรมการเชื่อมต่อเครือข่าย บันทึกเวอร์ชัน Synapse ของคุณไว้ในบันทึกเหตุการณ์ เนื่องจากรายละเอียดการกำหนดค่าและ Admin API มีการเปลี่ยนแปลงอยู่เสมอ