Mengapa Linux VM di vSphere ESXi 5.5 menunjukkan peningkatan latensi disk i / o secara dramatis?


8

Saya bingung dan saya berharap orang lain akan mengenali gejala dari masalah ini.

Perangkat Keras: Dell T110 II baru, dual-core Pentium G850 2,9 GHz, pengontrol SATA onboard, satu hard drive kabel baru 500 GB 7200 RPM di dalam kotak, drive lain di dalam tetapi belum terpasang. Tidak ada RAID. Perangkat lunak: mesin virtual CentOS 6.5 baru di bawah VMware ESXi 5.5.0 (build 1746018) + vSphere Client. RAM 2,5 GB dialokasikan. Disk adalah cara CentOS menawarkan untuk mengaturnya, yaitu sebagai volume di dalam Grup Volume LVM, kecuali bahwa saya melewatkan memiliki / home yang terpisah dan hanya memiliki / dan / boot. CentOS ditambal, ESXi ditambal, alat VMware terbaru yang diinstal di VM. Tidak ada pengguna di sistem, tidak ada layanan yang berjalan, tidak ada file di disk kecuali instalasi OS. Saya berinteraksi dengan VM melalui konsol virtual VM di vSphere Client.

Sebelum melangkah lebih jauh, saya ingin memeriksa apakah saya mengonfigurasi berbagai hal dengan lebih atau kurang masuk akal. Saya menjalankan perintah berikut sebagai root di shell di VM:

for i in 1 2 3 4 5 6 7 8 9 10; do
  dd if=/dev/zero of=/test.img bs=8k count=256k conv=fdatasync
done

Yaitu, ulangi perintah dd 10 kali, yang menghasilkan pencetakan tingkat transfer setiap kali. Hasilnya mengganggu. Dimulai dengan baik:

262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 20.451 s, 105 MB/s
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 20.4202 s, 105 MB/s
...

tetapi setelah 7-8 dari ini, kemudian dicetak

262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GG) copied, 82.9779 s, 25.9 MB/s
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 84.0396 s, 25.6 MB/s
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 103.42 s, 20.8 MB/s

Jika saya menunggu banyak waktu, katakan 30-45 menit, dan jalankan lagi, kembali ke 105 MB / s, dan setelah beberapa putaran (kadang-kadang beberapa, kadang-kadang 10+), turun menjadi ~ 20- 25 MB / s lagi.

Berdasarkan pencarian awal untuk kemungkinan penyebabnya, khususnya VMware KB 2011861 , saya mengubah penjadwal i / o Linux menjadi " noop" sebagai ganti default. cat /sys/block/sda/queue/schedulermenunjukkan bahwa ini berlaku. Namun, saya tidak dapat melihat bahwa ada perbedaan dalam perilaku ini.

Merencanakan latensi disk dalam antarmuka vSphere, ini menunjukkan periode latensi disk yang tinggi mencapai 1,2-1,5 detik selama waktu yang ddmelaporkan throughput rendah. (Dan ya, semuanya menjadi sangat tidak responsif saat itu terjadi.)

Apa yang menyebabkan ini?

Saya nyaman karena ini bukan karena disk gagal, karena saya juga telah mengkonfigurasi dua disk lain sebagai volume tambahan dalam sistem yang sama. Pada awalnya saya pikir saya melakukan sesuatu yang salah dengan volume itu, tetapi setelah berkomentar volume keluar dari / etc / fstab dan reboot, dan mencoba tes pada / seperti yang ditunjukkan di atas, menjadi jelas bahwa masalahnya ada di tempat lain. Ini mungkin masalah konfigurasi ESXi, tapi saya tidak terlalu berpengalaman dengan ESXi. Itu mungkin sesuatu yang bodoh, tetapi setelah mencoba mencari tahu ini selama berjam-jam selama beberapa hari, saya tidak dapat menemukan masalahnya, jadi saya berharap seseorang dapat mengarahkan saya ke arah yang benar.

(PS: ya, saya tahu kombo perangkat keras ini tidak akan memenangkan penghargaan kecepatan sebagai server, dan saya punya alasan untuk menggunakan perangkat keras kelas bawah ini dan menjalankan VM tunggal, tapi saya pikir itu selain poin untuk pertanyaan ini [kecuali ini sebenarnya masalah perangkat keras].)

LAMPIRAN # 1 : Membaca jawaban lain seperti yang satu ini membuat saya mencoba menambahkan oflag=directke dd. Namun, itu tidak membuat perbedaan dalam pola hasil: awalnya angkanya lebih tinggi untuk banyak putaran, kemudian turun menjadi 20-25 MB / s. (Angka absolut awal berada dalam kisaran 50 MB / s.)

ADDENDUM # 2 : Menambahkan sync ; echo 3 > /proc/sys/vm/drop_cacheske loop tidak membuat perbedaan sama sekali.

ADDENDUM # 3 : Untuk mengambil variabel lebih lanjut, saya sekarang menjalankan ddsedemikian rupa sehingga file yang dibuatnya lebih besar dari jumlah RAM pada sistem. Perintah baru adalah dd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct. Nomor throughput awal dengan versi perintah ini adalah ~ 50 MB / s. Mereka turun menjadi 20-25 MB / s ketika segalanya berjalan ke selatan.

TAMBAHKAN # 4 : Ini adalah output dari iostat -d -m -x 1menjalankan di jendela terminal lain sementara kinerja "baik" dan sekali lagi ketika itu "buruk". (Sementara ini sedang berlangsung, saya sedang berlari dd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct.) Pertama, ketika segala sesuatu "baik", ini menunjukkan ini:

masukkan deskripsi gambar di sini

Ketika segalanya menjadi "buruk", iostat -d -m -x 1perlihatkan ini:

masukkan deskripsi gambar di sini

ADDENDUM # 5 : Atas saran @ewwhite, saya mencoba menggunakan tuneddengan profil yang berbeda dan juga mencoba iozone. Dalam adendum ini, saya melaporkan hasil percobaan dengan apakah tunedprofil yang berbeda memiliki pengaruh pada ddperilaku yang dijelaskan di atas. Saya mencoba mengubah profil menjadi virtual-guest, latency-performancedan throughput-performancemenjaga semuanya tetap sama, me-reboot setelah setiap perubahan, dan kemudian setiap kali berjalan dd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct. Itu tidak mempengaruhi perilaku: sama seperti sebelumnya, segala sesuatunya dimulai dengan baik dan banyak putaran berulang ddmenunjukkan kinerja yang sama, tetapi kemudian di beberapa titik setelah 10-40 putaran, kinerja turun setengahnya. Selanjutnya, saya menggunakan iozone. Hasil-hasil itu lebih luas, jadi saya menempatkannya sebagai tambahan # 6 di bawah ini.

ADDENDUM # 6 : Atas saran @ewwhite, saya menginstal dan digunakan iozoneuntuk menguji kinerja. Saya menjalankannya di bawah tunedprofil yang berbeda , dan menggunakan parameter ukuran file (4G) maksimum yang sangat besar iozone. (VM memiliki 2,5 GB RAM yang dialokasikan, dan tuan rumah memiliki total 4 GB.) Uji coba ini memakan waktu cukup lama. FWIW, file data mentah tersedia di tautan di bawah ini. Dalam semua kasus, perintah yang digunakan untuk menghasilkan file adalah iozone -g 4G -Rab filename.

Berikut ini adalah ringkasan saya.

Dalam beberapa kasus saya reboot setelah menjalankan sebelumnya, dalam kasus lain saya tidak, dan hanya berlari iozonelagi setelah mengubah profil dengan tuned. Ini tampaknya tidak membuat perbedaan yang jelas pada hasil keseluruhan.

tunedProfil yang berbeda tampaknya tidak (bagi saya diakui tidak ahli) untuk mempengaruhi perilaku luas yang dilaporkan oleh iozone, meskipun profil memang memengaruhi rincian tertentu. Pertama, tidak mengejutkan, beberapa profil mengubah ambang batas di mana kinerja diturunkan untuk menulis file yang sangat besar: merencanakan iozonehasilnya, Anda dapat melihat tebing tipis pada 0,5 GB untuk profil latency-performancetetapi penurunan ini memanifestasikan dirinya pada 1 GB di bawah profilenterprise-storage. Kedua, meskipun semua profil menunjukkan variabilitas aneh untuk kombinasi ukuran file kecil dan ukuran rekaman kecil, pola variabilitas yang tepat berbeda antara profil. Dengan kata lain, dalam plot yang ditunjukkan di bawah ini, pola kasar di sisi kiri ada untuk semua profil tetapi lokasi lubang dan kedalamannya berbeda di profil yang berbeda. (Namun, saya tidak mengulangi run dari profil yang sama untuk melihat apakah pola variabilitas berubah secara nyata antara run di iozonebawah profil yang sama, jadi ada kemungkinan bahwa apa yang tampak seperti perbedaan antara profil benar-benar hanya variabilitas acak.)

Berikut ini adalah plot permukaan dari berbagai iozonetes untuk tunedprofil latency-performance. Deskripsi tes disalin dari dokumentasi untuk iozone.

Baca tes: Tes ini mengukur kinerja membaca file yang ada.

masukkan deskripsi gambar di sini

Tes tulis: Tes ini mengukur kinerja penulisan file baru.

masukkan deskripsi gambar di sini

Baca acak: Tes ini mengukur kinerja membaca file dengan akses yang dibuat ke lokasi acak dalam file.

masukkan deskripsi gambar di sini

Penulisan acak: Tes ini mengukur kinerja penulisan file dengan akses yang dibuat ke lokasi acak dalam file.

masukkan deskripsi gambar di sini

Fread: Tes ini mengukur kinerja membaca file menggunakan fungsi library fread (). Ini adalah rutinitas perpustakaan yang melakukan operasi baca yang disangga & diblokir. Buffer berada dalam ruang alamat pengguna. Jika suatu aplikasi membaca dalam ukuran transfer yang sangat kecil maka fungsionalitas I / O buffer (& I) yang diblok () dapat meningkatkan kinerja aplikasi dengan mengurangi jumlah panggilan sistem operasi aktual dan meningkatkan ukuran transfer saat sistem operasi panggilan dibuat.

masukkan deskripsi gambar di sini

Fwrite: Tes ini mengukur kinerja penulisan file menggunakan fungsi library fwrite (). Ini adalah rutinitas perpustakaan yang melakukan operasi penulisan buffer. Buffer berada dalam ruang alamat pengguna. Jika suatu aplikasi menulis dalam transfer ukuran yang sangat kecil maka fungsionalitas I / O yang diblokir & diblokir dari fwrite () dapat meningkatkan kinerja aplikasi dengan mengurangi jumlah panggilan sistem operasi aktual dan meningkatkan ukuran transfer ketika sistem operasi panggilan dibuat. Tes ini sedang menulis file baru sehingga sekali lagi overhead metadata termasuk dalam pengukuran.

masukkan deskripsi gambar di sini

Akhirnya, pada saat iozonemelakukan hal tersebut, saya juga memeriksa grafik kinerja untuk VM di antarmuka klien vSphere 5. Saya beralih bolak-balik antara plot real-time dari disk virtual dan datastore. Parameter plot yang tersedia untuk datastore lebih besar daripada untuk disk virtual, dan plot kinerja datastore tampaknya mencerminkan apa yang dilakukan disk dan plot disk virtual, jadi di sini saya hanya menyertakan cuplikan grafik datastore yang diambil setelah iozoneselesai (di bawah tunedprofil) latency-performance). Warnanya agak sulit dibaca, tetapi yang paling menonjol adalah paku vertikal tajam yang dibacalatensi (mis. pada 4:25, lalu sedikit lagi setelah 4:30, dan lagi antara 4: 50-4: 55). Catatan: plot tidak dapat dibaca saat disematkan di sini, jadi saya juga mengunggahnya ke http://cl.ly/image/0w2m1z2T1z2b

vSphere plot waktu nyata dari VM

Saya harus mengakui, saya tidak tahu harus membuat apa dari semua ini. Saya terutama tidak mengerti profil lubang yang aneh dalam catatan kecil / ukuran file kecil dari iozoneplot.


Dengan asumsi bahwa Anda telah menggunakan utilisasi disk yang tinggi dalam hal IOPS untuk jangka waktu yang lama, maka Anda kemungkinan mengalami kejenuhan disk pada beberapa level (baik pada level antrian penulisan disk os atau lebih mungkin pada level hard disk) di mana Anda memiliki lebih banyak permintaan daripada yang dapat ditangani oleh disk Anda saat ini. Saya tidak cukup berpengalaman untuk memberi tahu Anda cara menentukan apakah Anda mengalami kejenuhan disk tetapi saya pikir ini mungkin menjadi titik penyelidikan untuk Anda.
Jason Zhu

@JasonZhu Ini pertanyaan yang bagus. Saya telah mengasumsikan bahwa karena sistem tidak melakukan hal lain, dan saya hanya menjalankan perintah yang sama berulang kali, tingkat penggunaan disk kira-kira konstan. Namun, perlu waktu lama sebelum perilaku terwujud meskipun ini. Saya menjalankan iostatdan itu menunjukkan ~ 90% pemanfaatan sebelum dan sesudah. Tapi saya bukan ahli dalam menilai hal-hal ini - mungkin kejenuhan terjadi di suatu tempat. Saya memperbarui pertanyaan saya untuk menampilkan iostatkeluaran jika berguna.
mhucka

Apakah ada kemungkinan ini disebabkan oleh cache disk ESX? Apakah disk yang Anda uji dioptimalkan untuk kinerja atau keamanan? Juga, jika itu dioptimalkan untuk kinerja, dapatkah Anda melihat pemanfaatan cache ESX saat Anda menguji? Perubahan IO pada throughput ini tampak seperti menulis yang memukul cache, dan kemudian melambat ke kecepatan destage ketika mengisi.
Basil

Bisakah itu ada hubungannya dengan Anda cache controller RAID? IOPS / throughput tinggi hingga penuh dan kemudian Anda kembali ke kinerja HDD mentah? Hanya menebak-nebak ...
Mario Lenz

@ MarioLenz Seperti yang saya sebutkan dalam deskripsi, ini tidak memiliki RAID.
mhucka

Jawaban:


2

Bisakah Anda memberikan nomor build ESXi yang tepat? Silakan coba tes lagi dengan alat analisis kinerja disk tujuan-dibangun seperti fio atau iozone untuk mendapatkan dasar yang nyata. Penggunaannya ddtidak terlalu produktif untuk ini.

Secara umum, penjadwal I / O default di EL6 tidak terlalu bagus. Anda harus melihat beralih ke tenggat waktu atau lift I / O noop, atau lebih baik lagi, menginstal kerangka kerja yang disetel .

Coba: yum install tuned tuned-utilsdan tuned-adm profile virtual-guest, lalu uji lagi.


Argh, saya lupa menyebutkan bahwa saya benar-benar mengubah scheduler menjadi noop. Saya akan mengedit pertanyaan saya untuk mengatakan itu. Adapun nomor build, ini 1746018. (Saya memang memasukkan itu dalam paragraf 2, tapi saya melihat sesuatu terjadi dan itu terpotong - pasti kecelakaan editing. Saya akan memperbaikinya juga.) Saya akan melihat ke dalam framework disetel dan alat-alat lainnya. Terima kasih atas saran Anda.
mhucka

Saya mencoba tuned, menggunakan profil virtual-guestdan menjaga semuanya tetap sama (teknik eksperimental yang tepat - hindari mengubah lebih dari satu variabel). Itu tidak mempengaruhi perilaku: sama seperti sebelumnya, semuanya dimulai dengan baik, tetapi setelah banyak berjalan berulang-ulang (10-30) dd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct, kinerja turun setengahnya. Saya juga mencoba profil latency-performance- hasil yang sama. Saya sedang berusaha throughput-performance.
mhucka

Bisakah Anda mencoba sesuatu yang tidak melibatkan ddlari? Mungkin fioatau iozonedisebutkan sebelumnya?
ewwhite

Aku akan. Tapi pertama-tama, masuk akal untuk mengulangi tes yang sama, untuk melihat apakah perilakunya berubah.
mhucka

2

Saya mengalami masalah yang sama dan melihat kinerja drive yang sangat lambat dalam mesin virtual. Saya menggunakan ESXi 5.5 pada Seagate ST33000650NS.

Dengan mengikuti ini artikel kb saya mengubah Disk.DiskMaxIOSizeke saya ukuran disk block. Dalam kasus saya 4096.

Catatan VMware tentang ini sangat bagus, karena Anda bisa mengujinya.

Catatan: Anda dapat melakukan perubahan ini tanpa me-reboot host ESX / ESXi atau tanpa menempatkan host ESX / ESXi dalam mode pemeliharaan.

Saya tahu pertanyaan ini sudah sangat lama, tetapi mhucka menaruh begitu banyak energi dan informasi dalam jabatannya, yang harus saya jawab.

Sunting # 1: Setelah menggunakan 4096 selama sehari, saya beralih kembali ke nilai lama 32767. Menguji IO dan semuanya tampaknya masih stabil. Dugaan saya adalah menjalankan ESXi pada HDD normal dengan Disk.DiskMaxIOSizepengaturan 32767akan berfungsi dengan baik selama beberapa jam atau mungkin berhari-hari. Mungkin butuh beberapa beban dari VM untuk secara bertahap mengurangi kinerja.

Saya mencoba untuk menyelidiki dan kembali lagi nanti ...


Terima kasih telah berbagi ini. Berguna untuk mengetahui tentang mengubah ukuran blok disk. Saya menyesal tidak bisa mengujinya karena saya tidak lagi memiliki konfigurasi ini (saya akhirnya membuangnya dan pergi dengan CentOS pada bare metal), tetapi jika saya pernah mencoba sesuatu seperti ini lagi, Anda dapat yakin saya akan melihat ke dalam ini .
mhucka

Saya mencoba mencari waktu latensi tinggi pada esxi 6.5 saya pada mesin ProLiant 380 Gen9. Disk.DiskMaxIOSizemelakukan trik untukku. Saya sedang meneliti dan mengukur selama 2 minggu sekarang. Terima kasih telah berbagi.
EvanBlack

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.