Beban pelayan VPN dijelaskan: pengguna, CPU atau pautan naik?

Gerbang pada beban 0.4 masih boleh merangkak bagi setiap pengguna di belakangnya. Purata beban mengira tugas yang boleh dijalankan atau tersekat dalam tidur tidak boleh diganggu, dan pada hos empat teras satu proses yang tepu sudah cukup untuk menolaknya ke arah 1.0 sementara tiga teras duduk terbiar. Membaca nombor itu sebagai lebihan ialah kesilapan paling biasa dalam pemilihan titik akhir. Apa yang sebenarnya mengekang terowong biasanya salah satu daripada empat perkara: satu teras sibuk, pautan naik, baris gilir di hadapannya atau dasar setiap sesi yang tiada siapa dokumentasikan.

Purata beban mengira tugas, bukan daya pemprosesan

Kernel mengambil sampel baris gilir laksana dan bilangan tugas yang menunggu input dan output, kemudian melicinkan keduanya sepanjang satu, lima dan lima belas minit. Tiada apa dalam takrif itu menyebut bait, paket atau terowong. Hos yang storannya tersekat boleh melaporkan beban tinggi dengan hampir tiada trafik, dan hos yang menolak gigabit melalui laluan data kernel boleh melaporkan beban yang selesa.

Oleh itu, mengaitkan beban dengan prestasi terowong memerlukan pandangan setiap teras. Jika satu teras penuh, peratusan agregat pada papan pemuka masih akan kelihatan baik:

cat /proc/loadavg
mpstat -P ALL 1 1
top -H -b -n 1 | head -n 20

Perintah ketiga ialah yang paling penting pada hos VPN. Pemprosesan paket dalam ruang pengguna dalam OpenVPN 2.x sebahagian besarnya bersiri setiap proses, jadi satu utas sibuk boleh menjadi siling sementara papan pemuka melaporkan kapasiti terbiar yang banyak. Jika satu utas memegang sebahagian besar teras semasa tempoh perlahan anda, hos itu tidak kurang sumber secara keseluruhan; ia terhad pada dimensi yang kebetulan penting.

Perhatikan masanya juga. Purata lima belas minit menyembunyikan letusan yang merosakkan panggilan, jadi tangkapan skrin yang diambil selepas aduan ialah bukti lemah. Ambil sampel semasa masalah dan simpan cap masa bersama output.

Pautan naik dan baris gilir di hadapannya

Pembilang antara muka menjawab soalan lebar jalur yang tidak dapat dijawab oleh angka CPU. Ia juga memisahkan kapasiti daripada kehilangan, iaitu kegagalan berbeza dengan pembaikan berbeza:

ip -s link show dev eth0
tc -s qdisc show dev eth0
nstat -az TcpRetransSegs TcpExtTCPLostRetransmit

Pautan yang hampir dengan kadar yang diperuntukkan semasa ujian anda ialah penjelasannya, dan tiada jumlah CPU lebihan yang mengubahnya. Baris qdisc menambah perincian yang penting untuk trafik interaktif: tunggakan dan kehilangan memberitahu sama ada paket menunggu dalam baris gilir sebelum keluar. Baris gilir yang penuh di bawah muat naik besar menghasilkan gejala yang orang tuduh pada pelayan jauh, iaitu panggilan lambat pada sambungan yang masih berprestasi baik dalam penanda aras.

Pembilang penghantaran semula menangkap kes apabila paket keluar tetapi tidak pernah tiba dengan bersih. Jika penghantaran semula meningkat dalam tetingkap perlahan dan antara muka jauh daripada kapasiti, masalahnya terletak pada laluan dan bukan pada hos, dan berpindah ke titik akhir lain di bandar yang sama tidak akan membantu.

Bilangan sesi menerangkan permintaan, bukan lebihan

Setiap direktori awam menunjukkan beberapa bilangan pengguna yang disambungkan, dan hampir tiada yang memberitahu anda apa yang pengguna itu lakukan. Dua puluh sesi melakukan kerja interaktif dan empat sesi menarik fail besar menghasilkan beban yang sangat berbeza pada perkakasan yang sama. Corak kedua tidak kelihatan dalam bilangan pengguna, dan itulah yang merosakkan satu petang. Jadi nombor sesi paling baik dibaca sebagai petunjuk permintaan, tidak pernah sebagai kenyataan tentang kapasiti lebihan.

Pada hos yang anda kawal, fail status memberikan dimensi yang hilang. OpenVPN menulis petikan berkala yang merangkumi pembilang bait setiap klien, dan itu cukup untuk melihat sama ada satu sesi bertanggungjawab atas seluruh pautan naik:

status /run/openvpn/server.status 10
# then, after at least one interval
grep -E "^CLIENT_LIST" /run/openvpn/server.status

Dua sampel sepuluh saat berasingan menukar kiraan terkumpul itu kepada kadar setiap klien. Itulah ukuran yang digantikan oleh bilangan pengguna, dan begitulah juga anda menemui bahawa satu klien yang salah dikonfigurasi menepukan pautan setiap malam pada jam yang sama.

Had setiap sesi tersembunyi dalam dasar

Pelayan boleh terbiar dan masih enggan memberikan lebar jalur kepada anda. Had kadar, siling lebar jalur setiap klien dan pembentukan trafik sering digunakan mengikut nama umum atau mengikut kolam, jadi dua pengguna pada gerbang yang sama boleh mendapat keputusan yang sangat berbeza. Mekanismenya tidak halus, tetapi tidak kelihatan dari luar kerana terowong naik seperti biasa dalam kedua-dua kes.

Cari pembentukan pada antara muka terowong, bukan pada antara muka fizikal. Periksa sama ada had itu mengikut pengguna, sijil atau kolam alamat. Jika akaun ujian anda jatuh ke dalam kolam tanpa had, anda akan membuat kesimpulan bahawa pelayan itu baik dan pengguna yang mengadu itu salah. Kesimpulan itu lebih teruk daripada tiada kesimpulan, kerana ia menutup tiket.

Bandingkan dua titik akhir dengan satu tugas tetap

Eksperimen di pihak klien masih berbaloi dijalankan, tetapi hanya jika pemboleh ubah dipaku. Gunakan peranti yang sama, rangkaian akses yang sama, protokol yang sama dan fail destinasi yang sama, kemudian ulangi terhadap titik akhir kedua pada jarak yang serupa. Apa-apa yang berubah antara larian, termasuk masa dalam sehari, mencemarkan hasilnya.

Catat kegagalan dengan teliti seperti kejayaan. Satu siri di mana tiga titik akhir berfungsi dan satu tamat masa lebih bermaklumat daripada empat nombor kelajuan, kerana ia menunjuk kepada masalah laluan atau dasar dan bukan kapasiti. Jalankan setiap kes sekurang-kurangnya dua kali; satu sampel perlahan tidak membuktikan apa-apa pada rangkaian dikongsi.

Akhir sekali, simpan angka yang anda kumpulkan bersama dakwaan yang disokongnya. "Titik akhir ini menyelesaikan pemindahan dalam tetingkap yang sama apabila yang lain tersekat" boleh dipertahankan, manakala "titik akhir ini lebih pantas" mengundang perdebatan yang tidak boleh anda menangi dengan skor laman utama. Manual OpenVPN 2.6 mendokumentasikan fail status dan pilihan pembentukan jika anda memerlukan arahan tepat untuk pihak hos.