Cổng VPN của bạn có bị giới hạn bởi CPU? Hãy đọc tải mỗi lõi trước
Giá trị trung bình che giấu luồng quan trọng. Đọc tải mỗi lõi khi truyền có kiểm soát, loại trừ đường truyền, rồi mỗi lần chạy chỉ đổi một cài đặt đã được ghi lại.
Hãy xác định bạn đã chạm giới hạn nào trong ba giới hạn trước khi mua một phiên bản lớn hơn. Một lõi đầy tải trong khi các lõi khác rảnh chỉ ra công việc mã hóa theo luồng. Mọi lõi bão hòa khi truyền chỉ ra tổng dung lượng. CPU thấp với số lần truyền lại tăng chỉ ra đường truyền. Mỗi trường hợp có bước đầu khác nhau, và chỉ một trường hợp được giải quyết bằng phiên bản lớn hơn.
Ba giới hạn, một bảng, ba cách sửa
| 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 |
Đọc các hàng như chẩn đoán, không phải giai đoạn. Một luồng ở 100% trong khi các luồng khác rảnh là kết quả phổ biến nhất trên cổng mang một đường hầm lớn, vì việc mã hóa luồng đó chạy trên một lõi. Mọi lõi bận khi truyền nghĩa là máy đã làm hết mức có thể. CPU thấp với số lần truyền lại tăng nghĩa là bộ xử lý đang chờ một mạng liên tục đánh rơi dữ liệu.
Sửa theo đúng thứ tự bằng chứng đó. Phân tán luồng sang các worker giúp trường hợp đầu và không làm gì cho trường hợp thứ hai. Phiên bản lớn hơn giúp trường hợp thứ hai và lãng phí tiền cho trường hợp đầu. Sửa MTU hoặc mất gói là cách duy nhất chạm tới trường hợp thứ ba. Mua dung lượng trước khi biết mình đang ở hàng nào là phiên bản đắt tiền của việc đoán.
Tách một luồng bị ghim khỏi một máy chủ bận
Bắt đầu với mức sử dụng mỗi lõi, để một lõi bị ghim không thể ẩn trong một giá trị trung bình. Một lần chạy khi truyền cho thấy tải phẳng hay có đỉnh. Cả hai dạng đều có ích, và một biểu đồ có đỉnh thường có nghĩa là cửa sổ lấy mẫu bắt được hoạt động của bộ lập lịch thay vì mã hóa.
mpstat -P ALL 1 5Gán lõi bận cho một tiến trình, rồi đến một luồng. Lần chạy theo dõi bên dưới giữ luồng cha và con lại với nhau, điều này quan trọng khi daemon tách tiến trình cho mỗi kết nối:
pidstat -u -t -p $(pgrep -f 'openvpn|wireguard|ipsec') 1 10Mã hóa trong nhân không bao giờ xuất hiện trong bộ đếm tiến trình không gian người dùng. Lấy mẫu luồng riêng và so sánh góc nhìn đó với kế toán tiến trình:
top -H -b -n 1 | head -20Đọc bộ đếm socket sau cùng, vì chúng quyết định liệu thêm CPU có giúp được gì không. Truyền lại tăng trong khi CPU phẳng không phải vấn đề của bộ xử lý. Giữ việc truyền chạy trong khi lấy mẫu, nếu không các con số sẽ mô tả một máy rảnh:
ss -ti | grep -E 'retrans|cwnd|rtt'Một lần truyền có kiểm soát, chạy hai lần
Bộ đếm rảnh không chứng minh gì, và đánh giá so với một điểm cuối ngẫu nhiên chứng minh rất ít. Chọn một máy khách, một đích và một lần truyền đại diện mà bạn được phép chạy, rồi ghi thông lượng và độ trễ tương tác trong cùng cửa sổ. Cổng có thể bão hòa trong khi một bản sao lớn còn đang hoàn tất, và đường cong độ trễ là thứ người dùng thực sự cảm nhận. Ghi lần truyền, số máy khách và phiên bản daemon bên cạnh các con số.
Lặp lại lần chạy với vài luồng song song. Tăng theo số luồng gợi ý cửa sổ theo luồng; giữ phẳng với một lõi bị ghim gợi ý xử lý.
Sau đó lặp lại một lần nữa với các tải công việc tùy chọn đã dừng. Một bản sao lưu, một bộ gửi nhật ký hoặc một cơ sở dữ liệu trên cùng máy chủ có thể tạo ra giá trị trung bình bận không liên quan gì đến đường hầm. Nếu CPU vẫn bị ghim trong khi máy chủ yên tĩnh, bằng chứng chỉ về tiến trình VPN. Nếu nó giảm, bạn đang đo hàng xóm, và cổng chưa bao giờ là vấn đề.
Loại trừ đường truyền trước khi mua phần cứng
Truyền lại tăng, cửa sổ tắc nghẽn co lại và thời gian khứ hồi tăng đều chỉ ra khỏi bộ xử lý. So sánh MTU của đường hầm với MTU của đường truyền, kiểm tra liên kết bên dưới về mất gói, và xác nhận đường lên của chính máy khách không phải giới hạn. Một cổng lớn hơn không sửa được liên kết đánh rơi gói, và người dùng mô tả cả hai lỗi bằng cùng một từ. Bộ đếm truyền lại phân biệt chúng trong vài phút.
Trên máy chủ ảo, thêm số liệu của nhà cung cấp vào số liệu của khách. Thời gian bị đánh cắp là cách việc bán quá mức trở nên hiển thị bên trong khách, và không tinh chỉnh nào bên trong khách loại bỏ được nó. Bộ đếm của khách không nhìn thấy máy chủ, nên một biểu đồ khách sạch không phải bằng chứng về máy chủ khỏe.
Một thay đổi, một phép đo
Chọn giả thuyết mà bằng chứng ủng hộ, rồi đổi đúng một cài đặt được hỗ trợ: số worker, một tùy chọn giảm tải có ghi lại hoặc kích thước phiên bản. OpenVPN công bố hướng dẫn khắc phục sự cố hiệu năng về cùng sự phân chia giữa xử lý và vận chuyển: Khắc phục sự cố hiệu năng OpenVPN.
Xác nhận tùy chọn giảm tải thực sự hoạt động thay vì tin vào cờ, rồi chạy lại đúng lần truyền đó và so sánh cái tương đương với nhau. Đó là cách duy nhất để phân biệt một cải thiện thật với một buổi chiều yên tĩnh. Giữ một điểm kiểm tra có thể khôi phục, vì ở thay đổi thứ hai người ta mất dấu cái nào đã giúp. Một biến mỗi lần chạy thì chậm trong một ngày và nhanh trong một tháng.
Không làm yếu xác thực hay bộ mật mã để biểu đồ trông đẹp hơn. Nếu CPU vẫn không theo triệu chứng, hãy quay lại kiểm tra đường truyền và ứng dụng thay vì nâng cấp dựa trên phỏng đoán.