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.
sumber
Jawaban:
Masalah ini tampaknya diperbaiki di ESXi 5. Saya telah menguji build 469512 dengan sukses.
sumber
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:
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.
sumber
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.
sumber
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.
sumber
Bagaimana tampilan DNS Anda? Apakah kamu
/etc/resolv.conf
benar Batas waktu default adalah 5 detik.Dari
man resolv.conf
Coba tambahkan
timeout:3
ke Anda/etc/resolv.conf
dan jalankan tes fsync Anda lagi.sumber
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/
sumber
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.
sumber