SQL Server - Adakah yang menggunakan SUMA, trace flag 8048, atau trace flag 8015?


21

Baru-baru ini termasuk startup SQL Server Trace Flag 8048 untuk menyelesaikan masalah pertikaian spinlock serius dalam sistem SQL Server 2008 R2.

Tertarik untuk mendengar dari orang lain yang telah menemukan kasus penggunaan di mana nilai kinerja dikirimkan oleh jejak flag 8048 (mempromosikan strategi hibah memori permintaan dari node per-NUMA ke per-core), jejak flag 8015 (SQL Server mengabaikan NUMA fisik), atau SUMA ( interleaved akses memori yang cukup seragam, opsi BIOS pada beberapa mesin NUMA).

Trace flag 8048 http://blogs.msdn.com/b/psssql/archive/2011/09/01/sql-server-2008-2008-r2-on-newer-machines-with-more-than-8-cpus -disajikan-per-numa-simpul-mungkin-perlu-jejak-flag-8048.aspx

Trace flag 8015 http://blogs.msdn.com/b/psssql/archive/2010/04/02/how-it-works-soft-numa-io-completion-thread-lazy-writer-workers-and-memory -nodes.aspx

Detail berdarah tentang beban kerja sistem, metrik yang dikumpulkan dari sistem yang bermasalah, dan metrik yang dikumpulkan dari sistem setelah intervensi diikuti.

Bendera jejak 8048 adalah 'perbaikan', tetapi apakah itu perbaikan terbaik? Apakah SQL Server mengabaikan NUMA fisik karena jejak flag 8015 telah melakukan hal yang sama? Bagaimana dengan mengatur BIOS untuk menyisipkan memori, meninggalkan server dengan perilaku SUMA yang meniru SMP alih-alih perilaku NUMA?

Perdamaian! tw: @sql_handle


Tentang sistem: - 4 hex core Xeon E7540 @ 2.00GHz, hyperthreaded - 128 GB RAM - WS2008R2 - MSSQL 2008 R2 SP2 - maxdop 6


Tentang beban kerja: - 1000s dari laporan terjadwal / antrian Batch didorong dari 2 server aplikasi laporan. - 3 varian rasa: harian, mingguan, bulanan - Semua koneksi server aplikasi laporan ke SQL Server dibuat sebagai akun layanan tunggal - Konkurensi laporan maksimum = 90


Temuan utama pada sistem yang bermasalah: - Dari Perfmon, interval 15 detik - - Sistem tetap sibuk pada 95% -100% CPU - - Halaman penyangga SQL Server pencarian <10.000 per / detik

  • Dari DMV tunggu dan putar, interval 5 menit
    • Pelayan CMEMTHREAD tinggi dan waktu tunggu
    • SOS_SUSPEND_QUEUE tinggi berputar dan mundur

Postingan Blog Engineer Bob Dorr di flag flag 8048 menunjukkan bahwa sistem dengan lebih dari 8 core per NUMA node dapat mengalami gejala yang sama karena hambatan dalam permintaan memory grant. Bendera jejak 8048 akan mengubah strategi untuk per-inti, bukan per-NUMA node.


Intervensi

MSSQL telah dimulai kembali dengan -T8048 di tempatnya. Perbedaannya langsung terlihat: tingkat pencarian halaman buffer naik lebih dari 1 juta dan melonjak menjadi 8 juta per detik. Beban kerja batch bermasalah, yang sebelumnya tidak dapat diselesaikan dalam 24 jam, selesai dalam waktu kurang dari 4 jam. Beban kerja batch lain yang bukan fokus investigasi atau intervensi diajukan sebagai bagian dari memvalidasi nilai korektif bendera penelusuran 8048 (dan memastikan bahwa efek sampingnya yang tidak diinginkan minimal). Kumpulan laporan ini sebelumnya selesai dalam 2 jam; dengan tanda bendera 8048 di tempat kumpulan laporan selesai dalam sekitar 20 menit.

ETL Nightly juga menemui manfaat. Waktu ETL turun dari sekitar 60 menit menjadi 40 menit.

Menyatukan informasi dari beberapa tempat, saya berspekulasi bahwa tingginya tingkat antrian laporan, jumlah laporan bersamaan lebih besar daripada jumlah utas perangkat keras, dan akun pengguna tunggal untuk semua laporan digabungkan untuk memberikan tekanan pada satu NUMA node sampai tekanan utas pekerja menyebabkannya tidak disukai untuk permintaan koneksi masuk berikutnya untuk akun pengguna yang sama, pada titik mana NUMA node berikutnya akan mendapatkan sejumlah koneksi dekat secara instan. Setiap NUMA node akan berakhir dengan probabilitas tinggi menekankan kemacetan hibah memori permintaan.

Membuka lebih banyak jalur untuk permintaan memori permintaan menghilangkan hambatan. Tapi, saya tidak yakin biayanya. Posting CSS Bob Dorr memperjelas bahwa ada overhead memori tambahan dengan jejak flag 8048. Apakah overhead itu dalam wilayah pengalokasi satu halaman yang diatur oleh memori server maks MSSQL 2008 R2? Jika demikian, saya kira sistem hanya akan memiliki beberapa halaman basis data dalam cache pool buffer. Jika tidak, haruskah memori server maks diturunkan untuk mengakomodasi?

Jawaban:


12

Ini adalah pos yang luar biasa.

Untuk menjawab pertanyaan terakhir Anda, saya akan berspekulasi bahwa jawaban Anda adalah "ya".

Yang mengatakan, saya mungkin akan mengejar numa lunak sebelum beralih ke bendera jejak. Saya pikir Anda benar tentang alokasi numa node dan itu bisa menjadi akar masalah Anda. Melalui soft numa, Anda dapat mengurangi permintaan, tergantung pada jumlah node numa Anda (4?) - ke 4, jika itu angka yang benar, dan kemudian menetapkan, melalui alamat ip, masing-masing host ke node numa tertentu, selain itu untuk itu, saya akan menonaktifkan hyper threading. Digabungkan, masalah ini kemungkinan akan berkurang, namun, hal itu akan terjadi dengan biaya penjadwal yang lebih sedikit.

Pada pemikiran yang terpisah, saya akan melihat parameterisasi paksa - fakta bahwa beban Anda mengemudi CPU Anda begitu tinggi sangat menarik dan mungkin ada baiknya melihat ke dalamnya.

Terakhir, pada sistem multi-numa node, saya biasanya memiliki output dari query berikut ini ke tabel setiap N detik. Membuat beberapa analisis menarik ketika perubahan beban kerja atau tanda jejak diterapkan:

SELECT getdate() as poll_time, node_id, node_state_desc, memory_node_id, online_scheduler_count, active_worker_count, avg_load_balance, idle_scheduler_count
FROM sys.dm_os_nodes WITH (NOLOCK) 
WHERE node_state_desc <> N'ONLINE DAC'

dan

SELECT top 10 getdate() as sample_poll, wait_type, count (*)
FROM sys.dm_os_waiting_tasks
WHERE [wait_type] NOT IN
('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SLEEP_TASK','SLEEP_SYSTEMTASK',
'SQLTRACE_BUFFER_FLUSH','WAITFOR', 'BROKER_TASK_STOP',
'BROKER_RECEIVE_WAITFOR', 'OLEDB','CLR_MANUAL_EVENT', 'CLR_AUTO_EVENT' ) 
GROUP BY wait_type
ORDER BY COUNT (*) DESC

Terima kasih telah menyebutkan sys.dm_os_nodes dan sys.dm_os_waiting_tasks. Saya sedang menulis sejumlah prosedur tersimpan ke profil sistem aktvitas, pertama untuk mengejar baseline agak dioptimalkan, kemudian untuk melihat varians. Sekarang menangkap menunggu dan berputar, selanjutnya datanglah bantuan memori (termasuk dop per memori hibah) ... pelayan individu dan node berikutnya seperti yang Anda diskusikan ... kemudian mungkin ke pegawai memori dan penghitung cache ...
sql_handle

1
Counter lain yang menarik untuk dilihat adalah di perfmon: SQLServer: Buffer Node :. Penghitung dalam keluarga yang diminati adalah Halaman Asing, Halaman Gratis, Harapan Hidup Halaman, Halaman Total, Halaman Target, dan Halaman yang Dicuri. Saya menduga, bahwa sebelum Anda menerapkan tanda jejak, bahwa Anda memiliki jumlah halaman asing yang sangat tinggi - Apakah Anda mengaktifkan TF 834? Jika demikian, saya telah menemukan bahwa itu tidak mengalokasikan memori untuk setiap node numa secara seimbang yang mengarah ke jumlah yang sangat tinggi dari pencarian memori numa node remote mahal. Sistem yang saya gunakan untuk masalah ini mengandung 1TB ram pada saat itu.
Jeremy Lowell

poin bagus. Saya telah menonton metrik node buffer. Yang paling aneh adalah bahwa pada awalnya, simpul 00 tidak memiliki halaman asing, sedangkan node lain memiliki jumlah yang sangat besar. Saya pikir itu karena ETL kami melakukan buffer ramp up dengan jumlah thread yang cukup rendah agar sesuai sepenuhnya pada buffer node / NUMA node 00. Kami tidak memiliki flag flag 834 yang diaktifkan, tetapi akan segera mulai mengujinya. Pengujian beban kerja kami di Linux Oracle 11gR2 menunjukkan manfaat besar untuk memori halaman besar, saya pikir kita akan melihat keuntungan di Windows dengan SQL Server juga.
sql_handle

@Mike Soft NUMA vs TF 8048. Saya pikir NUMA lunak akan memungkinkan saya untuk membuat 'memory node' di dalam NUMA node. Jadi jika saya membuat NUMA lunak untuk setiap inti, akan ada (mungkin) ada 24 jalur untuk permintaan permintaan memori hibah. Tapi mungkin juga 24 node memori? Saya akan sedikit khawatir tentang overhead dalam mengelola 24 node memori dengan setiap inti membuat referensi halaman 'asing' setiap kali melintasi batas NUMA yang lembut, dan benar - benar referensi asing ketika melintasi batas untuk referensi halaman yang keduanya berbeda NUMA lunak dan NUMA keras. Saya akan bermain-main dan melihat apakah saya bisa membedakan apa pun.
sql_handle
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.