อธิบายภาระของเซิร์ฟเวอร์ VPN: ผู้ใช้ CPU หรืออัปลิงก์
คะแนนภาระต่ำอาจหมายถึงผู้ใช้ที่ไม่ได้ใช้งาน CPU ที่เหลือ หรืออัปลิงก์ที่กว้าง อ่าน loadavg ตัวนับอินเทอร์เฟซ และไฟล์สถานะก่อนจะเรียกมันว่าเร็ว
เกตเวย์ที่มีภาระ 0.4 ก็ยังอาจคลานช้าสำหรับผู้ใช้ทุกคนที่อยู่ข้างหลังได้ ภาระเฉลี่ยนั้นนับงานที่พร้อมรันหรือที่ติดค้างอยู่ในสภาวะหลับที่ไม่ถูกขัดจังหวะ และบนโฮสต์สี่คอร์นั้นโปรเซสเดียวที่อิ่มตัวก็เพียงพอจะดันให้เข้าใกล้ 1.0 ขณะที่อีกสามคอร์ว่างอยู่ การอ่านตัวเลขนั้นว่าเป็นส่วนเหลือคือข้อผิดพลาดที่พบบ่อยที่สุดในการเลือกปลายทาง สิ่งที่จำกัดทันเนลจริง ๆ มักเป็นหนึ่งในสี่อย่าง: คอร์ที่ยุ่งหนึ่งคอร์ อัปลิงก์ คิวที่อยู่ข้างหน้า หรือนโยบายต่อเซสชันที่ไม่มีใครจัดทำเอกสาร
ภาระเฉลี่ยนั้นนับงาน ไม่ได้วัดปริมาณงานที่ส่งผ่าน
เคอร์เนลสุ่มตัวอย่างคิวการรันและจำนวนงานที่รออินพุตและเอาต์พุต แล้วปรับให้เรียบทั้งสองค่าภายในหนึ่ง ห้า และสิบห้านาที ไม่มีสิ่งใดในนิยามนั้นกล่าวถึงไบต์ แพ็กเก็ต หรือทันเนล โฮสต์ที่สตอเรจติดขัดอาจรายงานภาระสูงโดยแทบไม่มีทราฟฟิก และโฮสต์ที่ดันกิกะบิตผ่านเส้นทางข้อมูลของเคอร์เนลอาจรายงานภาระที่สบาย
ดังนั้นการเชื่อมโยงภาระกับประสิทธิภาพของทันเนลจึงต้องมองแยกทีละคอร์ ถ้าคอร์หนึ่งเต็ม เปอร์เซ็นต์รวมบนแดชบอร์ดก็ยังดูดี:
cat /proc/loadavg
mpstat -P ALL 1 1
top -H -b -n 1 | head -n 20คำสั่งที่สามคือสิ่งที่สำคัญที่สุดบนโฮสต์ VPN การประมวลผลแพ็กเก็ตในพื้นที่ผู้ใช้ของ OpenVPN 2.x ส่วนใหญ่เรียงลำดับต่อโปรเซส ดังนั้นเธรดที่ยุ่งเพียงเธรดเดียวอาจกลายเป็นเพดาน ขณะที่แดชบอร์ดรายงานความจุว่างเหลือเฟือ ถ้าเธรดหนึ่งยึดเกือบทั้งคอร์ไว้ในช่วงที่ช้า โฮสต์ไม่ได้จัดสรรน้อยเกินไปโดยรวม แต่ถูกจำกัดในมิติที่บังเอิญสำคัญ
สังเกตเวลาด้วย ค่าเฉลี่ยสิบห้านาทีซ่อนการพุ่งที่ทำให้การโทรเสีย ดังนั้นภาพหน้าจอที่ถ่ายหลังการร้องเรียนจึงเป็นหลักฐานที่อ่อน เก็บตัวอย่างระหว่างเกิดปัญหา และเก็บเวลากำกับไว้กับผลลัพธ์
อัปลิงก์และคิวที่อยู่ข้างหน้า
ตัวนับอินเทอร์เฟซตอบคำถามเรื่องแบนด์วิดท์ที่ตัวเลข CPU ตอบไม่ได้ พวกมันยังแยกความจุออกจากการสูญเสีย ซึ่งเป็นความล้มเหลวต่างกันด้วยวิธีแก้ต่างกัน:
ip -s link show dev eth0
tc -s qdisc show dev eth0
nstat -az TcpRetransSegs TcpExtTCPLostRetransmitลิงก์ที่ใกล้ความเร็วที่จัดสรรให้ระหว่างการทดสอบคือคำอธิบาย และปริมาณ CPU ที่ว่างก็ไม่เปลี่ยนสิ่งนั้น บรรทัด qdisc เพิ่มรายละเอียดที่สำคัญสำหรับทราฟฟิกแบบโต้ตอบ: ปริมาณค้างสะสมและการดรอปบอกว่ามีแพ็กเก็ตกำลังรอในคิวหรือไม่ก่อนออกไป คิวที่เต็มภายใต้การอัปโหลดขนาดใหญ่สร้างอาการเดียวกับที่ผู้คนโทษเซิร์ฟเวอร์ปลายทาง นั่นคือการโทรที่หน่วงบนการเชื่อมต่อที่ยังวัดผลได้ดี
ตัวนับการส่งซ้ำจับกรณีที่แพ็กเก็ตออกไปแต่ไม่เคยไปถึงอย่างสมบูรณ์ ถ้าการส่งซ้ำเพิ่มขึ้นในช่วงเวลาที่ช้าและอินเทอร์เฟซยังห่างจากความจุ ปัญหาอยู่ที่เส้นทางไม่ใช่ที่โฮสต์ และการย้ายไปปลายทางอื่นในเมืองเดียวกันก็ไม่ช่วย
จำนวนเซสชันบอกความต้องการ ไม่ได้บอกส่วนเหลือ
ไดเรกทอรีสาธารณะทุกแห่งแสดงจำนวนผู้ใช้ที่เชื่อมต่ออยู่ระดับหนึ่ง และแทบไม่มีที่ใดบอกว่าผู้ใช้เหล่านั้นกำลังทำอะไร ยี่สิบเซสชันที่ทำงานโต้ตอบกับสี่เซสชันที่ดึงไฟล์ขนาดใหญ่สร้างภาระที่ต่างกันมากบนฮาร์ดแวร์เดียวกัน รูปแบบที่สองมองไม่เห็นในจำนวนผู้ใช้ และนั่นคือสิ่งที่ทำให้ค่ำคืนเสียไป ดังนั้นจำนวนเซสชันจึงควรอ่านเป็นเบาะแสเรื่องความต้องการ ไม่ใช่เป็นคำแถลงเรื่องความจุว่าง
| Number on the page | What it is really measuring | What it cannot tell you |
|---|---|---|
| Connected users | How many sessions hold an address | How much each one is transferring |
| Load or score | Whatever the operator chose to publish | Whether that definition matches your task |
| Uptime | How long since the process started | Current capacity, queue depth or packet loss |
| Distance or ping | Round-trip time on a small probe | Throughput under sustained transfer |
บนโฮสต์ที่คุณควบคุม ไฟล์สถานะให้มิติที่ขาดไป OpenVPN เขียนสแนปช็อตเป็นระยะซึ่งรวมตัวนับไบต์ต่อไคลเอนต์ และนั่นก็พอจะดูว่าเซสชันเดียวรับผิดชอบอัปลิงก์ทั้งหมดหรือไม่:
status /run/openvpn/server.status 10
# then, after at least one interval
grep -E "^CLIENT_LIST" /run/openvpn/server.statusสองตัวอย่างที่ห่างกันสิบวินาทีเปลี่ยนตัวนับสะสมเหล่านั้นเป็นอัตราต่อไคลเอนต์ นั่นคือการวัดที่จำนวนผู้ใช้เข้าแทนที่ และนี่คือวิธีที่คุณค้นพบว่าไคลเอนต์หนึ่งที่กำหนดค่าผิดทำให้ลิงก์อิ่มตัวทุกคืนในเวลาเดียวกัน
ขีดจำกัดต่อเซสชันซ่อนอยู่ในนโยบาย
เซิร์ฟเวอร์อาจว่างแต่ก็ยังปฏิเสธที่จะให้แบนด์วิดท์แก่คุณ ขีดจำกัดอัตรา เพดานแบนด์วิดท์ต่อไคลเอนต์ และการจัดรูปทราฟฟิกมักใช้ตามชื่อร่วมหรือตามพูล ดังนั้นผู้ใช้สองคนบนเกตเวย์เดียวกันอาจได้ผลลัพธ์ต่างกันมาก กลไกไม่ซับซ้อน แต่มองไม่เห็นจากภายนอกเพราะทันเนลขึ้นตามปกติในทั้งสองกรณี
มองหาการจัดรูปที่อินเทอร์เฟซของทันเนล ไม่ใช่ที่อินเทอร์เฟซกายภาพ ตรวจสอบว่าขีดจำกัดตามผู้ใช้ ใบรับรอง หรือพูลที่อยู่ ถ้าบัญชีทดสอบของคุณตกไปอยู่ในพูลที่ไม่จำกัด คุณจะสรุปว่าเซิร์ฟเวอร์ปกติดีและผู้ใช้ที่ร้องเรียนคิดผิด ข้อสรุปนั้นแย่กว่าการไม่มีข้อสรุป เพราะมันปิดตั๋ว
เปรียบเทียบสองปลายทางด้วยงานเดียวที่ตรึงไว้
การทดลองฝั่งไคลเอนต์ยังคุ้มค่าที่จะทำ แต่เฉพาะเมื่อตรึงตัวแปรไว้ ใช้อุปกรณ์เดิม เครือข่ายเข้าถึงเดิม โพรโทคอลเดิม และไฟล์ปลายทางเดิม แล้วทำซ้ำกับปลายทางที่สองในระยะทางที่ใกล้เคียง สิ่งใดที่เปลี่ยนไประหว่างการรัน รวมถึงช่วงเวลาของวัน ย่อมปนเปื้อนผลลัพธ์
บันทึกความล้มเหลวอย่างรอบคอบเท่ากับความสำเร็จ ชุดที่ปลายทางสามจุดทำงานและหนึ่งจุดหมดเวลานั้นให้ข้อมูลมากกว่าตัวเลขความเร็วสี่ตัว เพราะชี้ไปที่ปัญหาของเส้นทางหรือนโยบาย ไม่ใช่ความจุ รันแต่ละกรณีอย่างน้อยสองครั้ง ตัวอย่างที่ช้าตัวอย่างเดียวไม่พิสูจน์อะไรบนเครือข่ายที่ใช้ร่วมกัน
สุดท้าย เก็บตัวเลขที่คุณรวบรวมไว้พร้อมกับข้ออ้างที่มันสนับสนุน "ปลายทางนี้ทำการถ่ายโอนเสร็จในช่วงเดียวกับที่อีกปลายทางติดขัด" เป็นสิ่งที่ป้องกันได้ ในขณะที่ "ปลายทางนี้เร็วกว่า" เชิญชวนให้ถกเถียงซึ่งชนะไม่ได้ด้วยคะแนนจากหน้าแรก คู่มือ OpenVPN 2.6 อธิบายไฟล์สถานะและตัวเลือกการจัดรูปไว้ หากคุณต้องการคำสั่งที่แม่นยำสำหรับฝั่งโฮสต์