VMXNET3 menerima ukuran buffer dan penggunaan memori


12

Latar Belakang

Kami memiliki insiden di mana gugus failover Windows mengalami gangguan. Post-mortem menunjukkan bahwa node "dihapus" seperti yang dijelaskan dalam artikel ini .

Kami baru saja memigrasikan cluster ini sepenuhnya ke lingkungan VMware kami, dan tampaknya peristiwa yang dijelaskan di atas mungkin menjadi penyebab pemadaman.

Terkait artikel VMware KB tentang pembicaraan ini tentang peningkatan Small Rx Buffersdan Rx Ring #1pengaturan, tetapi memperingatkan bahwa peningkatan ini terlalu banyak drastis dapat meningkatkan overhead memori pada host.

Setelah audit Network Interface\Packets Received Discardedpenghitung kinerja untuk ~ 150 Windows VM kami, 22 vNIC di 16 tamu memiliki beberapa paket yang dibuang.

Jumlah yang cukup kecil yang saya tidak khawatir tentang membebani host dengan penggunaan memori tambahan, tetapi saya ingin memahami bagaimana memori digunakan untuk pengaturan ini dan dari mana memori berasal.

Pertanyaan

  1. Apa hubungan antara jumlah buffer dan ukuran cincin?
  2. Bagaimana cara menghitung jumlah memori yang digunakan untuk nilai yang diberikan pengaturan ini?
  3. Karena pengaturan ini pada NIC itu sendiri dalam OS tamu, saya menganggap mereka adalah pengaturan driver. Ini membuat saya berpikir bahwa RAM yang digunakan mungkin paged atau non-paged pool.
    1. Apakah ini benar?
    2. Jika demikian, haruskah saya khawatir tentang itu?
  4. Apakah ada kekhawatiran saya tidak mempertimbangkan di sini?

Kami mencoba menentukan apakah ada kekurangan untuk mengatur ini secara maksimal pada VM yang terpengaruh, selain penggunaan memori host VMware. Misalnya, jika kita meningkatkan risiko memori kumpulan habis di tamu, kita cenderung memulai dari yang kecil.

Beberapa (mungkin semua) pertanyaan ini mungkin tidak spesifik untuk VMware atau virtualisasi.


Saya telah melihat hal-hal yang benar-benar tidak jelas ketika mesin TCP offload dari NIC fisik mengalami gangguan dan VM menunjukkan perilaku aneh, mungkin merupakan petunjuk yang dapat Anda tindak lanjuti.
SpacemanSpiff

@SpacemanSpiff perlu diperiksa, tetapi hanya 16 VM dari 150+ yang menunjukkan perilaku tersebut. Mereka 16 tersebar di 12 node cluster, dan mereka semua menerima lalu lintas tinggi sesekali yang tampaknya menjadi pemicu gejala yang dijelaskan dalam artikel KB. Beberapa di antaranya adalah kluster Windows sehingga mereka tidak bergerak dengan DRS, kalau tidak saya mungkin melihat apakah semua tamu yang terkena dampak menunjukkan paket yang dijatuhkan saat berada di host tertentu sebelum dibatalkan. Saya akan memeriksa lagi dan melihat apakah saya dapat menemukan korelasi. Terima kasih.
briantist

Microbursting mungkin, perangkat keras apa ini?
SpacemanSpiff

@SpacemanSpiff Server IBM, beberapa model dan revisi yang berbeda, juga tidak yakin NIC mana, saya dapat memeriksa spesifikasi besok.
briantist

Jawaban:


5

Apa hubungan antara jumlah buffer dan ukuran cincin?

Mereka terkait, tetapi mandiri. Rx "ring" mengacu pada satu set buffer dalam memori yang digunakan sebagai antrian untuk melewatkan paket jaringan yang masuk dari host (hypervisor) ke guest (Windows VM). Memori dicadangkan di tamu oleh driver jaringan, dan itu akan dipetakan ke dalam memori host.

Ketika paket-paket jaringan baru masuk pada host, mereka dimasukkan ke buffer berikutnya yang tersedia di atas ring. Kemudian, tuan rumah memicu IRQ di tamu, di mana driver tamu merespons dengan mengambil dia paket dari cincin, dan mengirimkannya ke tumpukan jaringan OS tamu, yang mungkin mengirimkannya ke aplikasi tamu yang ingin menerimanya. Dengan asumsi paket datang cukup lambat, dan driver tamu memprosesnya cukup cepat, harus selalu ada slot gratis di ring. Namun, jika paket masuk terlalu cepat, atau tamu memprosesnya terlalu lambat, cincin itu bisa penuh, dan paket mungkin jatuh (seperti yang Anda lihat dalam situasi Anda).

Meningkatkan ukuran dering dapat membantu mengurangi masalah ini. Jika Anda meningkatkannya, lebih banyak slot akan tersedia di ring pada suatu waktu. Ini segues ke pengaturan kedua, "Small Rx Buffer", yang merupakan jumlah total buffer yang tersedia yang dapat digunakan untuk mengisi slot di cincin. Harus ada setidaknya buffer sebanyak slot di ring. Biasanya Anda menginginkan lebih. Ketika tamu mengambil buffer dari ring untuk diberikan ke tumpukan jaringan tamu, itu mungkin tidak selalu segera dikembalikan kembali ke driver. Jika itu terjadi, memiliki buffer cadangan untuk mengisi cincin berarti Anda bisa pergi lebih lama tanpa menjatuhkan paket.

Rx Ring # 1 / Small Rx Buffer digunakan untuk frame non-jumbo. Jika Anda memiliki konfigurasi NIC default, itu satu-satunya dering yang akan digunakan.

Bagaimana cara menghitung jumlah memori yang digunakan untuk nilai yang diberikan pengaturan ini?

Dengan asumsi Anda berbicara tentang frame non-jumbo, setiap buffer harus cukup besar untuk menyimpan seluruh paket jaringan, kira-kira 1,5kb. Jadi jika Anda memiliki 8192 buffer yang tersedia, itu akan menggunakan 12MB. Cincin yang lebih besar juga akan menggunakan lebih banyak memori, tetapi deskriptornya kecil (byte), jadi itu benar-benar buffer yang harus Anda khawatirkan.

Karena pengaturan ini pada NIC itu sendiri dalam OS tamu, saya menganggap mereka adalah pengaturan driver. Ini membuat saya berpikir bahwa RAM yang digunakan mungkin paged atau non-paged pool.

Ya, ini kolam non-paged. Jika buffer ring dipetakan, kemungkinan akan menghasilkan paket yang jatuh sementara buffer dikembalikan.

Apakah ada kekhawatiran saya tidak mempertimbangkan di sini?

Saya tidak yakin ini relevan dengan situasi Anda, tetapi mungkin perlu dicatat bahwa cincin yang lebih besar akan meningkatkan jejak cache dari jalur rx jaringan. Dalam microbenchmarks, Anda akan melihat bahwa cincin yang lebih besar biasanya merusak kinerja. Yang mengatakan, dalam aplikasi kehidupan nyata, jika sebuah paket dijatuhkan, itu biasanya lebih besar daripada peningkatan kinerja kecil dalam kecepatan meledak.

Sumber: Saya bekerja di VMware.


1
Terima kasih Roger, jawaban pertama yang bagus. Saya belum pernah berada di perusahaan ini untuk beberapa saat, jadi masalah ini sudah di luar jangkauan saya, tetapi untuk kelengkapannya, apakah ada masalah penggunaan memori untuk mengaturnya hingga maksimum? Artikel KB membuatnya terdengar seperti Anda bisa menggunakan banyak memori dengan cara itu tetapi sepertinya jumlahnya akan sangat kecil. Saya menanyakan hal ini karena juga tidak jelas bagaimana mengukur nilai-nilai ini selain trial and error, jadi mungkin lebih mudah untuk mengaturnya ke max jika tidak ada / sedikit downside.
briantis

1
Re: penggunaan memori, dua hal yang saya perhatikan: 1) Jika Anda tidak menggunakan frame jumbo, saya setuju, jumlah memori pada pengaturan maksimum masih cukup kecil. Jika Anda menggunakan bingkai jumbo, ukuran buffer sekitar 9kb sehingga Anda menggunakan lebih banyak memori. 2) Jumlah memori yang tersedia dalam kumpulan non-paged lebih kecil dari jumlah total memori pada host. Saya bukan ahli di sini, tetapi tautan ini memiliki ikhtisar yang cukup komprehensif tentang cara menghitung memori yang tersedia: blogs.technet.microsoft.com/markrussinovich/2009/03/10/…
Roger Jacobson

Terima kasih banyak. Saya harap jawaban ini membantu seseorang di masa depan (mungkin itu akan menjadi saya jika saya mengalami hal ini lagi!)
briantist

0

Saya tidak punya balasan untuk poin 1-2-3 tetapi Anda dapat memeriksa dengan insinyur virtual Anda tentang konfigurasi host Vmware. Jika dia VCP dia akan mengerti hal-hal :)

Anda benar-benar harus memeriksa host Anda karena masalah windows bisa di host bukan di tamu.

Ada banyak fitur perangkat keras yang dapat menjelaskan masalah Anda, directpath io, rss, vcpu, skema manajemen daya ...

Saya dapat memberi Anda beberapa tautan yang membantu tim virtual Anda, atau Anda :)

Tautan ini adalah tentang menyetel host http://buildvirtual.net/tuning-esxi-host-networking-configuration/

Dan pdf gemuk ini:

http://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.0.pdf

Dan ini tentang rss:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2008925


Terima kasih atas jawabannya, tetapi saya seorang VCP. Ini bukan konfigurasi host sama sekali. Artikel Microsoft yang saya tautkan menjelaskan bahwa penghitung kinerja yang dipermasalahkan tidak boleh lebih tinggi dari 0, dan ada di beberapa VM. Saya mencoba untuk mendapatkan pemahaman tentang pengaturan vNIC di luar apa yang dijelaskan dalam artikel VMware KB.
briantist

-1

Saya tidak dalam posisi untuk sepenuhnya mencari dan mengarahkan Anda ke halaman yang tepat: jadi saya meminta Anda untuk mencari sendiri detailnya ... (maaf)

Dalam Fail over Cluster ada 4 pengaturan yang dapat tweeked; dan mereka tidak akan memengaruhi buffer atau paged atau non-paged ... Itu mengubah cara Gagal terhadap Cluster membuat keputusan untuk mempertimbangkan sebuah simpul "dihapus". Pengaturan ini adalah:

SameSubnetDelay SameSubnetThreshold CrossSubnetDelay CrossSubnetThreshold

Mereka mungkin tidak menyelesaikan masalah Anda, tetapi mengubah ini dapat membuat Anda keluar dari masalah saat ini ...

Ketika kembali pada hari Senin, saya akan memeriksa kembali ke posting ini jika Anda memiliki pertanyaan lebih lanjut

HTH, Edwin.


PS: dapatkah Anda memberi tahu kami versi Windows yang Anda jalankan?
Edwin van Mierlo

Ini adalah Windows 2008. Saya mendapat balasan dari VMware (setelah sekian bulan ini), tetapi saya bahkan tidak berada di perusahaan tempat saya berada ketika ini terjadi. Jawabannya tidak langsung dan saya sudah bermaksud membaca jawaban mereka dan memposting sesuatu, tapi saya belum punya waktu. Saya menghargai tips Anda tentang klaster tetapi saya tidak dapat mencobanya saat ini.
briantis

Saya hanya melihat bahwa posting asli berumur beberapa bulan, yang tidak terlalu jelas di aplikasi-android ... Saya akan melihat lebih dekat lain kali ... sementara jawaban saya masih berlaku untuk pengguna lain yang mungkin mencari untuk pengalaman serupa.
Edwin van Mierlo
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.