Memecahkan masalah lonjakan latensi pada ESXi NFS datastores

44

Saya mengalami latensi fsync sekitar lima detik pada datastore NFS di ESXi, yang dipicu oleh VM tertentu. Saya menduga ini mungkin disebabkan oleh VM menggunakan NCQ / TCQ, karena ini tidak terjadi dengan drive IDE virtual.

Ini dapat direproduksi menggunakan fsync-tester (oleh Ted Ts'o) dan ioping . Misalnya menggunakan sistem hidup Grml dengan disk 8GB:

Linux 2.6.33-grml64:
root@dynip211 /mnt/sda # ./fsync-tester
fsync time: 5.0391
fsync time: 5.0438
fsync time: 5.0300
fsync time: 0.0231
fsync time: 0.0243
fsync time: 5.0382
fsync time: 5.0400
[... goes on like this ...]

Itu 5 detik, bukan milidetik. Ini bahkan membuat IO-latency pada VM berbeda yang berjalan di host dan datastore yang sama :

root@grml /mnt/sda/ioping-0.5 # ./ioping -i 0.3 -p 20 .
4096 bytes from . (reiserfs /dev/sda): request=1 time=7.2 ms
4096 bytes from . (reiserfs /dev/sda): request=2 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=3 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=4 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=5 time=4809.0 ms
4096 bytes from . (reiserfs /dev/sda): request=6 time=1.0 ms
4096 bytes from . (reiserfs /dev/sda): request=7 time=1.2 ms
4096 bytes from . (reiserfs /dev/sda): request=8 time=1.1 ms
4096 bytes from . (reiserfs /dev/sda): request=9 time=1.3 ms
4096 bytes from . (reiserfs /dev/sda): request=10 time=1.2 ms
4096 bytes from . (reiserfs /dev/sda): request=11 time=1.0 ms
4096 bytes from . (reiserfs /dev/sda): request=12 time=4950.0 ms

Ketika saya memindahkan VM pertama ke penyimpanan lokal, itu terlihat sangat normal:

root@dynip211 /mnt/sda # ./fsync-tester
fsync time: 0.0191
fsync time: 0.0201
fsync time: 0.0203
fsync time: 0.0206
fsync time: 0.0192
fsync time: 0.0231
fsync time: 0.0201
[... tried that for one hour: no spike ...]

Hal yang saya coba yang tidak membuat perbedaan:

  • Menguji beberapa ESXi Builds: 381591, 348481, 260247
  • Diuji pada perangkat keras yang berbeda, kotak Intel dan AMD yang berbeda
  • Diuji dengan server NFS yang berbeda, semua menunjukkan perilaku yang sama:
    • OpenIndiana b147 (Sinkronisasi ZFS selalu atau dinonaktifkan: tidak ada perbedaan)
    • OpenIndiana b148 (Sinkronisasi ZFS selalu atau dinonaktifkan: tidak ada perbedaan)
    • Linux 2.6.32 (sinkronisasi atau async: tidak ada perbedaan)
    • Tidak ada bedanya jika server NFS berada di mesin yang sama (sebagai alat penyimpanan virtual) atau pada host yang berbeda

OS Guest diuji, menunjukkan masalah:

  • Windows 7 64 Bit (menggunakan CrystalDiskMark, lonjakan latensi kebanyakan terjadi selama fase persiapan)
  • Linux 2.6.32 (fsync-tester + ioping)
  • Linux 2.6.38 (fsync-tester + ioping)

Saya tidak bisa mereproduksi masalah ini di Linux 2.6.18 VM.

Solusi lain adalah dengan menggunakan disk IDE virtual (vs SCSI / SAS), tetapi itu membatasi kinerja dan jumlah drive per VM.

Pembaruan 2011-06-30:

Paku latensi tampaknya lebih sering terjadi jika aplikasi menulis dalam beberapa blok kecil sebelum fsync. Misalnya fsync-tester melakukan ini (strace output):

pwrite(3, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 1048576, 0) = 1048576
fsync(3)                                = 0

ioping melakukan ini saat menyiapkan file:

[lots of pwrites]
pwrite(3, "********************************"..., 4096, 1036288) = 4096
pwrite(3, "********************************"..., 4096, 1040384) = 4096
pwrite(3, "********************************"..., 4096, 1044480) = 4096
fsync(3)                                = 0

Fase pengaturan ioping hampir selalu hang, sementara fsync-tester terkadang bekerja dengan baik. Apakah seseorang mampu memperbarui fsync-tester untuk menulis beberapa blok kecil? Keterampilan C saya menghisap;)

Pembaruan 2011-07-02:

Masalah ini tidak terjadi pada iSCSI. Saya mencoba ini dengan server OpenIndiana COMSTAR iSCSI. Tetapi iSCSI tidak memberi Anda akses mudah ke file VMDK sehingga Anda dapat memindahkannya di antara host dengan snapshots dan rsync.

Perbarui 2011-07-06:

Ini adalah bagian dari penangkapan wireshark, ditangkap oleh VM ketiga pada vSwitch yang sama. Ini semua terjadi pada host yang sama, tidak ada jaringan fisik yang terlibat.

Saya sudah mulai ioping sekitar waktu 20. Tidak ada paket yang dikirim sampai penundaan lima detik selesai:

No.  Time        Source                Destination           Protocol Info
1082 16.164096   192.168.250.10        192.168.250.20        NFS      V3 WRITE Call (Reply In 1085), FH:0x3eb56466 Offset:0 Len:84 FILE_SYNC
1083 16.164112   192.168.250.10        192.168.250.20        NFS      V3 WRITE Call (Reply In 1086), FH:0x3eb56f66 Offset:0 Len:84 FILE_SYNC
1084 16.166060   192.168.250.20        192.168.250.10        TCP      nfs > iclcnet-locate [ACK] Seq=445 Ack=1057 Win=32806 Len=0 TSV=432016 TSER=769110
1085 16.167678   192.168.250.20        192.168.250.10        NFS      V3 WRITE Reply (Call In 1082) Len:84 FILE_SYNC
1086 16.168280   192.168.250.20        192.168.250.10        NFS      V3 WRITE Reply (Call In 1083) Len:84 FILE_SYNC
1087 16.168417   192.168.250.10        192.168.250.20        TCP      iclcnet-locate > nfs [ACK] Seq=1057 Ack=773 Win=4163 Len=0 TSV=769110 TSER=432016
1088 23.163028   192.168.250.10        192.168.250.20        NFS      V3 GETATTR Call (Reply In 1089), FH:0x0bb04963
1089 23.164541   192.168.250.20        192.168.250.10        NFS      V3 GETATTR Reply (Call In 1088)  Directory mode:0777 uid:0 gid:0
1090 23.274252   192.168.250.10        192.168.250.20        TCP      iclcnet-locate > nfs [ACK] Seq=1185 Ack=889 Win=4163 Len=0 TSV=769821 TSER=432716
1091 24.924188   192.168.250.10        192.168.250.20        RPC      Continuation
1092 24.924210   192.168.250.10        192.168.250.20        RPC      Continuation
1093 24.924216   192.168.250.10        192.168.250.20        RPC      Continuation
1094 24.924225   192.168.250.10        192.168.250.20        RPC      Continuation
1095 24.924555   192.168.250.20        192.168.250.10        TCP      nfs > iclcnet_svinfo [ACK] Seq=6893 Ack=1118613 Win=32625 Len=0 TSV=432892 TSER=769986
1096 24.924626   192.168.250.10        192.168.250.20        RPC      Continuation
1097 24.924635   192.168.250.10        192.168.250.20        RPC      Continuation
1098 24.924643   192.168.250.10        192.168.250.20        RPC      Continuation
1099 24.924649   192.168.250.10        192.168.250.20        RPC      Continuation
1100 24.924653   192.168.250.10        192.168.250.20        RPC      Continuation

Pembaruan ke-2 2011-07-06:

Tampaknya ada beberapa pengaruh dari ukuran jendela TCP. Saya tidak dapat mereproduksi masalah ini menggunakan FreeNAS (berdasarkan FreeBSD) sebagai server NFS. Penangkapan wireshark menunjukkan pembaruan jendela TCP ke 29127 byte secara berkala. Saya tidak melihat mereka dengan OpenIndiana, yang menggunakan ukuran jendela lebih besar secara default.

Saya tidak lagi dapat mereproduksi masalah ini jika saya mengatur opsi berikut di OpenIndiana dan me-restart server NFS:

ndd -set /dev/tcp tcp_recv_hiwat 8192 # default is 128000
ndd -set /dev/tcp tcp_max_buf 1048575 # default is 1048576

Tapi ini membunuh kinerja: Menulis dari / dev / zero ke file dengan dd_rescue berjalan dari 170MB / s ke 80MB / s.

Perbarui 2011-07-07:

Saya sudah mengunggah tangkapan tcpdump ini (dapat dianalisis dengan wireshark). Dalam hal ini 192.168.250.2 adalah server NFS (OpenIndiana b148) dan 192.168.250.10 adalah host ESXi.

Hal yang saya uji selama penangkapan ini:

Mulai "ioping -w 5 -i 0.2." pada waktu 30, 5 detik menunggu dalam pengaturan, selesai pada waktu 40.

Mulai "ioping -w 5 -i 0.2." pada waktu 60, 5 detik bertahan dalam pengaturan, selesai pada waktu 70.

Mulai "fsync-tester" pada waktu 90, dengan output berikut, berhenti pada waktu 120:

fsync time: 0.0248
fsync time: 5.0197
fsync time: 5.0287
fsync time: 5.0242
fsync time: 5.0225
fsync time: 0.0209

Pembaruan ke-2 2011-07-07:

Diuji server VM NFS lain, kali ini edisi komunitas NexentaStor 3.0.5: Menunjukkan masalah yang sama.

Pembaruan 2011-07-31:

Saya juga dapat mereproduksi masalah ini pada ESXi build 4.1.0.433742 yang baru.

vmware-esxi  nfs  latency 
— exo_cw
sumber
12
Saya harus mengatakan itu sudah lama sejak pengguna baru telah datang ke papan dengan pertanyaan yang didokumentasikan dengan baik dan dipikirkan - serius, topi untuk Anda. Ini benar-benar menarik juga, saya belum pernah menemukan fsync-tester sebelumnya, jadi terima kasih. Yang mengatakan saya tidak yakin saya punya sesuatu untuk ditambahkan, Anda sudah mencoba banyak hal yang sudah saya miliki - saya akan mengatakan berbicara dengan VMWare sendiri jujur, mereka sangat pandai mengambil jenis ini hal-hal 'ekor panjang' / 'bukan pemadaman layanan yang sebenarnya' dengan serius. Pokoknya hanya ingin mengatakan dilakukan dengan baik pada apa yang telah Anda lakukan sejauh ini :)
— Chopper3
Sayangnya situs web VMware tidak akan membiarkan saya menghubungi mereka: "Anda saat ini tidak memiliki hak dukungan aktif"
— exo_cw
ah, ya, itu bisa menjadi masalah tentu saja ...
— Chopper3
3
Waktu tunggu 5 detik dengan NFS terdengar familier. Di linux NFS ada 0,7 detik timeout untuk RPC yang berlipat ganda setelah setiap kegagalan dan menarik utama setelah 3 gagal (pengaturan default). .7 + 1.4 + 2.8 = 4.9 detik. Ada berbagai masalah otentikasi RPC yang dapat menyebabkan hal ini.
— Markus
2
@Ryan: Saya sudah mengunggah file tangkap. Saya juga mengunggah output nfsstat .
— exo_cw

Jawaban:

5

Masalah ini tampaknya diperbaiki di ESXi 5. Saya telah menguji build 469512 dengan sukses.

— exo_cw
sumber
3

Terima kasih, nfsstat terlihat bagus. Saya telah meninjau tangkapannya. Belum menemukan sesuatu yang meyakinkan, tetapi menemukan sesuatu yang menarik. Saya memfilter pada tcp.time_delta> 5. Apa yang saya temukan di setiap instance delay adalah awal pasti dari panggilan RPC. Tidak semua panggilan RPC baru lambat, tetapi semua perlambatan terjadi tepat pada awal panggilan RPC. Juga, dari tangkapan tampak bahwa 192.168.250.10 berisi semua penundaan. 192.168.250.2 segera menanggapi semua permintaan.

Temuan:

  • Penundaan selalu terjadi pada paket pertama panggilan RPC
  • Jenis-jenis perintah NFS tidak berkorelasi dengan menunda instance
  • Fragmentasi = hanya menunda paket pertama

Panggilan Panggilan besar dapat dibagi menjadi 300 paket TCP individu, dan hanya yang pertama yang ditunda, tetapi sisanya semua terbang. Tidak pernah terjadi penundaan di tengah. Saya tidak yakin bagaimana ukuran jendela dapat mempengaruhi permulaan koneksi secara drastis.

Langkah selanjutnya: Saya akan mulai mengubah opsi NFS seperti NFSSVC_MAXBLKSIZE ke bawah daripada jendela TCP. Juga, saya perhatikan bahwa 2.6.18 bekerja sementara 2.6.38 tidak. Saya tahu bahwa dukungan telah ditambahkan untuk driver VMXnet3 selama jangka waktu itu. Driver NIC apa yang Anda gunakan pada host? TCP offloading ya / tidak? Sekitar tanda 95 detik ada lebih dari 500 paket TCP untuk satu panggilan NFS Write. Apa pun yang bertanggung jawab atas TCP dan memecah PDU besar bisa menjadi apa yang menghalangi.

— Ryan
sumber
Saya mencoba mengatur nfs: nfs3_max_transfer_size, nfs: nfs3_max_transfer_size_cots dan nfs: nfs3_bsize semuanya hingga 8192: Tidak ada perbedaan, masalah yang sama. Para tamu linux hanya menggunakan disk SCSI / SAS, tanpa NFS - ESXi adalah klien NFS, oleh karena itu tidak ada masalah driver jaringan pada tamu linux. Di sisi server NFS saya sudah mencoba virtual e1000 dan vmxnet3: Tidak ada bedanya. Sejauh yang saya tahu ESXi hanya menggunakan TCP offloading untuk iSCSI.
— exo_cw
Yang terbesar ? Yang saya miliki adalah mengapa menyesuaikan jendela TCP akan membuat perbedaan ... usus saya mengatakan itu ada hubungannya dengan memecah-mecah PDU besar itu melalui TCP. Sesuatu di tumpukan jaringan yang mencekiknya. Hanya tidak bisa memikirkan apa pun yang sesuai dengan perilaku yang kita lihat. Jika ukuran jendela adalah masalah, kita harus melihat latency membatasi bandwidth di tengah transfer besar, bukan awal, tapi itu selalu paket pertama panggilan RPC ... sulit.
— Ryan
2

Saya memiliki apa yang tampak seperti masalah yang sama menggunakan ESXi4.1U1 dan CentOS VM. Host adalah Dell R610s, penyimpanan adalah sebuah cluster Isilon EMC2.

Apakah Anda kebetulan menggunakan VLANS? Saya menemukan menggunakan VLAN pada port VMkernel untuk penyimpanan menyebabkan 4000-5000ms 'hang' untuk semua lalu lintas penyimpanan pada VMHost. Namun jika saya memindahkan port VMkernel dari VLAN sehingga menerima paket yang tidak ditandai saya tidak melihat masalah.

Pengaturan sederhana di bawah ini akan menyebabkan masalah pada jaringan saya:

1) Instal ESXi 4.1U1 di server atau workstation (keduanya menunjukkan masalah ketika saya mencoba)

2) Tambahkan port VMkernel pada VLAN.

3) Tambahkan NFS Datastore (milik saya pada VLAN yang sama, yaitu Isilon menerima paket yang ditandai)

4) Instal 2 CentOS 5.5 VM, satu dengan ioping.

5) Boot VM ke mode pengguna tunggal (yaitu tidak ada jaringan, layanan minimum)

6) Jalankan ioping pada satu mesin sehingga ia menulis ke disk virtualnya

7) Jalankan dd atau semacamnya di komputer lain untuk menulis 100MB data ke / tmp atau serupa

Lebih sering daripada tidak saya melihat kedua VM membeku selama 4-5 detik.

Sangat tertarik untuk melihat apakah ada orang lain yang melihat hal serupa.

— Nick
sumber
Selamat Datang di Kesalahan Server! Ini pertanyaan lama. Jika jawaban itu tidak membantu Anda secara langsung, maka Anda harus mengajukan pertanyaan BARU dengan mengklik tombol Ajukan Pertanyaan .
— user9517 mendukung GoFundMonica
Ya, tentu saja saya menggunakan VLAN yang ditandai. Ketika saya menggunakannya di mana-mana, saya bahkan tidak menganggapnya sebagai sumber potensial masalah ini. Saya akan mencoba mereproduksi ini pada port yang tidak ditandai.
— exo_cw
Saya dapat mereproduksi masalah ini pada port yang tidak ditandai juga, tidak ada VLAN yang terlibat pada host itu sama sekali.
— exo_cw
Saya hanya mencoba lagi dan melihat masalah pada port yang tidak ditandai juga, ini sedikit lebih jarang, mungkin itu sebabnya saya melewatkannya. Maaf untuk gelandangan. Saya tidak dapat melihat masalah pada Win7 64 bit menggunakan iometer, ditambah lagi tampaknya saya dapat menelusuri drive c: sementara vms linux lainnya digantung. Saya akan mencoba dengan crystaldiskmark
— Nick
Sebenarnya saya akan tertarik untuk melihat hasil Anda dengan iometer di win7 x64. Mengukur latensi tetapi angka keseluruhan tertinggi yang saya dapatkan adalah 300ms menggunakan tes baca 4k, bukan 4000 + ms
— Nick
2

Kami memiliki masalah yang sama persis dua minggu lalu. ESX41 U1 dan Netapp FAS3170 + NFS Datastores. RHEL5 VM hang selama 2 atau 4 detik dan kami melihat lonjakan yang sangat tinggi dari konsol kinerja Virtual Center.

Saya meminta orang jaringan untuk memeriksa konfigurasi dan masalahnya ada di cisco switch. Kami memiliki dua tautan ethernet yang dikonfigurasi pada Etherchannel di sisi Netapp dan bukan di sisi cisco. Dia menciptakan Ethechannel statis pada cisco dan sekarang berfungsi dengan baik. Untuk mengidentifikasi masalah semacam ini, matikan semua port kecuali satu antara filer dan switch. Biarkan satu port tetap hidup dan lihat bagaimana keadaannya.

Hal kedua yang kami lakukan adalah menghapus Flow Control pada switcj dan filer karena kami curiga itu mengirim bingkai jeda.

— Laurent
sumber
1

Bagaimana tampilan DNS Anda? Apakah kamu /etc/resolv.confbenar Batas waktu default adalah 5 detik.

Dari man resolv.conf

timeout:n
                 sets the amount of time the  resolver  will  wait  for  a
                 response  from  a  remote name server before retrying the
                 query via a different name server.  Measured in  seconds,
                 the default is RES_TIMEOUT (currently 5, see <resolv.h>).

Coba tambahkan timeout:3ke Anda /etc/resolv.confdan jalankan tes fsync Anda lagi.

— Joseph Kern
sumber
Saya mencoba menambahkan ini di server NFS (OpenIndiana dalam kasus ini) dan pada host ESXi. Sayangnya ini tidak membuat perbedaan. Saya dapat menyelesaikan server & IP tamu dengan baik.
— exo_cw
sepertinya Anda memfilter semua lalu lintas yang tidak terkait dengan aliran nfs, kami mungkin perlu melihat lebih banyak!
— tony roth
@tony roth: Sebenarnya itu adalah seluruh lalu lintas pada waktu itu. Saya mengujinya pada vSwitch yang terpisah hanya dengan host dan NFS-server di atasnya.
— exo_cw
Bisakah Anda membuang DNS dengan wireshark?
— Joseph Kern
@ Joseph Kern: Saya baru saja menganalisis file tangkap lagi: Tidak ada lalu lintas DNS sama sekali selama penangkapan saya. Datastore NFS dipetakan oleh IP pada host ESXi. DNS berfungsi dengan baik pada ESXi dan server NFS, saya menguji maju & mundur pencarian semua IP yang terlibat. Saat ini saya tidak punya alasan untuk percaya bahwa DNS adalah penyebabnya.
— exo_cw
1

Menggenggam sedotan di sini, tetapi NIC apa yang Anda gunakan di server ini? Sysadmin Stack Overflow memiliki masalah jaringan yang aneh dengan Broadcom NIC yang hilang ketika mereka beralih ke Intel NIC: http://blog.serverfault.com/post/broadcom-die-mutha/

— bergairah
sumber
Tes terakhir dilakukan pada vSwitch saja, tidak ada jaringan fisik yang terlibat (e1000 dan vmxnet3: tidak ada bedanya). Tetapi saya juga telah menguji ini pada Intel 82574L, Intel 82576 dan Intel 82567LF-3, semuanya menunjukkan masalah. Saya belum menemukan perangkat keras di mana saya tidak dapat mereproduksi ini.
— exo_cw
1

Ini adalah tebakan lain ... Apakah IPv6 Anda diaktifkan pada host EXS? Jika ya, cobalah mematikannya? Dari pengalaman saya jika seluruh jaringan Anda tidak dikonfigurasi dengan benar untuk IPv6 (yaitu RADV, DHCP6, DNS, reverse DNS) mungkin ada masalah untuk beberapa layanan. Juga, pastikan itu tidak aktif di server NFS.

— dtoubelis
sumber
IPv6 sudah dinonaktifkan pada host ESXi. Saya telah menonaktifkan IPv6 pada server NFS (ifconfig -a6 kosong sekarang), tetapi tidak ada bedanya: Ini menunjukkan masalah yang sama.
— exo_cw
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.