VPN เกตเวย์ของคุณติด CPU อยู่หรือไม่? อ่านภาระต่อคอร์ก่อน
ค่าเฉลี่ยซ่อนเธรดที่สำคัญ อ่านภาระต่อคอร์เทียบกับการถ่ายโอนที่ควบคุมได้ ตัดเส้นทางออก แล้วเปลี่ยนการตั้งค่าที่มีเอกสารกำกับหนึ่งอย่างต่อการรัน
ตัดสินว่าคุณติดขีดจำกัดใดในสามข้อก่อนซื้ออินสแตนซ์ที่ใหญ่ขึ้น คอร์เดียวเต็มขณะที่คอร์อื่นว่างบ่งชี้งานเข้ารหัสต่อโฟลว์ ทุกคอร์อิ่มตัวระหว่างการถ่ายโอนบ่งชี้ความจุรวม CPU ต่ำแต่จำนวนการส่งซ้ำเพิ่มขึ้นบ่งชี้เส้นทาง แต่ละข้อมีก้าวแรกต่างกัน และมีเพียงข้อเดียวที่แก้ได้ด้วยอินสแตนซ์ที่ใหญ่ขึ้น
สามขีดจำกัด ตารางเดียว สามวิธีแก้
| Limit | Reading during a transfer | First move |
|---|---|---|
| Single thread | one core near 100%, siblings idle | spread flows across workers |
| Aggregate CPU | every core busy, load average climbs | capacity, or less work per byte |
| Path or provider | low CPU, retransmits or steal time high | MTU, loss, host contention |
อ่านแถวเป็นการวินิจฉัย ไม่ใช่ขั้นตอน เธรดเดียวที่ 100% ขณะที่ตัวอื่นว่างเป็นผลลัพธ์ที่พบบ่อยที่สุดบนเกตเวย์ที่แบกอุโมงค์ใหญ่หนึ่งเส้น เพราะการเข้ารหัสของโฟลว์นั้นทำงานบนคอร์เดียว ทุกคอร์ไม่ว่างระหว่างการถ่ายโอนหมายถึงเครื่องทำงานเต็มที่แล้ว CPU ต่ำแต่การส่งซ้ำเพิ่มขึ้นหมายถึงโปรเซสเซอร์กำลังรอเครือข่ายที่ปล่อยข้อมูลหายตลอด
แก้ตามลำดับหลักฐานนั้น การกระจายโฟลว์ไปยังเวิร์กเกอร์ช่วยกรณีแรกและไม่ช่วยกรณีที่สอง อินสแตนซ์ที่ใหญ่ขึ้นช่วยกรณีที่สองและเสียเงินเปล่ากับกรณีแรก การแก้ MTU หรือการสูญหายเป็นวิธีเดียวที่แตะกรณีที่สาม ซื้อความจุก่อนรู้ว่าคุณอยู่แถวไหน คือเวอร์ชันแพงของการเดา
แยกเธรดที่ถูกปักไว้ออกจากโฮสต์ที่ยุ่ง
เริ่มจากการใช้งานต่อคอร์ เพื่อให้คอร์ที่ถูกปักไว้ซ่อนในค่าเฉลี่ยไม่ได้ การรันครั้งเดียวระหว่างการถ่ายโอนแสดงว่าภาระเรียบหรือเป็นยอด ทั้งสองรูปแบบให้ข้อมูล และโปรไฟล์ที่เป็นยอดมักหมายถึงหน้าต่างสุ่มจับกิจกรรมของตัวจัดตารางแทนการเข้ารหัส
mpstat -P ALL 1 5ระบุคอร์ที่ยุ่งให้กับโปรเซส แล้วจึงระบุเธรด การรันติดตามด้านล่างเก็บเธรดพ่อและลูกไว้ด้วยกัน ซึ่งสำคัญเมื่อดีมอนแยกโปรเซสต่อการเชื่อมต่อ:
pidstat -u -t -p $(pgrep -f 'openvpn|wireguard|ipsec') 1 10การเข้ารหัสในเคอร์เนลไม่เคยปรากฏในตัวนับโปรเซสพื้นที่ผู้ใช้ สุ่มตัวอย่างเธรดแยกกันและเทียบภาพนั้นกับการบัญชีของโปรเซส:
top -H -b -n 1 | head -20อ่านตัวนับซ็อกเก็ตเป็นอย่างสุดท้าย เพราะมันตัดสินว่าการเพิ่ม CPU จะช่วยได้หรือไม่ การส่งซ้ำเพิ่มขึ้นขณะ CPU เรียบไม่ใช่ปัญหาโปรเซสเซอร์ ปล่อยการถ่ายโอนให้ทำงานขณะสุ่ม มิฉะนั้นตัวเลขจะอธิบายเครื่องที่ว่างอยู่:
ss -ti | grep -E 'retrans|cwnd|rtt'การถ่ายโอนที่ควบคุมได้ ทำสองครั้ง
ตัวนับที่ว่างไม่พิสูจน์อะไร และการวัดเทียบจุดปลายแบบสุ่มพิสูจน์ได้น้อยมาก เลือกไคลเอนต์หนึ่ง เครื่องหมายปลายทางหนึ่ง และการถ่ายโอนตัวแทนหนึ่งที่ได้รับอนุญาตให้รัน แล้วบันทึกปริมาณงานและความหน่วงเชิงโต้ตอบในช่วงเดียวกัน เกตเวย์อิ่มตัวได้ขณะที่การคัดลอกจำนวนมากยังไม่เสร็จ และเส้นความหน่วงคือสิ่งที่ผู้ใช้รู้สึกจริง เขียนการถ่ายโอน จำนวนไคลเอนต์ และเวอร์ชันดีมอนไว้ข้างตัวเลข
ทำซ้ำด้วยโฟลว์ขนานหลายเส้น การขยายตามโฟลว์บ่งชี้หน้าต่างต่อโฟลว์ การคงที่ด้วยคอร์เดียวที่ถูกปักไว้บ่งชี้การประมวลผล
จากนั้นทำซ้ำอีกครั้งโดยหยุดภาระงานเสริม งานสำรอง ตัวส่งบันทึก หรือฐานข้อมูลบนโฮสต์เดียวกันอาจสร้างค่าเฉลี่ยที่ยุ่งซึ่งไม่เกี่ยวกับอุโมงค์เลย ถ้า CPU ยังถูกปักไว้ขณะโฮสต์เงียบด้านอื่น หลักฐานชี้ไปที่โปรเซส VPN ถ้ามันลดลง คุณกำลังวัดเพื่อนบ้าน และเกตเวย์ไม่เคยเป็นปัญหา
ตัดเส้นทางออกก่อนซื้อฮาร์ดแวร์
การส่งซ้ำเพิ่มขึ้น หน้าต่างความแออัดที่หดลง และเวลาวนกลับที่เพิ่มขึ้นล้วนชี้ห่างจากโปรเซสเซอร์ เปรียบ MTU ของอุโมงค์กับ MTU ของเส้นทาง ตรวจลิงก์พื้นฐานว่ามีการสูญหาย และยืนยันว่าอัปลิงก์ของไคลเอนต์ไม่ใช่ขีดจำกัด เกตเวย์ที่ใหญ่ขึ้นไม่ซ่อมลิงก์ที่ทำแพ็กเก็ตหาย และผู้ใช้อธิบายอาการทั้งสองด้วยคำเดียวกัน ตัวนับการส่งซ้ำแยกสองอย่างนั้นได้ในไม่กี่นาที
บนเซิร์ฟเวอร์เสมือน ให้เพิ่มตัวชี้วัดของผู้ให้บริการเข้ากับของแขก เวลาที่ถูกขโมยคือวิธีที่การขายเกินปรากฏภายในแขก และการปรับแต่งใดในแขกก็เอามันออกไม่ได้ ตัวนับของแขกมองไม่เห็นโฮสต์ กราฟแขกที่สะอาดจึงไม่ใช่หลักฐานของโฮสต์ที่แข็งแรง
เปลี่ยนหนึ่งครั้ง วัดหนึ่งครั้ง
เลือกสมมติฐานที่หลักฐานสนับสนุน แล้วเปลี่ยนการตั้งค่าที่รองรับเพียงหนึ่งอย่าง: จำนวนเวิร์กเกอร์ ตัวเลือกออฟโหลดที่มีเอกสารกำกับ หรือขนาดอินสแตนซ์ OpenVPN เผยแพร่คู่มือแก้ปัญหาประสิทธิภาพเกี่ยวกับการแบ่งระหว่างการประมวลผลกับการขนส่งแบบเดียวกัน: การแก้ปัญหาประสิทธิภาพของ OpenVPN.
ยืนยันว่าตัวเลือกออฟโหลดทำงานจริงแทนที่จะเชื่อธง แล้วรันการถ่ายโอนเดิมซ้ำและเทียบสิ่งที่เทียบได้ นี่เป็นวิธีเดียวที่จะแยกการปรับปรุงจริงจากบ่ายที่เงียบสงบ เก็บจุดตรวจที่กู้คืนได้ เพราะการเปลี่ยนครั้งที่สองคือจุดที่ผู้คนตามไม่ทันว่าอะไรช่วย หนึ่งตัวแปรต่อการรันช้าหนึ่งวันและเร็วจริงหนึ่งเดือน
อย่าอ่อนการยืนยันตัวตนหรือชุดรหัสลับเพื่อให้กราฟดูดีขึ้น ถ้า CPU ยังไม่ตามอาการ ให้กลับไปตรวจเส้นทางและแอปพลิเคชันแทนการอัปเกรดจากความคาดเดา