Saya akan menjawab dalam dua bagian: pertama "mengapa jawaban tradisional tentang memisahkan berurutan dan acak sering tidak berlaku."
Kemudian saya akan membahas manfaat potensial dari memisahkan file di physicaldisk Windows, dan menambahkan vHBAs tambahan dan mendistribusikan disk fisik di antara mereka.
Mengharapkan manfaat dari memisahkan IO disk acak dan berurutan pada tingkat fisikdisk Windows biasanya mengasumsikan perangkat HDD untuk penyimpanan data. Ini juga biasanya mengasumsikan bahwa pemisahan fisik Windows terpisah berarti perangkat HDD terpisah. Idenya adalah bahwa beberapa set HDD terutama menangani IO disk berurutan dan memiliki pergerakan kepala disk yang sangat terbatas (mis. HDD menampung txlog * tunggal sibuk), sementara seperangkat HDD lain menangani IO disk acak.
Asumsi itu jarang berlaku saat ini - terutama dalam VM. Pertama-tama, kecuali disk fisik VM Windows adalah RDM, beberapa bisa dalam satu datastore - atau mungkin beberapa datastores berada pada satu host LUN ESXi tunggal. Jadi apa yang dipisahkan dalam tamu dapat dicampurkan di tingkat host ESXi.
Tetapi katakanlah bahwa RDM digunakan, atau bahwa setiap physicaldisk tamu ada di datastore sendiri, di ESXi LUN sendiri. Bahkan kemudian, urutan terpisah dari io acak di tamu sering bercampur di array, karena LUN yang disajikan ke host ESXi mungkin dari kumpulan perangkat disk yang sama. Hampir setiap larik penyimpanan melakukan ini sekarang - baik secara eksklusif atau sebagai opsi untuk memudahkan manajemen dan meningkatkan efisiensi larik / pemanfaatan sumber daya.
Akhirnya, banyak penyimpanan saat ini adalah semua flash atau hybrid + HDD. Dengan tidak ada gerakan kepala yang perlu dikhawatirkan, flash tidak peduli tentang pemisahan urutan secara acak ... bahkan tidak peduli tentang tenun IO.
Jadi ... itu semua alasan memisahkan sekuensial dari acak mungkin tidak terlalu menguntungkan. Selanjutnya mengapa menyebarkan file di file fisik dan menyebarkan file fisik di vHBA masih dapat meningkatkan kinerja.
* Saya sengaja menyebutkan satu log transaksi dalam contoh HDD ini. Ketika beberapa aliran IO disk berurutan terpisah (mis. 8 log transaksi sibuk) terjadi pada HDD yang sama - kecuali entah bagaimana hampir semua aktivitas berada dalam cache SAN - gerakan head konstan di antara trek IO berurutan mengarah ke IO menenun. Itu jenis tertentu dari disk head thrashing yang mengarah ke latensi disk yang "lebih buruk daripada acak". Terjadi pada RAID5 dan RAID10, meskipun RAID10 dapat mentolerir sedikit lebih banyak variasi dalam hal ini daripada RAID5 sebelum degradasi yang signifikan.
Sekarang - mengingat bahwa pembicaraan panjang lebar tentang bagaimana memisahkan sekuensial dari acak mungkin tidak membantu - bagaimana bisa menyebarkan file di file fisik masih membantu? Bagaimana cara menyebarkan masalah fisik di antara vHBA membantu?
Ini semua tentang antrian disk IO.
Setiap fisik Windows atau LogicalDisk dapat memiliki hingga 255 IO disk yang luar biasa pada waktu yang dilaporkan oleh perfmon sebagai "Current Disk Queue". Dari disk IO yang beredar dalam antrian disk fisik, storport dapat melewati hingga 254 ke minidriver. Tetapi minidriver mungkin juga memiliki antrian layanan (diturunkan ke level lebih rendah berikutnya) dan antrian tunggu. Dan storport dapat dikatakan menurunkan jumlah yang diteruskannya dari 254.
Dalam tamu VMware Windows, driver pvscsi memiliki kedalaman antrian "perangkat" default 64, di mana perangkat tersebut adalah disk fisik. Jadi, meskipun perfmon dapat menampilkan hingga 255 IO disk dalam "panjang antrian disk saat ini" untuk satu disk fisik, hanya 64 di antaranya yang akan diteruskan ke level berikutnya sekaligus (kecuali jika default diubah).
Berapa banyak IO disk yang dapat beredar untuk satulog transaksi sibuk pada suatu waktu? Yah, log transaksi menulis bisa mencapai ukuran 60kb. Selama ETL skala tinggi, saya akan sering melihat setiap menulis ke txlog di 60kb. Penulis txlog dapat memiliki hingga 32 penulisan 60kb yang beredar untuk satu txlog sekaligus. Jadi bagaimana jika saya punya pementasan sibuk txlog dan sibuk dw txlog pada physicaldisk yang sama, dengan pengaturan VMware default? Jika kedua txlog maksimum masing-masing mencapai 60kb, masing-masing menulis 60kb, physicaldisk itu berada pada kedalaman antrian 64. Sekarang ... bagaimana jika ada juga flatfiles sebagai sumber ETL pada physicaldisk? Nah ... antara membaca ke flatfiles dan menulis txlog, mereka harus menggunakan antrian tunggu, karena hanya 64 yang bisa keluar sekaligus. Untuk database dengan txlog yang sibuk seperti itu, apakah server fisik atau virtual, saya sarankan txlog pada disk fisiknya sendiri, dengan tidak ada lagi di physicaldisk. Itu mencegah antrian pada tingkat itu dan juga menghilangkan kekhawatiran dengan isi dari beberapa file interleaving (yang merupakan perhatian jauh, jauh lebih sedikit hari ini).
Berapa banyak IO disk yang dapat beredar ke file baris sekaligus (dari perspektif SQL Server, tidak harus diserahkan ke tingkat yang lebih rendah)? Sebenarnya tidak ada batasan dalam SQL Server itu sendiri (yang saya temukan, sih). Tetapi dengan asumsi file yang ada di Windows PhysicalDisk tunggal (saya tidak menyarankan menggunakan disk dinamis bergaris untuk SQL Server, itu topik untuk lain waktu), ada adalah batas. Ini adalah 255 yang saya sebutkan sebelumnya.
Dengan keajaiban readahead SQL Server dan IO asinkron, saya telah melihat 4 query bersamaan yang berjalan dalam drive serial total "panjang antrian disk saat ini" lebih dari 1200! Karena batas 255, itu bahkan tidak mungkin dengan semua konten rowfile pada disk fisik tunggal. Itu bertentangan dengan filegroup utama dengan 8 file, masing-masing pada disk fisik sendiri.
Jadi readahead membaca bisa sangat agresif, dan dapat menekankan antrian IO. Mereka bisa sangat agresif sehingga file baris lain membaca dan menulis akhirnya menunggu. Jika log transaksi berada di physicaldisk yang sama dengan rowfiles, selama readahead simultan membaca dan menulis txlog, sangat mudah untuk menunggu berlangsung. Bahkan jika penantian itu tidak pada tingkat "panjang antrian disk saat ini", mungkin menunggu di antrian perangkat (64 secara default dengan pvscsi).
Pencadangan cadangan terhadap file baris juga bisa menjadi agresif, terutama jika buffercount telah disetel untuk memaksimalkan throughput cadangan.
Ada satu lagi tipe SQL Server io yang harus diperhatikan ketika mempertimbangkan mengisolasi txlog: query spill to tempdb. Saat terjadi kueri tumpahan, setiap tumpahan berfungsi menulis ke tempdb. Punya banyak pekerja paralel tumpah pada saat yang sama? Itu bisa jadi beban menulis. Menjaga txlog yang sibuk dan barisfile penting jauh dari itu bisa sangat membantu :-)
Sekarang, dimungkinkan untuk mengubah kedalaman antrian perangkat default untuk driver pvscsi. Standarnya adalah 64, dan dapat ditetapkan setinggi 254 yang merupakan penyimpanan paling banyak yang akan diteruskan. Tapi hati-hati mengubah ini. Saya selalu merekomendasikan menyelaraskan kedalaman antrian perangkat tamu dengan kedalaman antrian LUN host ESXi yang mendasarinya. Dan pengaturan ESXi host LUN kedalaman antrian per array praktik terbaik. Menggunakan EMC VNX? Host LUN antrian harus 32. Tamu menggunakan RDM? Bagus. Atur kedalaman antrian perangkat pvscsi tamu menjadi 32 sehingga sesuai dengan kedalaman antrian host LUN ESXi. EMC VMAX? Biasanya 64 di tingkat host ESXi, 64 di tamu. Murni / Xtremio / IBM FlashSystem? Terkadang kedalaman host LUN antrian akan ditetapkan setinggi 256! Silakan dan atur kedalaman antrian perangkat pvscsi ke 254 (Maksimal mungkin).
Berikut tautan dengan instruksi.
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2053145
Tautan ini juga berbicara tentang halaman requestring - WhatAreThose ?? Mereka menentukan kedalaman antrian untuk adaptor pvscsi itu sendiri. Setiap halaman memberikan 32 slot dalam kedalaman antrian adaptor. Secara default, requestringpages adalah 8 untuk kedalaman antrian adaptor 256. Ini dapat ditetapkan setinggi 32 untuk 1024 slot kedalaman antrian adaptor.
Katakanlah semuanya default. Saya punya 8 file fisik dengan file baris pada mereka, dan SQL Server sedikit sibuk. Ada rata-rata 32 "panjang antrian disk saat ini" di 8, dan tidak ada yang lebih tinggi dari 64 (semuanya cocok dalam berbagai antrian layanan perangkat). Hebat - yang menghasilkan 256 OIO. Cocok dengan antrian layanan perangkat, cocok dengan antrian layanan adaptor sehingga semua 256 membuatnya keluar dari tamu untuk antrian di tingkat host ESX.
Tapi ... jika semuanya menjadi sedikit lebih sibuk, jadi rata-rata 64 dengan beberapa antrian disk fisik setinggi 128. Untuk perangkat yang memiliki lebih dari 64 yang beredar, kelebihan penggunaan berada dalam antrian tunggu. Jika lebih dari 256 ada dalam antrian layanan perangkat di 8 fisikdisk, kelebihan ada di antrian tunggu sampai slot di antrian layanan adaptor terbuka.
Dalam hal ini, menambahkan vHBA pvscsi lain dan menyebarkan disk fisik di antara mereka menggandakan kedalaman antrian adaptor total menjadi 512. Lebih banyak io dapat diteruskan dari tamu ke tuan rumah pada saat yang sama.
Hal serupa dapat dicapai dengan tetap menggunakan satu adaptor pvscsi dan meningkatkan halaman requestring. Pergi ke 16 akan menghasilkan 512 slot, dan 32 menghasilkan 1024 slot.
Jika memungkinkan, saya sarankan untuk melebar (menambahkan adaptor) sebelum masuk lebih dalam (meningkatkan kedalaman antrian adaptor). Tapi ... pada banyak sistem tersibuk, harus melakukan keduanya: menempatkan 4 vHBas pada tamu, dan meningkatkan halaman requestring menjadi 32.
Ada banyak pertimbangan lain juga. Hal-hal seperti sioc dan adaptive depth throttling jika vmdks digunakan, konfigurasi multipathing, konfigurasi adaptor ESXi di luar kedalaman antrian LUN, dll.
Tapi saya tidak ingin memperpanjang sambutan saya :-)
Lonny Niederstadt @sqL_handLe
