Fokus utama situs blog ini adalah kinerja di lingkungan SQL Server. Orang bisa berargumen bahwa kinerja dimulai dengan database dan desain aplikasi. Tetapi Anda juga dapat menyatakan bahwa ketersediaan sumber daya yang tepat sangat penting untuk kinerja yang baik. Untuk semua diskusi tentang sumber daya yang tepat (model CPU apa, berapa banyak memori, jenis penyimpanan apa), terkadang kita mengabaikan tindakan perencanaan kapasitas:menggunakan data yang kita miliki untuk membuat keputusan yang tepat tentang apa yang butuhkan . Perencanaan kapasitas tidak hanya mencari tahu berapa banyak ruang disk yang kita butuhkan, tetapi juga melibatkan sumber daya yang harus dimiliki oleh instance SQL Server untuk menangani beban kerja.
Baru atau Sudah Ada?
Perencanaan kapasitas untuk solusi baru benar-benar rumit. Anda harus membuat perkiraan tentang beban kerja berdasarkan informasi yang Anda kumpulkan dari bisnis. Ini berarti Anda harus mengajukan pertanyaan sulit tentang berapa banyak data yang mereka harapkan di bulan pertama, enam bulan pertama, dan tahun pertama. Ketika solusi baru datang, ini sering kali merupakan hal TERAKHIR yang dipikirkan bisnis, sehingga sangat sering Anda akan mendapatkan jawaban yang tidak jelas. Dalam hal solusi baru, Anda benar-benar telah melakukan upaya tebakan terbaik. Jangan menarik rambut Anda untuk mendapatkan angka pasti.
Jika solusinya berasal dari vendor, Anda harus meminta rekomendasi perencanaan vendor tentang ruang yang dibutuhkan dan sumber daya yang dibutuhkan. Saya akui, mereka mungkin tidak memiliki data itu, tetapi Anda tidak mendapatkan apa yang tidak Anda minta. Tidak ada salahnya untuk mencoba.
[Bonus:Jika vendor tidak memiliki informasi apa pun untuk diberikan, bukankah akan membantu jika, setelah sistem aktif dan berjalan selama beberapa bulan, Anda mengirimkan data Anda…seperti perangkat keras apa yang Anda miliki , dan seperti apa beban kerjanya? Itu tidak harus berupa tulisan 20 halaman, tetapi umpan balik mungkin mendorong mereka ke arah yang lebih proaktif ke depannya.]
Dalam hal solusi yang ada, jika Anda mengalami masalah kinerja atau ingin mengupgrade perangkat keras, sebaiknya ambil informasi tentang lingkungan saat ini untuk merencanakan yang baru.
Penyimpanan
Merencanakan jumlah penyimpanan yang dibutuhkan cukup sederhana, hanya memerlukan beberapa perencanaan di muka. Dalam artikel pemeriksaan kesehatan SQL Server proaktif saya, saya membahas pemantauan ruang disk dan menyertakan kueri untuk menangkap informasi file. Kueri ini menangkap ukuran file database untuk instance serta ruang yang digunakan. Sangat penting untuk membuat tren data ini dari waktu ke waktu, dan itu tidak berarti beberapa minggu. Anda ingin melihat bagaimana file berubah selama berbulan-bulan, mungkin hingga satu hingga dua tahun, karena pola penggunaan untuk suatu aplikasi dapat berubah. Informasi ini mudah ditangkap, membutuhkan sedikit ruang untuk disimpan, dan sangat berharga untuk dimiliki sebagai referensi saat Anda membeli penyimpanan. Jika Anda dapat memberikan data kuantitatif tentang pertumbuhan sistem, maka Anda memiliki peluang yang jauh lebih baik untuk mendapatkan ruang yang Anda butuhkan di muka daripada harus memintanya nanti. Dan saat Anda meminta ruang, pastikan untuk menyertakan tempdb dalam perhitungan Anda.
Sumber Daya Perangkat Keras
CPU
Mengoptimalkan kinerja CPU Anda bukan hanya tentang jumlah CPU yang Anda miliki, Anda juga harus mempertimbangkan model dan beban kerja (misalnya gudang data dengan kueri paralel yang besar vs. OLTP dengan kueri serial). Dengan informasi ini, dan sedikit bantuan dari Glenn, Anda dapat menentukan prosesor terbaik untuk server Anda. Jangan lupa untuk mempertimbangkan biaya dan batasan lisensi berdasarkan edisi SQL Server Anda!
Memori
Memori relatif murah dan merupakan rekomendasi kami untuk selalu membeli jumlah memori maksimum yang dapat ditampung oleh server. Membaca data dari memori secara signifikan lebih cepat daripada membacanya dari disk, jadi semakin banyak data yang masuk ke memori semakin baik. Perhatikan bahwa seluruh database tidak memiliki agar sesuai dengan memori. Anda hanya perlu set data yang berfungsi agar sesuai dengan memori. Pertimbangkan database 2TB. Kecil kemungkinannya, dalam skenario OLTP, semua 2TB diakses setiap hari. Biasanya hanya data terbaru yang diakses – mungkin hanya dalam 30 atau 60 hari terakhir. Itu adalah data yang perlu masuk ke dalam memori. Tapi tentu saja, jarang kita melihat lingkungan OLTP murni, seringkali lingkungan campuran karena pengguna suka menjalankan laporan pada kumpulan data yang besar, dan tidak ada gudang data atau salinan pelaporan database sehingga mereka memiliki untuk menjalankan laporan terhadap produksi. Ini memperumit kebutuhan memori. Sekarang, terkadang Anda membutuhkan data lama itu di memori, tetapi terkadang tidak. Penting untuk memahami beban kerja; jenis kueri apa yang dijalankan terhadap database?
Jika Anda menggunakan Edisi Standar, pastikan Anda memiliki lebih banyak memori di server daripada memori maksimum yang didukung. Misalnya, dengan SQL Server 2014 dan yang lebih tinggi, di Edisi Standar, jumlah maksimum memori yang dapat Anda alokasikan ke kumpulan buffer (melalui pengaturan memori server maks) adalah 128 GB. Oleh karena itu, Anda ingin memiliki lebih banyak memori di server (misalnya 160GB) sehingga Anda dapat mengatur memori server maksimal pada nilai tertinggi 128GB, dan masih memiliki memori yang tersedia untuk OS dan proses SQL Server lainnya. Selanjutnya, dengan SQL Server 2016 SP1 Standard Edition Anda dapat menggunakan In-Memory OLTP, dengan batas 32GB per database. Ini di atas nilai memori server maksimal, jadi jika Anda berencana menggunakan fitur ini, beli memori yang sesuai.
Penyimpanan
Ketika kita berbicara tentang persyaratan kinerja untuk penyimpanan, Anda sering mendengar orang berbicara tentang IOPS (operasi input/output per detik). Sebenarnya, artikel ini terinspirasi oleh pertanyaan dari pemirsa yang menonton kursus Pluralsight saya tentang Benchmarking dan Baselining. Pertanyaannya adalah:"Bagaimana Anda menghubungkan penghitung Monitor Kinerja untuk membaca dan menulis per detik ke koneksi pengguna untuk memperkirakan jumlah IO per pengguna?" Membaca dan menulis per detik adalah operasi input/output, jadi kami memiliki data ini tersedia melalui PerfMon di tingkat instans, dan inilah yang Anda gunakan untuk menentukan persyaratan IOPS untuk sebuah instans.
Namun, jika Anda tahu membaca dan menulis dan koneksi pengguna, maka Anda dapat menghitung dan mencari tahu IOPS per pengguna. Ini berguna jika Anda berencana untuk mengembangkan solusi dan menambahkan lebih banyak pengguna. Anda ingin memastikan bahwa solusi akan diskalakan, dan satu opsi yang Anda miliki adalah mengambil IOPS terhitung per pengguna, berdasarkan jumlah pengguna X, lalu memperkirakan IOPS instans untuk jumlah pengguna Y. Sekarang, kami membuat banyak asumsi dengan perhitungan ini. Kami berasumsi bahwa cara koneksi baru menggunakan sistem sama seperti saat ini – yang mungkin atau mungkin tidak pada akhirnya, Anda tidak akan tahu sampai sistem terpasang. Saat Anda memahami nilai ini (baca + tulis / koneksi pengguna =rata-rata IOPS per pengguna), maka Anda tahu cara memperkirakan IOPS untuk solusi berdasarkan koneksi pengguna yang diantisipasi.
Anda kemudian membawa informasi ini ke petugas penyimpanan Anda untuk mendiskusikan konfigurasi potensial yang tersedia. Anda dapat menghitung IOPS maksimum untuk konfigurasi disk, asalkan Anda memiliki informasi tentang disk (misalnya jumlah disk, kecepatan, ukuran, dan konfigurasi RAID). Anda dapat menguji throughput IO untuk drive menggunakan CrystalDiskMark, meskipun ini mungkin tidak dapat dilakukan jika penyimpanan belum diputuskan. Namun, setelah terpasang, Anda harus menjalani pengujian ini untuk memastikan bahwa IOPS untuk drive tertentu dapat memenuhi beban kerja yang diharapkan.
IOPS hanyalah salah satu cara untuk melihat kinerja penyimpanan. Pahami bahwa data ini memberi tahu Anda berapa banyak IO yang terjadi, dan idealnya, jika Anda mengetahui IOPS dan Anda memiliki penyimpanan untuk memenuhi persyaratan, maka latensi harus minimal. Namun, latensilah yang memengaruhi kinerja. Untuk menentukan latensi apa yang ada, Anda harus menggunakan alat seperti DiskSpd untuk membandingkan penyimpanan. Glenn memiliki artikel bagus yang menjelaskan cara menganalisis kinerja IO, dan kemudian artikel lain tentang cara menggunakan DiskSpd untuk mengujinya guna memahami latensi. Saya sangat menyarankan untuk meninjau kedua artikel tersebut jika Anda belum pernah melihat penyimpanan dan kinerja sebelumnya.
Kesimpulan
Perencanaan kapasitas lebih dari sekadar mengetahui berapa banyak ruang yang Anda butuhkan untuk file database. Anda harus memahami beban kerja dan apa yang dibutuhkan dalam hal sumber daya CPU, memori, dan disk. Untuk melakukan ini, Anda memerlukan data… yang berarti Anda perlu menangkap baseline. Sesi pertama saya di komunitas SQL Server adalah pada bulan Desember 2010, dan itu tentang topik baseline. Enam tahun kemudian saya masih berbicara tentang pentingnya mereka, dan saya masih mendengar dari orang-orang bahwa mereka tidak memiliki angka-angka ini. Jika Anda ingin melakukan perencanaan kapasitas yang cerdas dan terarah, maka Anda perlu mengumpulkan data yang sesuai…jika tidak, Anda hanya menebak-nebak.
