Memperkirakan Persyaratan IO untuk Penggunaan Bursty

Kami memiliki aplikasi yang menanyakan basis data SQL secara berkala sepanjang hari. Ada periode nol atau hanya aktivitas ringan, diselingi dengan permintaan individu untuk jumlah data yang relatif besar. Ketika permintaan itu masuk, tujuan utama adalah untuk mengirimkan data dengan cepat, dan tujuan kedua adalah melakukan hal itu secara efektif. Karena sifat aplikasi, sangat tidak mungkin bahwa data / indeks akan di-cache dalam RAM dari permintaan sebelumnya (pengguna yang berbeda, bekerja pada bagian data yang berbeda).

Untuk sistem yang mengalami penggunaan yang relatif stabil, saya telah mendengar aturan praktis untuk mengamati panjang antrian disk dan menjaga jumlah itu relatif kecil. Ini secara khusus akan berjalan di AWS, di mana saya telah melihat aturan praktis bahwa panjang antrian disk 1 per 100 IOPS masuk akal.

Bagaimana saya bisa memperkirakan persyaratan IO untuk sistem seperti itu? Apakah panjang antrian disk merupakan indikator yang dapat diandalkan saat menangani kueri individual yang bursty? Apakah ada metrik lain yang harus saya pertimbangkan?

sql-server performance

— Eric J.
sumber

Apakah ada penulisan yang sedang berlangsung, atau ini sudah baca-berat?

— Jack bilang coba topanswers.xyz

@JackDouglas: Ini adalah 98% dibaca. Ada setitik tulisan.

— Eric J.

Pertanyaan selanjutnya: apakah bacaan tersebar atau "permintaan individu Anda untuk jumlah data yang relatif besar" cenderung melakukan IO berurutan?

— Jack bilang coba topanswers.xyz

@JackDouglas: Pembacaan terbesar adalah melalui tampilan yang diindeks, sehingga klausa WHERE sesuai dengan indeks, tetapi mengembalikan lebih banyak data daripada apa yang ada di indeks. Saya tidak yakin apa artinya untuk tingkat IO berurutan. Karena subsistem IO yang mendasarinya adalah AWS EBS, saya tidak yakin bagaimana itu berdampak pada akses fisik.

— Eric J.

Subsistem IO yang mendasarinya akan mempengaruhi konsistensi kinerja , tetapi akan peduli tentang akses berurutan v yang tersebar dengan cara yang mirip dengan penyimpanan lokal. Bacaan besar itu, berapa banyak blok berbeda yang biasanya mereka tekan? Pemindaian indeks itu sendiri akan berurutan tetapi akses tabel tidak akan jika saya mengerti Anda dengan benar sejauh ini.

— Jack bilang coba topanswers.xyz

Metrik utama yang selalu saya pertimbangkan untuk IO di SQL Server bukanlah IOP atau Panjang Antrian Disk, tetapi throughput disk (dtk / baca dan dtk / tulis). Secara keseluruhan, basis data bukan tentang berapa banyak operasi yang dapat Anda lemparkan ke disk, tetapi seberapa cepat operasi tersebut selesai. Aturan umum adalah memiliki kurang dari 20 ms / operasi (meskipun lebih rendah selalu lebih baik). Detail lebih lanjut dapat ditemukan di artikel ini .

Panjang Antrian Disk adalah stat palsu dan tidak lagi relevan. Masalahnya adalah bahwa nilainya mengukur antrian untuk satu drive, tetapi sekarang kita hidup di zaman RAID, SAN, dan penyimpanan terdistribusi lainnya, tidak ada cara untuk menerjemahkan nilai ini dengan benar ke angka yang berarti. Tempat awal yang bagus untuk metrik kinerja adalah poster dari Quest / Dell ini yang memberi Anda banyak hal dan penjelasan mengapa atau mengapa itu tidak penting. Anda tidak harus menggunakan semuanya, tetapi itu adalah permulaan.

Untuk menguji IO Anda, Anda harus memahami beban kerja Anda pada puncaknya. Berapa banyak transaksi dan berapa banyak yang di-cache? Kecuali Anda tahu dan telah mengukur ini, sangat sulit untuk menilai. Anda bisa membuat beban kerja dan menggunakan alat-alat seperti SQLIO untuk menguji penyimpanan Anda, tetapi Anda akan membutuhkan pola beban kerja untuk membangun tes yang tepat.

Akhirnya, catatan tentang AWS: Setahu saya, Amazon tidak akan menjamin kinerja IO di AWS. Ini terutama karena penyimpanan adalah sumber daya bersama yang besar dan tidak mungkin untuk mengukur pola Anda dan tetangga Anda pada area penyimpanan tertentu (lihat masalah Noisy Neighbor ).

Rekomendasi saya adalah mengalokasikan memori sebanyak mungkin. SQL Server hanya akan mendorong hal-hal keluar dari memori jika berada di bawah tekanan dan ruang di buffer pool (berdasarkan LRU-K). Jadi jika Anda buffer pool dapat menyimpan sebagian besar database dalam memori, Anda dapat mengurangi beberapa kinerja yang meledak-ledak. Juga, pertimbangkan taktik yang dapat membuat objek cache "hangat". Akhirnya, awasi SQL 2014 dan fitur Hekaton baru .

— Mike Fal
sumber

"SQL Server hanya akan mendorong hal-hal keluar dari memori jika berada di bawah tekanan" atau di pos pemeriksaan ?

— Jack bilang coba topanswers.xyz

Pos pemeriksaan tidak menghapus objek dari buffer, tetapi menulis halaman kotor ke disk untuk pemulihan. Itu masih akan mempertahankan objek di kolam penyangga.

— Mike Fal

Terima kasih atas jawaban terincinya. AWS sekarang memiliki fitur premium yang disebut IOPS Provisioned yang memastikan bahwa jumlah operasi IO yang dibeli per detik dapat dilakukan 99,9% dari waktu. Saya pikir operasi IO didefinisikan sebagai membaca atau menulis blok data 16K.

— Eric J.

@ MikeFal: Apakah Anda memiliki pemikiran tentang metodologi pengujian khusus untuk pola bursty ini? Cukup jalankan satu permintaan dan saksikan konter yang dimaksud? Jalankan sejumlah kueri (biasanya periodik) satu demi satu, mengawasi penghitung?

— Eric J.

Ya, saya kenal dengan PIOPS. Seperti yang saya nyatakan, saya tidak ingin tahu berapa banyak operasi yang dapat dilakukan, saya ingin tahu seberapa cepat mereka. Dan ini bukan sesuatu yang bisa dijamin oleh AWS, bahkan pada PIOP.

— Mike Fal