Peningkatan RAM, Performa Lebih Buruk

Mendirikan:

Windows Server 2008 R2
SQL Server 2008 R2 SP1
RAM 240GB
TempDB adalah file data 8x16GB tanpa tumbuh otomatis (total 128GB)
Server Fisik / Stand-alone

Server ini digunakan untuk pemrosesan ETL. Kami baru saja menginstal lebih banyak RAM di server ini untuk total 240GB RAM. Layanan SQL Server adalah satu-satunya hal nyata yang berjalan.

Memori muncul dengan baik di BIOS, OpenManage dan Windows.

Jika saya mengkonfigurasi SQL Server untuk menggunakan memori Min / Max 70 / 100GB, kami tidak memiliki masalah. Namun, begitu saya meningkatkannya menjadi 120 / 150GB, saya mendapatkan kesalahan berikut ketika saya menjalankan salah satu proses ETL kami:

Tidak dapat mengalokasikan ruang untuk objek '<objek sistem sementara: 422234507706368>' dalam database 'tempdb' karena filegroup 'PRIMER' sudah penuh. Buat ruang disk dengan menghapus file yang tidak dibutuhkan, menjatuhkan objek di filegroup, menambahkan file tambahan ke filegroup, atau mengatur autogrowth untuk file yang ada di filegroup. (Msg 1105, Status 2, Prosedur Tidak Diketahui, Baris 1)

Kami belum pernah mengalami masalah ini sebelum mengubah konfigurasi memori. Setelah mengkonfigurasi ulang kembali ke aslinya 70 / 100GB, kami tidak menerima kesalahan ini.

Hal yang sudah saya coba:

Atur file data TempDB ke tumbuh otomatis. Ini hanya menghasilkan file tumbuh otomatis sampai kapasitas disk tercapai dan kemudian gagal.
Tambahkan lebih banyak file data TempDB. Kesalahan yang sama seperti yang ditunjukkan.
Tambah ukuran TempDB ke 8x32GB (total 256GB)

Saya bingung apa yang bisa menyebabkan masalah ini.

sql-server sql-server-2008-r2 memory

— Derek Kromm
sumber

Apakah memori Anda seimbang di seluruh NUMA node? Bagaimana dengan prosesor Anda? Apakah log SQL Server menunjukkan berapa banyak CPU yang digunakan selama startup?

— Aaron Bertrand

Apa yang Anda gunakan untuk proses ETL? SSIS atau alat serupa? Jika itu adalah alat di luar SQL Server, apakah Anda menjalankannya di server yang sama dengan contoh SQL Server Anda?

— Mike Fal

Itu poin yang bagus @ Mike, jika proses ETL tidak dapat mengambil cukup memori untuk melakukan hal itu, karena SQL Server menggunakan terlalu banyak, maka mungkin harus mendorong pekerjaan ke tempdb.

— Aaron Bertrand

Berikut ini adalah permulaan yang baik untuk memantau penggunaan tempdb: msdn.microsoft.com/en-us/library/ms176029(v=SQL.105).aspx . Ini akan memberi Anda gambaran tentang apa yang terjadi.

— Thomas Stringer

Sudahkah Anda melakukan analisis tentang apa yang sebenarnya berjalan ketika Anda TempDB sebenarnya berkembang? Sp_who2 / sp_whoisactive sederhana? Bagi saya sepertinya Anda memiliki beberapa transaksi jangka panjang yang dapat dikelola dengan lebih baik, tetapi sulit untuk diceritakan. Secara pribadi, saya tidak akan terhubung dengan perubahan memori tetapi lihat dulu kodenya dan lihat apakah itu berjalan dengan baik.

— Mike Fal

Terimakasih untuk semua orang atas bantuannya.

Setelah menuangkan beberapa rencana eksekusi, ternyata ada GABUNG yang sedang diproses secara berbeda berdasarkan jumlah RAM yang tersedia. Dengan lebih sedikit RAM, ia mengevaluasinya dengan Hash; dengan lebih banyak RAM, ia menggunakan serangkaian Gabung Bergabung.

Jadi pada dasarnya itu datang ke T-SQL yang ditulis dengan buruk, yang saat ini saya refactoring.

— Derek Kromm
sumber

Itu cukup berlawanan dengan intuisi karena hash join membutuhkan memory grant sedangkan penggabungan tidak. Apakah ada operasi penyortiran tambahan untuk mendukung penggabungan gabung?

— Martin Smith

Ini bukan jawaban untuk pertanyaan, hanya beberapa kode yang tidak ingin saya poskan dalam komentar. Untuk melihat keseimbangan penjadwal dan memori Anda di seluruh NUMA node (dan juga untuk melihat apakah ada node yang tidak terlihat online):

SELECT 
  parent_node_id, 
  [status],
  AVG(current_tasks_count) AS avg_tasks_count, 
  AVG(load_factor) AS avg_load_factor,
  scheduler_count = COUNT(*)
FROM sys.dm_os_schedulers
GROUP BY parent_node_id, [status];

SELECT 
  memory_node_id, 
  name, 
  SUM(single_pages_kb + multi_pages_kb) AS memory_kb
FROM sys.dm_os_memory_clerks
GROUP BY memory_node_id, name;

(Dalam SQL Server 2012, yang terakhir SUMseharusnya SUM(pages_kb)karena tidak ada lagi pengalokasi halaman tunggal dan multi-halaman.)

— Aaron Bertrand
sumber