persyaratan memori umum untuk sql server 2008 r2

11

Saya tidak berpengalaman dengan pekerjaan DBA, tapi saya mencoba membuat kasus untuk meminta sumber daya tambahan untuk server sql kami dan berharap saya bisa mendapatkan beberapa orang pintar untuk memberikan perkiraan kasar kasar tentang apa yang harus kita jalankan. Saya mencurigai bahwa alokasi sumber daya yang telah diberikan TI ke server sql produksi kami rendah.

Perangkat keras Perangkat Lunak:

Database: sql server 2008 r2 database perusahaan

Windows: Windows 2008 r2 Enterprise 64 bit, cukup yakin berjalan di VMware.

Prosesor: Intel (R) Xeon (R) CPU E7-4860 @ 2.27GHz 2.26 GHz (2 prosesor)

Memori yang dipasang: 4GB

Hard drive untuk file Database: 300GB

Hard drive untuk cadangan: 150GB

Hard drive untuk log: 100GB

Aplikasi:

Kami memiliki 3 database utama yang menambahkan hingga sekitar 170GB dalam data, database Layanan Pelaporan (SSRS) pada server yang sama yang menampung 10 laporan berbeda (masing-masing terdiri dari rata-rata 700 ribu catatan) yang dihasilkan setiap hari. Basis pengguna kami adalah sekitar 20 pengguna secara simultan, mungkin 5 di antaranya dapat dianggap "intensif sumber daya" dengan menghasilkan laporan besar yang mengelompokkan data. Mayoritas pengguna berinteraksi dengan database melalui situs web asp.net dan situs web server Laporan. Selain itu, pengembang kami menggunakan SSIS dalam BIDS secara luas dengan mengirim ulang langsung ke server (maksimum 2 koneksi jarak jauh). Akhirnya, kami memiliki operasi pergudangan data yang cukup terlibat yang mungkin membawa 3 juta catatan per hari melalui paket SSIS yang juga berjalan di server.

Masalah saat ini:

Kami memiliki batas waktu server terputus yang kronis dan waktu respons ke situs web sangat buruk. Saya menduga jumlah memori yang kita miliki (4GB) mungkin merupakan hambatan besar. Permintaan kami sebelumnya untuk memori tambahan telah ditolak dengan respons umum bahwa kami perlu melakukan lebih banyak optimasi kueri. Meskipun kami bukan pro sql atau (karena saya yakin Anda dapat mengetahui dari pengaturan kami) db admin pro, saya ingin memastikan bahwa saya tidak menghabiskan semua waktu saya mencoba untuk memeras sedikit potensi kinerja jika perangkat keras adalah kemacetan.

Terima kasih semua atas penghindaran dr!

RMuesi
sumber
7
Mereka berharap dapat melayani data 170 GB dengan memori 4 GB? Tidak ada pencarian nada yang akan memperbaikinya, dan mereka keluar dari pohon mereka.
Aaron Bertrand
Tunjukkan angka-angkanya (statistik kinerja). Anda juga bisa menunjukkan kepada mereka dokumentasi Microsoft yang menunjukkan memori minimum untuk Window Server 2008 R2, adalah 4GB; ini tidak meninggalkan banyak untuk SQL Server.
2
Apa yang ditunjukkan oleh statistik tunggu Anda? Saya menduga Anda melihat banyak PAGEIOLATCH_XX menunggu pertanyaan Anda. Jika ya, Anda mungkin dapat menggunakannya sebagai bukti bahwa beberapa memori tambahan akan bermanfaat.
SQLRockstar
2
Dan jika Anda memiliki memori, Anda dapat mulai bekerja pada subsistem IO yang lebih baik. Hard DRIVE untuk database yang digunakan dengan baik adalah lelucon IOPS. Itu harus DRIVES. Anda tidak membeli drive sebagai kapasitas, untuk database Anda membeli drive sebagai sumber IOPS. Yang artinya SSD 512GB akan lebih baik untuk file database. Standar "mari membuatnya besar dan murah" akan mematikan basis data.
TomTom
@ TomTom Saya yakin (saya harap) kami memiliki array serangan. Saya tidak yakin bagaimana cara mendeteksi itu. Saya hanya mendasarkan deskripsi hard drive pada apa yang ditampilkan windows explorer di server windows.
RMuesi

Jawaban:

14

... berharap aku bisa mendapatkan ... perkiraan kasar tentang apa yang harus kita jalankan.

Tanpa informasi lebih lanjut tentang kueri dan ukuran data Anda, sangat sulit untuk memberi Anda segala jenis perkiraan, apalagi perkiraan yang akurat.

Database: sql server 2008 r2 database perusahaan

Windows: Windows 2008 r2 Enterprise 64 bit, cukup yakin berjalan di VMware.

Prosesor: Intel (R) Xeon (R) CPU E7-4860 @ 2.27GHz 2.26 GHz (2 prosesor)

Memori yang dipasang: 4GB

Dua prosesor (saya berasumsi ini terpapar dalam VM sebagai 2 core) mungkin atau mungkin tidak sesuai ketentuan. Core yang ditugaskan untuk VM tidak harus dipetakan langsung ke core fisik (atau bahkan diizinkan untuk menggunakan 100% dari satu core ketika dibutuhkan!), Jadi Anda mungkin menemukan ini adalah sumber daya yang lebih fleksibel daripada memori. Tanpa ada informasi lebih lanjut tentang beban kerja atau konfigurasi hardware / virtualisasi, saya akan mengatakan meningkatkan ini ke 4 akan menyenangkan untuk dimiliki.

Alokasi memori. Oh Boy. Ini terlalu kekurangan bekal untuk beban kerja. Windows itu sendiri membutuhkan minimal 2-3 GB untuk tetap bahagia, dan masing-masing dari 2 pengguna yang menjalankan BIDS pada kotak akan membutuhkan setidaknya masing-masing 500 MB. Dan dengan itu, kotak sudah maksimal, dan saya bahkan tidak mulai mencari tahu berapa banyak database yang akan dibutuhkan.

Mayoritas pengguna berinteraksi dengan database melalui situs web asp.net dan situs web server Laporan.

Anda tidak mengatakan, tetapi jika ini berjalan pada kotak yang sama, persyaratan memori untuk mereka juga perlu diperhitungkan.

Akhirnya, kami memiliki operasi pergudangan data yang cukup terlibat yang mungkin membawa 3 juta catatan per hari melalui paket SSIS yang juga berjalan di server.

Dengan asumsi ini berjalan pada malam hari ketika tidak ada pengguna langsung pada sistem, saya tidak melihat ini sebagai masalah kecuali butuh waktu terlalu lama untuk berjalan. Bagian dari hal ini adalah yang paling tidak Anda khawatirkan; pengguna langsung lebih penting.

Permintaan kami sebelumnya untuk memori tambahan telah ditolak dengan respons umum bahwa kami perlu melakukan lebih banyak optimasi kueri.

Seperti yang saya tunjukkan di atas, jumlah memori saat ini yang telah disediakan sama sekali tidak memadai. Namun, pada saat yang sama, di ujung lain dari spektrum, sangat tidak mungkin Anda bisa mendapatkan cukup memori yang disediakan untuk dapat menyimpan seluruh database dalam memori sekaligus.

Meskipun Anda mendapatkan tanggapan menyeluruh seperti itu (yang, omong-omong, mungkin lebih berkaitan dengan seberapa persuasif justifikasi Anda terhadap sumber daya tambahan, dan bukan penggunaan sumber daya yang sebenarnya itu sendiri), sangat mungkin efisiensi database dapat ditingkatkan. Namun tidak ada jumlah penyetelan yang dapat memperbaiki masalah yang Anda alami sekarang; saran itu adalah non-starter lengkap bagi saya.

Saya akan mengambil pendekatan keseluruhan bahwa jumlah memori yang saat ini disediakan di bawah minimum yang diperlukan (yang harus diperbaiki secepatnya), dan sumber daya tambahan mungkin diperlukan untuk meningkatkan pengalaman pengguna ke tingkat yang dapat digunakan sementara perbaikan dilakukan untuk meningkatkan efisiensi sistem.

Berikut adalah beberapa pemikiran (dalam urutan serangan):

  • Anda akan menang jika Anda dapat membuktikan seberapa banyak kinerja meningkat setiap kali Anda mendapatkan lebih banyak sumber daya yang disediakan. Melacak metrik kinerja menggunakan pencatatan Monitor Kinerja (catatan: bagian pencatatan sangat penting), termasuk waktu respons situs web jika Anda bisa. Mulailah melakukan ini sekarang , sebelum melakukan hal lain. Ketika Anda akhirnya mencapai jumlah minimum memori (Anda tidak akan mendapatkan 32 GB segera), tiba-tiba Anda sekarang memiliki bukti bahwa memori yang ditambahkan meningkatkan hal-hal ... yang berarti menambahkan lebih banyak lagi mungkin akan membantu juga! Jika Anda tidak mengumpulkan garis dasar pada konfigurasi saat ini, Anda akan ketinggalan perahu ketika segala sesuatunya mencapai tingkat minimum yang disarankan.

  • Analisis statistik tunggu server Anda . Ini akan memberi tahu Anda apa hambatan terbesar dalam sistem. Anda mungkin memiliki PAGEIOLATCH_XXwaktu tunggu yang paling umum / tertinggi, yang menunjukkan terlalu banyak I / O yang dilakukan untuk mengambil halaman dari disk. Ini dapat dikurangi dengan menambahkan memori, sehingga I / O fisik menjadi kurang sering karena data yang diperlukan sudah ada dalam memori. Meskipun analisis ini adalah kesimpulan yang sudah pasti, fakta bahwa Anda telah mengumpulkan statistik ini sama sekali memberi Anda lebih banyak amunisi ketika membenarkan kebutuhan akan sumber daya.

  • Seperti yang saya sebutkan di atas, persyaratan minimum untuk memori tidak terpenuhi. Kumpulkan serangkaian persyaratan perangkat keras yang disarankan untuk semua perangkat lunak yang Anda jalankan, dan mungkin juga ambil tangkapan layar dari Task Manager. Ini saja harus cukup untuk membenarkan setidaknya 4-8 GB lebih, di tempat. Jika mereka masih menolak, cobalah meyakinkan mereka untuk mengizinkan Anda mencobanya selama seminggu, dan berikan kembali setelah itu (Anda mengumpulkan statistik kinerja, jadi Anda tidak perlu mengembalikannya karena pada pertengahan minggu Anda ' Saya akan dapat membuktikan seberapa banyak itu memperbaiki situasi). Jika mereka masih menolak, Anda diatur untuk gagal; URLT .

  • Jika Anda dapat membebani sebagian dari beban kerja (khususnya, hindari remoting jika memungkinkan), ini akan meningkatkan jumlah memori yang tersedia untuk database, yang lebih penting.

  • Anda tidak akan dapat memasukkan seluruh database ke dalam memori sekaligus, yang berarti Anda perlu mengatur pengaturan memori maks SQL Server dengan sangat hati-hati untuk mencegah memori berlebih , yang membunuh kinerja seperti tidak ada yang lain . Komit berlebihan sebenarnya lebih buruk daripada tidak bisa memasukkan semua data dalam memori. Sangat mungkin Anda berada dalam skenario ini sekarang hanya karena tidak ada memori sama sekali, dan kemungkinan pengaturan memori maks diatur ke default (tidak terbatas).

  • Karena Anda menjalankan SQL Server Enterprise Edition, dan memori sangat mahal, saya akan sangat mempertimbangkan untuk menerapkan kompresi data . Ini akan mengurangi peningkatan penggunaan CPU untuk menghemat ruang memori (dan karenanya mengurangi akses disk, yang relatif sangat lambat).

  • Tune basis data. Kemungkinan struktur dan kueri dapat menggunakan peningkatan sejauh pengindeksan dan pola akses. Juga, jika banyak data yang sering dipindai dan dikumpulkan, membuat tampilan yang diindeks, tabel ringkasan, atau laporan yang dikomputasi mungkin sangat membantu.

  • Ini mungkin merupakan dampak yang panjang karena mungkin berarti lebih banyak penyediaan perangkat keras, tetapi menerapkan solusi caching. Permintaan tercepat adalah yang Anda tidak pernah buat .

Itu hanya beberapa ide. Intinya adalah bahwa menyetel saja tidak akan menyelesaikan masalah di sini, juga tidak akan perangkat keras sendiri, meskipun yang terakhir mungkin akan meringankan sebagian besar masalah langsung. Begitulah caranya: melempar perangkat keras pada masalah dalam jangka pendek untuk memadamkan api, dan melempar tuning pada masalah dalam jangka panjang untuk memperbaiki akar penyebabnya sebaik mungkin.

Jon Seigel
sumber
1
John Saya suka jawaban Anda dan +1 tetapi dalam skenario ini, sepertinya komentar Harun memukulnya di kepala dan mereka hanya perlu lebih banyak ram, tidak peduli seberapa keras mereka berusaha untuk menyetelnya.
Ali Razeghi
2
@ Ali: Ya, saya setuju, dan saya menyebutkannya dalam jawaban saya. Sebagian besar saya ingin fokus pada strategi untuk mendapatkan lebih banyak RAM, karena itu sepertinya masalah di sini. (Jika tidak tersedia, itu masalah tersendiri.)
Jon Seigel
Terima kasih banyak atas jawaban terperinci! Saya baru mengenal penyetelan kinerja db jadi saya hanya mencoba memahami dari mana memulainya. Saya memiliki beberapa bahan bacaan dan Monitor Kinerja, sekarang saya baru saja memahami metriknya. Tetapi saran Anda memberikan peta jalan yang baik untuk mendekati masalah ini. Terima kasih lagi.
RMuesi
@RMuesi: Sama-sama. Jika Anda memiliki pertanyaan spesifik tentang bagaimana mencapai apa yang perlu Anda lakukan, jangan ragu untuk mempostingnya (silakan cari dulu, tentu saja) dan komunitas akan dengan senang hati membantu.
Jon Seigel
9

Ini adalah akun gila 'penghitung kacang'. $ 1100 - $ 2500 yang akan Anda belanjakan untuk RAM mungkin dapat membayar sendiri kembali dalam waktu seminggu !

Mereka mendapatkan waktu menyendiri untuk 20 karyawan dan 5 dari mereka melakukan pekerjaan 'intensif sumber daya'. Saya membayangkan waktu mereka tidak murah, dan beberapa dari laporan-laporan itu adalah yang tidak disukai oleh bos pada gaji. Itu ton menghabiskan terbuang transmisi ulang dan berurusan dengan frustrasi.

Jelaskan kepada mereka bahwa mereka mungkin mencari RAM $ 15 - $ 20. 128GB RAM akan menjadi sekitar $ 2200 - $ 2500 sekarang, dan harga RAM saat ini telah naik sedikit. Bahkan jika motherboard server Anda tidak dapat mendukungnya (itu akan aneh), maka 64GB akan menjadi $ 1.100 - $ 1.200 (saya baru memeriksa, dan itu adalah kualitas server ram dari Dell tanpa diskon yang berlaku). Bahkan 64GB ram bisa membuat perbedaan BESAR (khususnya jika kita memastikan untuk menghindari pemindaian tabel pada tabel besar).

Cari tahu berapa banyak waktu yang terbuang, dan tanyakan kepada mereka apakah nilainya $ 1.100 - $ 2500. Jika Anda hanya menghabiskan $ 1.100 dan mendapatkan ram 64GB, pastikan untuk menghindari pemindaian tabel pada tabel besar. Gunakan lebih banyak disk dengan indeks (jika Anda memiliki latensi untuk mendukungnya) untuk menghindari memori dump pemindaian yang besar.

Ali Razeghi
sumber
5
Dikatakan baik untuk kegilaan. Memori 4GB kurang dari yang saya sarankan hari ini untuk desktop. Dan itu sekarang sedang mencoba untuk berjalan di lingkungan basis data 170GB. Lelucon sial. Tapi hei, virtualisasi untuk beancounters berarti Anda dapat menyingkirkan server mahal yang besar;)
TomTom
2
Sangat setuju. Setidaknya penghitung kacang dalam skenario OPs memiliki cakar mereka diambil dari server fisik (semoga!)
Ali Razeghi
1
percaya itu. Bukan saya. TIPIS akan menjadi server dengan banyak RAM dan - LAAAAARGE disc murah. Jadi Anda dapat menjalankan BANYAK mesin virtual pada mereka. Lagi pula, RAM biasanya merupakan faktor pembatas, bukan?)? Hasilnya akan menjadi kinerja IOPS yang mengerikan - bahkan tanpa database. Pernah ke sana, melihat itu. Memori 64GB, 2tb mencerminkan disk SATA;)
TomTom
Terima kasih atas jawabannya. Saya menduga sebanyak tetapi tidak memiliki data untuk membuktikan masalah ini sebagian imitasi perangkat keras. Saya sedang mengerjakan itu sekarang.
RMuesi
2
Anda mungkin ingin memberi tahu mereka bahwa SQL Server adalah mesin basis data memori. Membaca dari disk, bahkan SSD (yang saya yakin toko ini tidak menggunakannya) sangat lambat. Pembacaan dari RAM memakan waktu sekitar 5ns. Tunjukkan pada mereka rencana eksekusi dengan SET STATISTICSIO ON yang menampilkan pemindaian dan pembacaan tabel. Tunjukkan pada mereka bacaan fisik vs bacaan logis. Fisik dilakukan dari disk.
Ali Razeghi
-1

Saya menjalankan 2008 R2 dengan 46GB Ram. Tidak ada mesin virtual. SQL Server 2008.

Database sekitar 300GB.

Saya menempatkan basis data pada solid state drive baru-baru ini dan melipatgandakan output data saya.

Server saat ini menggunakan Ram 45GB dan berjalan dengan baik.

FC Sata Razia dan SAS SCSI Razia. 26 drive logis di semua. 144 Memutar disk.

Kemarin saya hanya menggunakan ram 24GB ketika saya hanya memiliki 50TB hard drive penuh yang terhubung dan mentransfer data. Hari ini saya memiliki 160TB hard drive penuh dan saya menggunakan ram 45GB.

Aplikasi saya tidak menggunakan lebih dari 400MB ram.

Saya menduga Anda membutuhkan database pada solid state drive atau ram drive yang cepat. Meskipun pada dasarnya Anda membutuhkan lebih banyak ram.

David
sumber
IBM exFlash 400GB MCS $ 4400. Itu tujuan saya.
david