Tuning NFS client / server stack


10

Saya memiliki server CentOS 5 VMWare yang terhubung ke mesin OpenSolaris 2009.06 melalui NFS yang menampung gambar disk. Mesin virtual saya sepertinya terikat oleh IO yang lambat jadi saya ingin melakukan semua yang saya bisa untuk mengoptimalkan koneksi.

Saya tidak yakin tentang cara terbaik untuk mengukur throughput pada sistem produksi, tetapi beberapa tes tidak ilmiah menggunakan dd bs=1024k count=400acara lokal (OpenSolaris) menulis ~ 1.6GB / s dan jarak jauh (CentOS) menulis ~ 50MB / s. Saya membayangkan ini lebih rendah dari apa yang sebenarnya saya dapatkan karena 7 VM saat ini berjalan melalui koneksi.

Saat ini, 2 mesin adalah gigE yang terhubung langsung dengan frame jumbo diaktifkan pada kedua NIC (MTU = 9000). Selain itu, belum ada optimasi yang dilakukan. NFS mount / ekspor menggunakan default.

Di mana saya harus mulai memutar kenop untuk meningkatkan kinerja?


Throughput seharusnya tidak terlalu menjadi masalah. Apa spesifikasi perangkat keras yang mendasarinya pada sistem yang menjalankan OpenSolaris? Berapa banyak disk / spindle yang Anda miliki? Berapa banyak RAM?
ewwhite

12 disk tersebar di 2 kolam raidz1 pada satu kontroler dengan 4GB RAM. Jika throughput tidak penting, metrik apa yang harus saya perhatikan?
Sysadminicus

Apa yang dilakukan cat / proc / mounts | grep solaris_server katakan pada klien Linux? Berbagai versi Linux memiliki opsi pemasangan standar yang berbeda :(
James

10.10.1.1:/tank/vm / vm nfs rw, vers = 3, rsize = 1048576, wsize = 1048576, hard, proto = tcp, timeo = 600, retrans = 2, sec = sys, addr = 10.10.1.1 0 0
Sysadminicus

dengan beberapa edisi Solaris 10, nfs3 tidak stabil. Jika Anda dapat pindah ke nfs4 Anda mungkin melihat beberapa peningkatan. Namun, seperti komentator lain mengatakan, melihat 50MB / s di link gigE dekat tertinggi Anda dapat melihat
warren

Jawaban:


2

Hanya untuk memperjelas, Anda mendapatkan 50MB / detik dengan NFS melalui koneksi ethernet Gb tunggal?

Dan server host menjalankan CentOS dengan VMware Server diinstal, yang pada gilirannya menjalankan 7 VM? Apakah ada alasan tertentu Anda menggunakan CentOS dan VMware Server, daripada VMware ESXi yang merupakan solusi kinerja yang lebih tinggi?

50MB / detik tidak bagus, tapi tidak jauh di bawah apa yang Anda harapkan melalui kabel jaringan Gb tunggal - setelah Anda memasukkan NFS tweak yang telah disebutkan di atas, Anda mungkin akan melihat mungkin 70- 80MB / detik. Opsi di sepanjang baris:

"ro, hard, intr, retrans = 2, rsize = 32768, wsize = 32768, nfsvers = 3, tcp"

mungkin masuk akal untuk Anda di kedua ujung sistem.

Untuk mendapatkan di atas bahwa Anda akan perlu melihat timing kartu jaringan menjadi berpasangan, yang akan meningkatkan throughput Anda sekitar 90%. Anda mungkin memerlukan sakelar yang mendukung 802.3ad untuk mendapatkan kinerja terbaik dengan agregasi tautan .

Satu hal yang saya sarankan adalah throughput IO Anda pada kotak OpenSolaris terdengar sangat mencurigakan, 12 disk sepertinya tidak mendukung throughput 1,6GB / detik, dan itu mungkin sangat di-cache oleh Solaris + ZFS.


Kami menggunakan CentOS + VMWare Server karena gratis. Terakhir saya memeriksa ESXi cukup mahal. Menurut / proc / mounts, rsize / wsize saat ini 1048576. Hanya untuk mengkonfirmasi, Anda pikir mengurangi ini menjadi 32k akan membantu meningkatkan kecepatan? Saya akan memeriksa agregasi tautan. Apakah saya akan melakukan ini di kedua ujung koneksi atau hanya satu? Saya pikir Anda benar tentang IO sedang di-cache. Menabrak dd saya di atas 512MB secara signifikan menurunkan kecepatan transfer (berkisar antara 50-120MB / s).
Sysadminicus

Saya tidak lagi memiliki kemampuan di UI untuk menerima jawaban untuk pertanyaan ini, tetapi saya telah meningkatkan ini karena sepertinya agregasi tautan akan menjadi taruhan terbaik saya.
Sysadminicus

Maaf atas balasan yang tertunda, ESXi sekarang gratis dalam bentuk dasarnya, dan akan memberi Anda peningkatan kinerja, tetapi memang memiliki fungsi terbatas sehingga mungkin tidak tepat untuk Anda. Anda harus melakukan agregasi tautan di kedua ujung tautan jaringan untuk melihat banyak peningkatan. Semoga ini berhasil untuk Anda
Ewan Leith

1

Untuk mesin RHEL / CentOS 5 kami, kami menggunakan flag mount berikut

nfsvers = 3, tcp, timeo = 600, retrans = 2, rsize = 32768, wsize = 32768, hard, intr, noatime

Versi kernel Linux yang lebih baru mendukung parameter rsize / wsize yang lebih besar, tetapi 32k adalah maksimum untuk kernel 2.6.18 di EL5.

Di server NFS, setidaknya untuk Linux no_wdelay seharusnya membantu jika Anda memiliki pengontrol disk dengan BBWC. Juga, jika Anda menggunakan flag noatime pada klien, mungkin masuk akal untuk me-mount sistem file pada server dengan noatime juga.

Dan, seperti yang telah disebutkan, jangan repot-repot dengan UDP. Dengan jaringan berkecepatan lebih tinggi (1GbE +), ada peluang kecil, tetapi tidak nol, dari pembungkus nomor urut yang menyebabkan korupsi data. Juga, jika ada kemungkinan packet loss, TCP akan berkinerja lebih baik daripada UDP.

Jika Anda tidak terlalu mengkhawatirkan integritas data, opsi ekspor "async" dapat menjadi peningkatan kinerja utama (masalah dengan async adalah Anda mungkin kehilangan data jika server crash).

Juga, setidaknya untuk server Linux, Anda perlu memastikan Anda memiliki cukup thread server NFS yang berjalan. Default 8 terlalu rendah.


1

Saya pernah melakukan tes dengan dell r710, 1 cpu, 4 GB RAM, 6 SATA disk dengan RAID-10. Klien adalah x2100 matahari, baik dengan CentOS 5.3 dan parf nfs seperti yang disebutkan di atas

"ro, hard, intr, retrans = 2, rsize = 32768, wsize = 32768, nfsvers = 3, tcp"

dipasang di kedua sisi dengan noatime.

Saya juga menabrak hingga nfsds ke 256 dan menggunakan scheduler noop untuk pengontrol serangan perc6. Hal lain yang saya lakukan adalah menyelaraskan partisi dengan ukuran garis 64K dari pengontrol serangan.

kemudian saya mengukur kinerja nfs dengan dd - untuk membaca saya bisa mengisi pipa gigE tetapi untuk menulis saya hanya bisa mendapatkan hasil yang sedikit lebih baik seperti Anda. Dengan async diaktifkan saya bisa mendapatkan 70 hingga 80 MB / s tetapi async tidak ada pilihan untuk saya.

Mungkin Anda tidak bisa mendapatkan lebih banyak dengan nfs dari tautan gigE?


1

Coba ini: Nonaktifkan ZFS Intent Log (ZIL) sementara di server OpenSolaris NFS dengan dua langkah berikut

  1. echo zil_disable/W0t1 | mdb -kw
  2. pasang kembali partisi uji

Lalu tes lagi. Anda dapat menggunakan zilstat untuk memastikan bahwa tidak ada lagi IO ke ZIL. Jika tes berjalan lebih cepat, Anda tahu bahwa masalah kinerja ada hubungannya dengan ZIL. Jika masih berjalan lambat, Anda tahu bahwa ZIL bukanlah penyebabnya dan bahwa menggunakan SSD untuk ZIL juga tidak akan membantu. Lihat Panduan Tuning Jahat ZFS untuk informasi lebih lanjut tentang ZIL.

Pilihan lain adalah untuk menangkap lalu lintas jaringan (misalnya dengan Wireshark) dan melihat apakah ada masalah misalnya dengan frame Jumbo. Verifikasi bahwa paket pada kabel terlihat seperti yang Anda harapkan dari konfigurasi Anda. Apakah ada fragmentasi buruk yang terjadi? Apakah ada pengiriman ulang?


0

Meningkatkan ukuran muatan baca dan tulis dapat membantu. Terutama dalam hubungannya dengan bingkai jumbo.

Saya cenderung menemukan 32k menjadi optimal.

rsize=32768,wsize=32768

Beralih ke transport UDP tentu saja lebih cepat daripada TCP, karena menghemat overhead kontrol transmisi. Tapi itu hanya berlaku di jaringan yang andal dan di mana NFSv4 tidak digunakan.


Sepertinya CentOS terhubung menggunakan NFSv3. Apakah ada nilai dalam NFSv4 untuk kasus penggunaan kami? Saya akan mengatakan jaringannya cukup andal mengingat hanya ada kabel cross-over antara kedua NIC.
Sysadminicus

2
UDP benar-benar tidak sebanding dengan kerumitannya. Tetap berpegang pada TCP. Saya tidak akan menyarankan mencoba NFSv4 sampai Anda membuat v3 berfungsi dengan baik.
James

0

Kinerja NFS pada ZFS sangat ditingkatkan dengan menggunakan SSD untuk log tujuan ZFS (ZIL) karena ini mengurangi latensi operasi. Utas ini tentang VMWare NFS pada kinerja ZFS pada milis OpenSolaris NFS dan ZFS memiliki informasi lebih lanjut, termasuk alat tolok ukur untuk melihat apakah kinerja ZIL adalah hambatan.


0

FYI perintah dd akan menulis ke cache dan tidak ada disk, ini Anda bisa mendapatkan angka gila seperti 1.6G / s karena Anda menulis ke RAM dan bukan disk di Solaris Anda dapat menggunakan "-oflag = sinkronisasi" untuk memaksa menulis ke disk

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.