Cara memecahkan masalah latensi antara 2 host linux

Latency antara 2 host linux adalah sekitar .23ms. Mereka terhubung dengan satu saklar. Ping & Wireshark mengkonfirmasi nomor latensi. Tapi, saya tidak memiliki visibilitas apa yang menyebabkan latensi ini. Bagaimana saya bisa tahu jika latensi disebabkan oleh NIC pada host A atau B atau saklar atau kabel?

UPDATE: .23 ms latency buruk untuk aplikasi saya yang ada, yang mengirim pesan pada frekuensi yang sangat tinggi dan saya mencoba untuk melihat apakah itu dapat dibawa ke .1ms

— Jimm
sumber

Menurut Anda, mengapa .23ms adalah latensi buruk? Itu latensi yang luar biasa.

— SpacemanSpiff

Hubungkan mereka secara langsung dengan kabel crossover. Jika Anda memiliki latensi yang sama maka penyebabnya adalah salah satu host. Jika Anda tidak memiliki latensi yang sama maka penyebabnya adalah sakelar atau kabel.

— joeqwerty

Setuju, apa masalahnya? 0.23ms latensi kurang dari yang saya dapatkan dengan dua mesin duduk bersebelahan.

— Michael Hampton

@ joeqwerty Jika dua sistem terhubung melalui kabel crossover, bagaimana mereka menemukan satu sama lain? Apakah ARP masih berfungsi? Apakah TCP masih berfungsi?

— Jimm

Mereka akan bekerja sama seperti jika keduanya terhubung ke saklar yang sama. Kabel hanyalah media fisik di mana mereka akan berkomunikasi. Semua 7 lapisan model OSI (atau 4 lapisan model DARPA, jika Anda mau) akan bekerja persis seperti yang mereka lakukan sekarang.

— joeqwerty

Secara umum, Anda dapat menggunakan beberapa sakelar lanjutan ke utilitas iperf untuk mendapatkan tampilan kinerja jaringan antar sistem, khususnya latensi dan jitter ...

Apakah ini aliran pesan berbasis UDP atau TCP?

Saya berkomentar di atas karena memerlukan informasi lebih lanjut tentang pengaturan Anda. Jika ini adalah aplikasi olahpesan latensi rendah, ada seluruh dunia teknik tuning dan optimisasi yang menjangkau peranti keras, driver, dan tweaker OS. Tapi sungguh, kami membutuhkan informasi lebih lanjut.

Edit:

Oke, jadi ini adalah perpesanan TCP. Sudahkah Anda mengubah /etc/sysctl.confparameter apa pun ? Seperti apa bentuk pengiriman / penerimaan buffer Anda? Menggunakan kernel realtime saja tidak akan banyak membantu, tetapi jika Anda pindah ke titik di mana Anda mengikat interupsi ke CPU, mengubah prioritas waktu nyata dari aplikasi perpesanan ( chrt) dan mungkin memodifikasi tuned-admprofil sistem dapat membantu ...

Ini kedengarannya seperti sistem EL6 umum, jadi cara mudah untuk menetapkan garis dasar penyetelan kinerja melibatkan mengubah profil kinerja sistem ke yang lain yang tersedia dalam kerangka kerja yang disetel . Kemudian bangun dari sana.

Dalam kasus Anda:

yum install tuned tuned-utils
tuned-adm profile latency-performance

Matriks cepat yang menunjukkan perbedaan:

Bisakah Anda memberi tahu kami tentang perangkat kerasnya? Jenis-jenis CPU, NIC, memori?

Jadi, mungkin menarik untuk menguji tautan Anda ... Coba uji iperf ini ...

Pada satu sistem, mulai pendengar UDP iperf. Di sisi lain, buka koneksi ke yang pertama ... Tes kualitas saluran cepat.

# Server2
[root@server2 ~]# iperf -su   

# Server1
[root@server1 ~]# iperf -t 60 -u -c server2

Dalam kasus saya, jitter rendah dan waktu ping rendah:

------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size:  224 KByte (default)
------------------------------------------------------------
[  3] local 192.168.15.3 port 5001 connected with 172.16.2.152 port 36312
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0-20.0 sec  2.50 MBytes  1.05 Mbits/sec   0.012 ms    0/ 1785 (0%)

PING server1 (172.16.2.152) 56(84) bytes of data.
64 bytes from server1 (172.16.2.152): icmp_seq=1 ttl=63 time=0.158 ms
64 bytes from server1 (172.16.2.152): icmp_seq=2 ttl=63 time=0.144 ms

Saya akan memeriksa perangkat keras dan antarmuka untuk kesalahan. Jika Anda mau, hilangkan sakelar antar sistem dan lihat seperti apa koneksi langsung itu. Anda tidak ingin jitter tinggi (varian), jadi periksa itu.

Tetapi jujur, bahkan dengan waktu ping yang Anda dapatkan pada pengaturan saat ini, itu tidak cukup untuk mematikan aplikasi Anda. Saya akan menyusuri jalur penyetelan / penerimaan buffer Anda. Lihat: net.core.rmem_max, net.core.wmem_maxdan default mereka ...

Sesuatu seperti yang berikut ini di /etc/sysctl.conf(harap sesuaikan selera):

net.core.rmem_default = 10000000
net.core.wmem_default = 10000000
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

— putih
sumber

Ini adalah aplikasi perpesanan yang sensitif terhadap latensi. OS umumnya adalah kernel-2.6.32-279.11.1.el6.x86_64, meskipun saya memuat host dengan kernel 3.2.23-rt37.56.el6rt.x86_64 untuk melihat apakah itu akan membuat perbedaan. Tapi itu hampir sama. Ukuran pesan bervariasi antara 1KB - 3KB. Semua komunikasi terjadi melalui TCP.

— Jimm

Apakah OS Red Hat MRG?

— ewwhite

Sekarang ini Redhat 6.3, tapi MRG juga kemungkinan. Seperti yang saya sebutkan di atas, saya mencoba keduanya, tetapi latensi sama. Jenis musik apa yang harus saya perhatikan?

— Jimm

Saya ingin tahu pengaturan perangkat keras dan NIC. Switch model membantu. Untuk merdu, area yang jelas untuk dilihat pada 6.3 adalah tuned-admprofil Anda .

— ewwhite

Pengontrol Ethernet Ganda: Emulex Corporation OneConnect 10Gb NIC (rev 02) dan 16 inti AMD Family 10h Processor, masing-masing 2.400 MHz.

— Jimm