Apakah penonaktifan hyperthreading akan meningkatkan kinerja pada pemasangan SQL Server kami


28

Terkait dengan: Kebijakan terkini tentang SQL Server dan Hyperthreading

Baru-baru ini kami memutakhirkan server database Windows 2008 R2 kami dari X5470 ke X5560 . Teorinya adalah kedua CPU memiliki kinerja yang sangat mirip, jika apa pun X5560 sedikit lebih cepat.

Namun, kinerja SQL Server 2008 R2 telah sangat buruk selama beberapa hari terakhir dan penggunaan CPU telah cukup tinggi.

Harapan hidup halaman sangat besar, kami mendapatkan hit cache hampir 100% untuk halaman, jadi memori tidak menjadi masalah.

Ketika saya berlari:

SELECT * FROM sys.dm_os_wait_stats 
order by signal_wait_time_ms desc

Saya mendapatkan:

wait_type waiting_tasks_count wait_time_ms max_wait_time_ms signal_wait_time_ms
-------------------------------------------------- ---------- -------------------- -------------------- -------------------- --------------------
XE_TIMER_EVENT 115166 2799125790 30165 2799125065
REQUEST_FOR_DEADLOCK_SEARCH 559393 2799053973 5180 2799053973
SOS_SCHEDULER_YIELD 152289883 189948844 960 189756877
CXPACKET 234638389 2383701040 141334 118796827
SLEEP_TASK 170743505 1525669557 1406 76485386
LATCH_EX 97301008 810738519 1107 55093884
LOGMGR_QUEUE 16525384 2798527632 20751319 4083713
WRITELOG 16850119 18328365 1193 2367880
PAGELATCH_EX 13254618 8524515 11263 1670113
ASYNC_NETWORK_IO 23954146 6981220 7110 1475699

(10 baris terpengaruh)

Saya juga berlari

-- Isolate top waits for server instance since last restart or statistics clear
WITH Waits AS (
   SELECT 
        wait_type, 
        wait_time_ms / 1000. AS [wait_time_s],
        100. * wait_time_ms / SUM(wait_time_ms) OVER() AS [pct],
        ROW_NUMBER() OVER(ORDER BY wait_time_ms DESC) AS [rn]
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN ('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE',
    'SLEEP_TASK','SLEEP_SYSTEMTASK','SQLTRACE_BUFFER_FLUSH','WAITFOR','LOGMGR_QUEUE',
    'CHECKPOINT_QUEUE','REQUEST_FOR_DEADLOCK_SEARCH','XE_TIMER_EVENT','BROKER_TO_FLUSH',
    'BROKER_TASK_STOP','CLR_MANUAL_EVENT','CLR_AUTO_EVENT','DISPATCHER_QUEUE_SEMAPHORE',
    'FT_IFTS_SCHEDULER_IDLE_WAIT','XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN'))

SELECT W1.wait_type, 
    CAST(W1.wait_time_s AS DECIMAL(12, 2)) AS wait_time_s,
    CAST(W1.pct AS DECIMAL(12, 2)) AS pct,
    CAST(SUM(W2.pct) AS DECIMAL(12, 2)) AS running_pct
FROM Waits AS W1
INNER JOIN Waits AS W2 ON W2.rn <= W1.rn
GROUP BY W1.rn, W1.wait_type, W1.wait_time_s, W1.pct
HAVING SUM(W2.pct) - W1.pct < 95; -- percentage threshold

Dan mendapatkan

wait_type wait_time_s pct running_pct
CXPACKET 554821.66 65.82 65.82
LATCH_EX 184123.16 21.84 87.66
SOS_SCHEDULER_YIELD 37541.17 4.45 92.11
PAGEIOLATCH_SH 19018.53 2.26 94.37
FT_IFTSHC_MUTEX 14306.05 1.70 96.07

Itu menunjukkan sejumlah besar waktu menyinkronkan kueri yang melibatkan paralelisme (CXPACKET tinggi). Selain itu, secara anekdot banyak dari kueri masalah ini dieksekusi pada banyak core (kami tidak memiliki petunjuk MAXDOP di mana pun dalam kode kami)

Server belum dimuat selama lebih dari satu hari atau lebih. Kami mengalami banyak variasi dengan eksekusi kueri, biasanya banyak kueri tampak lebih lambat daripada yang ada di server DB kami sebelumnya dan CPU sangat tinggi.

Akankah menonaktifkan Hyperthreading membantu mengurangi penggunaan CPU kami dan meningkatkan throughput?



Perlu diingat bahwa CXPACKET tidak berarti bahwa ada banyak waktu menunggu proses untuk digabung bersama. CXPACKET berarti bahwa utas sedang menunggu utas lainnya menyelesaikan prosesnya. Anda perlu melihat kueri tertentu yang memiliki utas di CXPACKET, tunggu dan lihat utas apa yang menunggu selain CXPACKET. Biasanya IO atau jaringan. Dalam output di atas Anda sedang menunggu kait dan sedang dijadwalkan. Beberapa permintaan perlu dicari, atau Anda perlu melihat mengapa kait diambil.
mrdenny

Dalam kasus kami, CXPACKET tinggi karena utas lainnya hanya membaca berlebihan dari cache (20 juta pembacaan logis per kueri). Kasus kami, sekali lagi, adalah anti-semijoin buruk dengan tabel dipartisi yang hanya 700K baris.
ozamora

@ Mrdenny, ya waktu tunggu latch tinggi adalah tentang kita sedang menyelidiki itu saat ini.
Sam Saffron

Jawaban:


10

Saya masih merasa bahwa menguji beban kerja spesifik Anda , sesuai jawaban asli, adalah satu-satunya cara untuk memastikan. Ini bukan jawaban yang ideal ketika Anda mencoba untuk menyetel sistem produksi (jadi saya akan bertanya apakah mungkin untuk mendapatkan testbed identik dalam sistem di mana baik kinerja dan ketersediaan sangat penting) tetapi itu satu-satunya yang saya sangat nyaman dengan.

Kita dapat berbicara tentang teori apakah Hyperthreading harus melukai atau meningkatkan hal-hal secara umum (saya merasa lebih cenderung terluka daripada bantuan pada server sehingga untuk penyebaran "generik" saya mungkin menonaktifkannya), tetapi ada hanya satu cara untuk memastikan apakah itu akan membuat perbedaan dalam kasus spesifik Anda, dan itu adalah coba dan lihat.


3
Catatan saya tidak downvote, kami membutuhkan semua bantuan yang bisa kami dapatkan, namun kami ingin menghindari tusukan dalam gelap pada sistem produksi. Saya ingin memastikan kami mengumpulkan cukup diagnostik sebelum melakukan panggilan untuk bermain dengan pengaturan ini.
Sam Saffron

3
Saya yakin Anda ingin menghindari 'bermain' dengan sistem produksi, di dunia yang ideal kita semua akan memiliki lingkungan pengujian yang identik dengan produksi karena alasan itu. Saya setuju dengan tidak ingin mengubah produksi berdasarkan spekulasi. Namun, saya setuju dengan jawaban saya: Menguji beban kerja spesifik adalah bagian penting dari penyebaran apa pun dan siapa pun yang memberi tahu Anda berbeda adalah penipu. Bagi saya, semua tanda menunjukkan hyperthreading menjadi masalah di sini, tetapi kita bisa membicarakan hal-hal sepanjang hari dan sepanjang malam dan masih ada satu-satunya cara untuk mengetahui dengan pasti.
Rob Moir

5
Suara positif di sini - Saya setuju dengan jawabannya. Jawaban umum adalah: Nonaktifkan Hyperthreading. Jawaban yang lebih spesifik adalah: Itu tergantung pada spesifik dan HARUS DIUJI.
TomTom

1
Anehnya, saya pikir ini adalah jawaban terbaik untuk diterima, bermain-main dengan pengaturan maxdop dapat menyebabkan banyak masalah, nehalem cpus jauh lebih cepat daripada xeon berbasis inti bahkan pada kecepatan clock yang lebih lambat, saya menemukan argumen cache l2 sedikit dari herring merah menyebabkan cache l3 jauh lebih besar. Sebagai tambahan lihat: blog.stackoverflow.com/2010/10/database-upgrade , jika ada yang melihat hit / gain lebih dari 20% ... mungkin bukan karena HT.
Sam Saffron

Saya memiliki pengalaman yang berlawanan dengan @TomTom dan @Robert. Saya telah menemukan bahwa HT on biasanya 10-15% lebih baik daripada off. Kesempatan mematikannya meningkatkan kinerja memang jarang terjadi.
Brian Knoblauch

12

Saya setuju itu

  • paling baik rekomendasinya adalah "coba HyperThreading pada beban kerja Anda dan lihat apa yang terjadi". Kami sedang melakukan ini saat saya mengetik, dan .. itu tidak baik!
  • Anda mungkin harus selalu mulai dengan HyperThreading dinonaktifkan, karena itu paling aman

Sepertinya kita harus menyetel dua hal:

  1. MAXDOP (Derajat Maksimal Paralelisme). Semua yang saya baca menunjukkan bahwa memiliki batasan ini mungkin merupakan ide yang buruk, dan dokumentasi Microsoft mengatakan:

    Mengatur opsi ini [MAXDOP] ke nilai yang lebih besar [dari 8] sering menyebabkan konsumsi sumber daya yang tidak diinginkan dan penurunan kinerja.

    sesuatu yang lebih tinggi daripada 8umumnya tidak disarankan .. jadi saya atur 4untuk saat ini. Awalnya nol (tidak terikat).

  2. Ambang Batas Biaya untuk Paralelisme. Rupanya default di 5sini dianggap sebagai default yang cukup rendah menurut beberapa posting SQL MVP yang saya temukan - kita dapat menyetelnya untuk mengurangi berapa banyak paralelisme yang bahkan dicoba oleh scheduler.

Tapi jujur ​​ini terasa seperti solusi; Saya pikir solusi sebenarnya untuk beban kerja kami (indeks teks lengkap berat) adalah untuk menonaktifkan HT.


4
MAXDOP juga menyebabkan masalah dengan HT karena mungkin mencoba untuk mengeksekusi dua utas pada CPU yang sama jika Anda telah mengatakan, 8 core dan 16 utas, dan maxdop Anda diatur ke 10. Umumnya 1 MAXDOP per prosesor logis harus maks. Dan mengeksekusi dua utas pada CPU yang sama untuk proses yang sama tidak ada gunanya.
Mark Henderson

2
@Farseeker itu hanya terjadi jika Anda tidak memiliki sistem operasi HyperThreading-aware. Windows yang lebih baru dari 2000 menyadarinya.
Mircea Chirea

Perlu dicatat bahwa override maxdop ini hanya menyebabkan masalah. standarnya baik-baik saja bagi kita
Sam Saffron

2
Versi standar SQL Server maksimal pada MAXDOP 4, jika tidak dibatasi. Perlu Enterprise untuk melangkah lebih tinggi dari itu. Kami memiliki beberapa beban kerja yang berjalan tercepat dengan MAXDOP 1 (kotak non-HT, menjalankan beberapa AMD 8 inti) ...
Brian Knoblauch

1
@Brian Knoblauch - Saya tahu ini lebih dari setahun kemudian, tetapi saya menemukan ini "Versi standar SQL Server maxes pada MAXDOP 4 anyways ketika dibiarkan tidak terikat" setiap kesempatan Anda dapat mengarahkan saya ke beberapa dokumentasi. Kami saat ini berbicara tentang menggunakan MAXDOP di tempat kerja tetapi tidak yakin akan mengaturnya. Ini pada dasarnya berarti 4 sama dengan tidak terikat benar?
Jeremy A. West

9

Anandtech menemukan bahwa dengan beban baca murni, itu sedikit sakit, dan dengan beban tulis yang berat, itu sedikit menang. Saya belum melihat apa pun yang membuat saya berpikir itu akan membuat Anda mendapat pukulan yang jauh lebih buruk daripada -5%, atau kemenangan yang jauh lebih baik dari 15%. Perhatikan apa yang terjadi dengan Atom, ini adalah kemenangan besar, tetapi itu adalah cpu yang sangat aneh.

Yang Anda ubah hanyalah cpu? Anda beralih dari 12MB cache dan 4 thread, jadi 3MB cache per thread, menjadi 8 MB cache, dan 8 thread, jadi 1MB per thread. Nah, itu terlalu menyederhanakan, tapi saya yakin itulah yang membunuh Anda, Anda dulu menjalankan kueri dalam cache, dan sekarang menjalankannya dari RAM karena mereka membutuhkan lebih dari 1MB tetapi kurang dari 3MB. Mematikan HT mungkin akan membantu, tapi saya akan kembali ke CPU lama. Matikan HT, dan Anda mendapatkan 2MB per utas, tetapi jika beban kerja Anda terlalu banyak, itu tidak akan membantu. Mungkin cpu cache 12MB yang lama sangat cepat untuk beban kerja Anda.

Saya akan mencoba mematikan HT, dan melihat apakah itu merupakan peningkatan, tapi saya menduga cache adalah raja untuk beban kerja Anda, dan Anda mungkin perlu kembali ke chip 12 MB.


3
Cache L2 per pengamatan inti adalah penyederhanaan besar , karena CPU adalah satu generasi penuh di depan (Nehalem / Core i7 vs Core 2 Quad class).
Jeff Atwood

@Jess, @Ronald, dan Nehalem memiliki sedikit cache L2. Sebagian besar adalah L3 yang dibagi lintas core.
Mircea Chirea

7

Hyperthreading, paling-paling, hanyalah cara mengabstraksi tugas beralih dari sistem operasi dan meletakkannya di-mati, dengan akses langsung ke cache L1 dan L2, yang membuat tugas beralih crapload lebih cepat.

Pengujian dengan VMWare menunjukkan bahwa penonaktifan HT tidak membuat perbedaan nyata pada beban standar, dan kenaikan 5% di bawah beban berat, karena fakta bahwa ESXi cukup pintar untuk mengetahui perbedaan antara utas "nyata" dan utas "palsu" (Ada banyak hal lebih dari itu, tapi itu dalam istilah awam). SQL Server 2005 tidak secerdas itu, tetapi dikombinasikan dengan sistem operasi terbaru harus ada sedikit keuntungan untuk menonaktifkan HT.

Semua yang dikatakan, saya setuju dengan Ronald bahwa itu kemungkinan besar akan menjadi cache L2 Anda. Penurunan 33% dalam ukuran cache adalah besar, dan ketika kami menentukan SQL Server kami, kami selalu mencari cache lebih dari kecepatan clock mentah setiap waktu.


Bisakah Anda mengatur afinitas secara eksternal sehingga 4 core yang tepat diabaikan oleh SQL?
Sam Saffron

3
Secara umum Anda akan mengatur afinitas satu sama lain untaian CPU lainnya, tetapi selama MAXDOP diatur dengan benar, saya tidak melihat alasan untuk mengatur afinitas sama sekali. Dengan HT meskipun utas pertama yang terkena CPU menjadi utas "utama", dan utas 2 adalah utas "HT". Tidak ada untaian "utama" dan "ht" yang nyata, karena itu adalah salah satu yang pertama ada di sana, dan kemudian ketika mereka beralih tugas, urutannya terbalik.
Mark Henderson

CPU berbasis Nehalem memiliki cache L2 SANGAT, SANGAT SEDIKIT, sebagian besar dibagi L3.
Mircea Chirea

7

Berdasarkan pengalaman saya, HT membuat operasi I / O selamanya pada node aktif saya pada Windows 2008 R2 Cluster (menjalankan SQL Server 2008 R2). Fakta yang menarik adalah bahwa hal itu tidak tercermin dalam statistik tunggu maupun dalam pssdiag yang saya jalankan untuk dukungan Microsoft.

Cara saya perhatikan I / O rendah hanya dengan menonton penghitung OS untuk disk fisik. Seperti yang ditunjukkan Sam, saya menulisnya di sini dan di sini

Jika Anda TIDAK mengalami masalah I / O dan terikat dengan CPU, saya sarankan Anda memulai dengan cara ini:

Tentukan proses dan blok T-SQL mana yang paling banyak memanfaatkan CPU. Dalam pengalaman kami, setelah kami memperbaiki masalah dengan I / O (dengan mematikan HT) kami mengidentifikasi kode yang berkinerja buruk pada 2008 R2 dan baik-baik saja pada tahun 2005. Saya menulisnya di sini .

Saat berada di bawah beban tinggi, jalankan sp_whoisactive Adam Machanic. Anda dapat mengunduhnya dari sini . Kami mengalami pemanfaatan CPU yang sangat tinggi karena jumlah pembacaan logis yang berlebihan (20 juta per kueri) karena rencana yang sangat buruk. Proses kami melakukan anti-semi joins dengan tabel yang dipartisi.

Rekomendasi saya berikutnya adalah menjalankan profiler untuk mengidentifikasi satu set kode T-SQL yang keduanya tinggi dalam CPU dan I / O membaca logis.

Dengan langkah-langkah di atas kami dapat menyesuaikan proses yang menyinggung dan beralih dari 85% pemanfaatan CPU berkelanjutan menjadi hampir nol.

Semoga Sukses dan jangan ragu untuk mengirimkan saya garis jika Anda menemukan perbaikan karena saya ingin menambahkan kasus ke blog saya.

Terima kasih

Oscar


1
+1 untuk profiler, menyelamatkan saya berkali-kali begitu titik masalah telah diidentifikasi
Mark Henderson

Terima kasih +1 atas semua saran Anda, menyetel SQL kami ke tingkat yang wajar adalah mimpi buruk total, kami sangat bergantung pada teks lengkap untuk berurusan dengan tag, cukup sering kami mencari daftar item dalam tag tertentu sehingga kami dapat keseluruhan atur dan saring. Misalnya, mendapatkan daftar pertanyaan dengan tag [x] dan [y] yang dipesan berdasarkan tanggal melibatkan menarik sejumlah besar data dari teks lengkap dan kemudian bergabung secara besar-besaran.
Sam Saffron

Dimengerti. Ambil satu sampel dan jalankan dengan statistik IO ON dan lihat apakah Anda dapat menentukan tabel dengan bacaan paling logis. Sekali lagi, kami baik-baik saja di tahun 2005 dan sangat buruk di tahun 2008 R2. Jika Anda baru saja menemukan utilisasi CPU yang tinggi dan menunggu CXPACKET yang tinggi, coba dulu dengan meningkatkan Cost Threshold untuk paralelisme menjadi 10, 15 atau bahkan 20.
ozamora

Jika tidak ada yang membantu, luring DB, matikan HT, dan pergi dari sana. Semoga sukses
ozamora

sp_whoisactive adalah alat yang sangat mengagumkan, suka cara kuliknya dapat diklik
Sam Saffron

2

Apakah HT baik atau buruk sulit dijabarkan.

Itu benar-benar tergantung pada pola beban server berdasarkan pengalaman dan membaca. Yaitu, ketika hal itu memengaruhi kinerja, ia melakukannya dengan sangat buruk : jika tidak, Anda tidak menyadarinya.

Teori yang saya baca adalah bahwa thread berbagi cache yang berarti dalam kondisi buruk setiap thread dapat menimpa cache thread lain. Jika Anda tidak memiliki banyak paralelisme, atau beban Anda banyak pertanyaan pendek, maka itu mungkin tidak mempengaruhi Anda.

Saya sudah mencoba dengan MAXDOP dan afinitas prosesor (kembali ke peran DBA nyata terakhir saya di SQL Server 2000) tetapi tidak pernah bisa menemukan sesuatu yang konklusif: tetapi hanya untuk toko saya pada waktu itu.

Sebagai tes cepat, Anda dapat mengatur afinitas prosesor untuk hanya menggunakan inti fisik (angka yang lebih rendah) dan melihat apa yang terjadi.

Namun, paling banyak Anda kehilangan setengah inti Anda. Saat ini mungkin tidak masalah dibandingkan dengan apa yang saya mainkan beberapa tahun yang lalu ketika itu 2 vs 4 atau 4 vs 8. Sekarang 8 vs 16 atau 16 vs 32.

Sunting: Tes oleh Slava Oks


Apakah inti 0-3 fisik dan 4-7 logis? Apakah itu cara kerjanya? Kami tidak tahu, dan saya tidak tahu alat apa pun untuk memberi tahu saya ..
Jeff Atwood

2
@ Jeff Atwood: Saya akan menemukan lebih banyak nanti. Saya telah membacanya di suatu tempat .... Untuk saat ini: support.microsoft.com/kb/322385
gbn

Artikel KB itu meringkasnya.
pauska

Meskipun artikel KB itu memang mengandung beberapa informasi yang bermanfaat, sepertinya tidak langsung menjawab pertanyaan Jeff tentang bagaimana tepatnya prosesor logis dipetakan ke yang fisik. Otak saya digoreng sekitar setengah jalan, tapi mudah-mudahan artikel INTEL ini akan memberi Anda apa yang Anda butuhkan untuk mengetahui pemetaan: software.intel.com/en-us/articles/… juga lihat software.intel.com/en-us/ blog / 2009/12/21 / ... dengan tautan terkaitnya.
BradC

@ Jeff Atwood, @BradC: Lordy, sulit ditemukan. Lihat ini: ini bergantung pada rekomendasi Intel. SQL Server akan menggunakan mendasari Windows pencacahan download.microsoft.com/download/5/7/7/... .
gbn

2

Sayangnya, saya tidak berpikir Anda akan mendapatkan jawaban yang lebih pasti daripada "coba nonaktifkan hyperthreading dan lihat apakah itu membantu".

Terlepas dari jawaban bermanfaat dari Jonathan di utas asli saya (yang Anda tautkan dalam pertanyaan Anda), saya tidak pernah bisa mendapatkan bukti pasti tentang dampak HT pada server tertentu yang saya selidiki. Dalam kasus saya, server sudah dijadwalkan untuk diganti, jadi kami cukup membiarkan penggantian itu "mengatasi masalah".

Saranku:

Coba pengaturan tingkat Paralelisme MAX Tingkat server 1 . Paralelisme pada SQL paling berguna untuk kueri yang lebih besar dan lebih lama, dan beban Anda (saya asumsikan) terdiri dari sejumlah besar kueri yang lebih kecil. Ini sepenuhnya harus menghilangkan menunggu CXPACKET. Ini dapat membuat kueri individual tertentu berjalan sedikit lebih lama, tetapi harus memungkinkan lebih banyak "throughput" dari total kueri di server.

Saya sudah mendapatkan hasil yang baik melakukan ini di server OLTP. Jenis server lain (server pelaporan, server pemrosesan, data pergudangan) pasti membutuhkan MAXDOP yang ditetapkan lebih tinggi.

Dan hanya untuk memperjelas, pengaturan ini masih memungkinkan SQL untuk menggunakan beberapa utas untuk setiap tabel dalam GABUNGAN, jadi Anda tidak benar-benar menghilangkan paralelisme sepenuhnya.

Setidaknya patut dicoba, karena perubahan pengaturan ini segera berlaku dan bahkan tidak mengharuskan Anda untuk me-restart layanan SQL: http://msdn.microsoft.com/en-us/library/ms181007.aspx
Ini berarti Anda bisa beralih segera kembali jika semuanya mulai masuk neraka.

Mematikan hyperthreading di BIOS akan membutuhkan server reboot penuh, jadi sedikit lebih berisiko.


0

Sebagai catatan, kami juga memiliki kinerja buruk yang tidak terduga setelah peningkatan server. Ternyata karena masalah dengan penghematan daya BIOS dan CPU. Pengaturan default pada server (HP) adalah untuk mengabaikan kontrol OS dari kecepatan CPU dan menggunakan algoritma sendiri. Mengubah ini ke kontrol OS, dan memperbarui BIOS, menghasilkan peningkatan yang signifikan. Ada beberapa catatan rilis (tidak dapat menemukannya sekarang) bahwa ada bug BIOS yang mengunci CPU pada kondisi kinerja terendah.

/server//a/196329/6390

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.