Masalah kinerja utama pada SQL Server produksi kami, bagaimana saya memecahkan masalah ini?

Pertanyaan ini pada dasarnya adalah pertanyaan tindak lanjut untuk pertanyaan ini:
Masalah kinerja yang aneh dengan SQL Server 2016

Kami sekarang menjadi produktif dengan sistem ini. Meskipun database aplikasi lain telah ditambahkan ke SQL Server ini sejak posting terakhir saya.

ini adalah statistik sistem:

• 128 GB RAM (memori 110GB Maks untuk SQL Server)
• 4 Cores @ 2.6 GHz
• Koneksi jaringan 10 GBit
• Semua penyimpanan berbasis SSD
• File program, file Log, file database dan tempdb berada di partisi server yang terpisah
• Windows Server 2012 R2
• Versi VMware HPE-ESXi-6.0.0-Update3-iso-600.9.7.0.17
• VMware Tools versi 10.0.9, build 3917699
• Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64) 28 Okt 2016 18:17:30 Hak cipta (c) Edisi Standar Microsoft Corporation (64-bit) pada Windows Server 2012 R2 Standard 6.3 (Build 9600:) (Hypervisor)

Sistem kami sekarang memiliki masalah kinerja utama. Penggunaan CPU dan jumlah utas sangat tinggi:

Tunggu statistik monitor aktivitas (saya tahu itu tidak terlalu bisa diandalkan)

Hasil sp_blitzfirst:

Hasil sp_configure:

Pengaturan server tingkat lanjut (hanya untuk bahasa Jerman)

Pengaturan MAXDOP diubah oleh saya.

Saya sadar bahwa ini mungkin bukan masalah dengan SQL Server itu sendiri . Ini mungkin masalah dengan virtualisasi (vmware), jaringan terkait (saya sudah menguji ini) atau aplikasi itu sendiri. Saya hanya ingin memahaminya lebih jauh.

Apakah ASYNC_NETWORK_IO yang tinggi akan menghasilkan jumlah utas yang tinggi untuk proses sqlserver? Saya membayangkan itu membuat banyak pekerja karena utas tidak dapat ditutup. Apakah itu benar?

Saya akan memberikan info tambahan yang Anda butuhkan. Terima kasih sebelumnya atas dukungan Anda!

EDIT:

Hasil dari sp_Blitz @OutputType = ‘markdown’, @CheckServerInfo = 1

Prioritas 1: Cadangkan :

• Mencadangkan ke Drive yang Sama Tempat Basis Data berada - 5 backup dilakukan pada drive E: \ dalam dua minggu terakhir, tempat file database juga hidup. Ini merupakan risiko serius jika array itu gagal.

Prioritas 1: Keandalan :

• CHECKDB DBCC baik terakhir lebih dari 2 minggu

  • babtec_prod - Terakhir sukses CHECKDB: 2017-08-20 00: 01: 01.513

  • D3PR - CHECKDB sukses terakhir: tidak pernah.

  • DEMO77 - Terakhir berhasil CHECKDB: 2016-02-23 20: 31: 38.590

  • FINP - Terakhir berhasil CHECKDB: 2017-04-23 22: 01: 19.133

  • GridVis_EnMs - CHECKDB sukses terakhir: 2017-05-18 22: 10: 48.120

  • master - CHECKDB sukses terakhir: tidak pernah.

  • model

  • msdb

  • PROD77 - Keberhasilan terakhir CHECKDB: 2016-02-23 21: 33: 24.343

Prioritas 10: Kinerja :

• Query Store Dinonaktifkan - Fitur SQL Server 2016 Query Store baru belum diaktifkan pada database ini.

  • babtec_prod

  • D3PR

  • DEMO77

  • FINP

  • GridVis_EnMs

Prioritas 50: Acara DBCC :

• DBCC DROPCLEANBUFFERS - Schorsch pengguna telah menjalankan DBCC DROPCLEANBUFFERS 1 kali antara 21 Sep 2017 2017 11:57 dan 21 Sep 2017 11:57. Jika ini adalah kotak produksi, ketahuilah bahwa Anda menghapus semua data dari memori saat ini terjadi. Monster apa yang akan melakukan itu?

• DBCC SHRINK% - Schorsch pengguna telah menjalankan penyusutan file 6 kali antara 21 Sep 2017 11:51 PM dan 4 Okt 2017 9:02 AM. Jadi, uh, apakah mereka berusaha memperbaiki korupsi, atau menyebabkan korupsi?

• Keseluruhan Acara - 287 acara DBCC telah terjadi antara 19 September 2017 13:40 dan 4 Okt 2017 15:20. Ini tidak termasuk CHECKDB dan acara DBCC lainnya yang biasanya tidak berbahaya.

Prioritas 50: Kinerja :

• Pertumbuhan File Lambat PROD77 - 2 pertumbuhan masing-masing memakan waktu lebih dari 15 detik. Pertimbangkan untuk menyetel autogrowth file menjadi lebih kecil.

Prioritas 50: Keandalan :

• Verifikasi Halaman Tidak Optimal babtec_prod - Database [babtec_prod] memiliki TORN_PAGE_DETECTION untuk verifikasi halaman. SQL Server mungkin lebih sulit mengenali dan memulihkan dari korupsi penyimpanan. Pertimbangkan untuk menggunakan CHECKSUM sebagai gantinya.

Prioritas 100: Kinerja :

• Banyak Paket untuk Satu Kueri - 3576 paket hadir untuk satu permintaan dalam cache paket - artinya kita mungkin memiliki masalah parameterisasi.

Prioritas 110: Kinerja :

• Tabel Aktif Tanpa Indeks Clustered

  • babtec_prod - Basis data [babtec_prod] memiliki tumpukan - tabel tanpa indeks berkerumun - yang sedang ditanyakan secara aktif.

  • D3PR - Basis data [D3PR] memiliki tumpukan - tabel tanpa indeks berkerumun - yang sedang ditanya secara aktif.

  • DEMO77 - Basis data [DEMO77] memiliki banyak - tabel tanpa indeks berkerumun - yang sedang ditanyakan secara aktif.

  • FINP - Database [FINP] memiliki tumpukan - tabel tanpa indeks berkerumun - yang sedang ditanya secara aktif.

  • GridVis_EnMs - Database [GridVis_EnMs] memiliki tumpukan - tabel tanpa indeks berkerumun - yang sedang ditanya secara aktif.

  • PROD77 - Basis data [PROD77] memiliki tumpukan - tabel tanpa indeks berkerumun - yang sedang ditanyakan secara aktif.

Prioritas 150: Kinerja :

• Kunci Asing Tidak Tepercaya

  • babtec_prod - Database [babtec_prod] memiliki kunci asing yang mungkin dinonaktifkan, data diubah, dan kemudian kunci diaktifkan lagi. Cukup mengaktifkan kunci tidak cukup bagi pengoptimal untuk menggunakan kunci ini - kita harus mengubah tabel menggunakan parameter WITH CHECK CHECK CONSTRAINT.

  • D3PR - Basis data [D3PR] memiliki kunci asing yang mungkin dinonaktifkan, data diubah, dan kemudian kunci diaktifkan kembali. Cukup mengaktifkan kunci tidak cukup bagi pengoptimal untuk menggunakan kunci ini - kita harus mengubah tabel menggunakan parameter WITH CHECK CHECK CONSTRAINT.

• Tabel Tidak Aktif Tanpa Indeks Clustered

  • D3PR - Database [D3PR] memiliki tumpukan - tabel tanpa indeks berkerumun - yang belum ditanya sejak restart terakhir. Ini mungkin tabel cadangan yang ditinggalkan dengan sembarangan.

  • GridVis_EnMs - Basis data [GridVis_EnMs] memiliki tumpukan - tabel tanpa indeks berkerumun - yang belum di-query sejak restart terakhir. Ini mungkin tabel cadangan yang ditinggalkan dengan sembarangan.

• Pemicu pada Tabel babtec_prod - Database [babtec_prod] memiliki 26 pemicu.

Prioritas 170: Konfigurasi File :

• Database Sistem pada Drive C

  • master - Database master memiliki file pada drive C. Menempatkan basis data sistem pada drive C berisiko menabrak server saat kehabisan ruang.

  • model - Database model memiliki file pada drive C. Menempatkan basis data sistem pada drive C berisiko menabrak server saat kehabisan ruang.

  • msdb - Database msdb memiliki file di drive C. Menempatkan basis data sistem pada drive C berisiko menabrak server saat kehabisan ruang.

Prioritas 170: Keandalan :

• Set Ukuran File Maks

  • D3PR - File database [D3PR] d3_data_01 memiliki ukuran file maksimum yang diatur ke 61440MB. Jika kehabisan ruang, database akan berhenti berfungsi meskipun mungkin ada ruang drive yang tersedia.

  • D3PR - File basis data [D3PR] d3_data_idx_01 memiliki ukuran file maksimum yang diatur ke 61440MB. Jika kehabisan ruang, database akan berhenti berfungsi meskipun mungkin ada ruang drive yang tersedia.

  • D3PR - File database [D3PR] d3_firm_01 memiliki ukuran file maksimum yang diatur ke 61440MB. Jika kehabisan ruang, database akan berhenti berfungsi meskipun mungkin ada ruang drive yang tersedia.

  • D3PR - File basis data [D3PR] d3_firm_idx_01 memiliki ukuran file maksimum yang diatur ke 61440MB. Jika kehabisan ruang, database akan berhenti berfungsi meskipun mungkin ada ruang drive yang tersedia.

  • D3PR - File basis data [D3PR] d3_log_01 memiliki ukuran file maksimum yang diatur ke 61440MB. Jika kehabisan ruang, database akan berhenti berfungsi meskipun mungkin ada ruang drive yang tersedia.

  • D3PR - File database [D3PR] d3_phys_01 memiliki ukuran file maksimum yang diatur ke 61440MB. Jika kehabisan ruang, database akan berhenti berfungsi meskipun mungkin ada ruang drive yang tersedia.

  • D3PR - File basis data [D3PR] d3_phys_idx_01 memiliki ukuran file maksimum yang diatur ke 61440MB. Jika kehabisan ruang, database akan berhenti berfungsi meskipun mungkin ada ruang drive yang tersedia.

  • D3PR - File basis data [D3PR] d3_sys_01 memiliki ukuran file maksimum yang diatur ke 20480MB. Jika kehabisan ruang, database akan berhenti berfungsi meskipun mungkin ada ruang drive yang tersedia.

  • D3PR - File basis data [D3PR] d3_usr_01 memiliki ukuran file maksimum yang ditetapkan ke 20480MB. Jika kehabisan ruang, database akan berhenti berfungsi meskipun mungkin ada ruang drive yang tersedia.

  • D3PR - File basis data [D3PR] d3_wort_01 memiliki ukuran file maksimum yang diatur ke 20480MB. Jika kehabisan ruang, database akan berhenti berfungsi meskipun mungkin ada ruang drive yang tersedia.

  • D3PR - File database [D3PR] d3_wort_idx_01 memiliki ukuran file maksimal yang ditetapkan ke 20480MB. Jika kehabisan ruang, database akan berhenti berfungsi meskipun mungkin ada ruang drive yang tersedia.

Prioritas 200: Informasi :

• Default Kompresi Cadangan Nonaktif - Cadangan lengkap yang tidak terkompresi telah terjadi baru-baru ini, dan kompresi cadangan tidak diaktifkan di tingkat server. Kompresi cadangan disertakan dengan SQL Server 2008R2 & yang lebih baru, bahkan dalam Edisi Standar. Kami menyarankan untuk mengaktifkan kompresi cadangan secara default sehingga cadangan ad-hoc akan terkompresi.

• Collation adalah Latin1_General_CS_AS FINP - Perbedaan collation antara database pengguna dan tempdb dapat menyebabkan konflik terutama ketika membandingkan nilai string

• Collation adalah SQL_Latin1_General_CP1_CI_AS - Perbedaan collation antara database pengguna dan tempdb dapat menyebabkan konflik terutama ketika membandingkan nilai string

  • DEMO77

  • PROD77

• Server Tertaut Dikonfigurasi - BWIN2 \ INFOR dikonfigurasi sebagai server tertaut. Periksa konfigurasi keamanannya saat terhubung dengan sa, karena setiap pengguna yang menanyakannya akan mendapatkan izin tingkat admin.

Prioritas 200: Pemantauan :

• Pekerjaan Agen Tanpa Email Gagal

  • Pekerjaan syspolicy_purge_history belum diatur untuk memberi tahu operator jika gagal.

  • Pekerjaan upd_durchpreis_monatl belum diatur untuk memberi tahu operator jika gagal.

  • Pekerjaan upd_fertmengen_woche belum diatur untuk memberi tahu operator jika gagal.

  • Pekerjaan upd_liegezeit_monatl belum diatur untuk memberi tahu operator jika gagal.

  • Pekerjaan upd_vertreter_diff belum diatur untuk memberi tahu operator jika gagal.

  • Pekerjaan UPDATE_CONNECT_IK belum diatur untuk memberi tahu operator jika gagal.

  • Pekerjaan Wartung.Cleanup belum diatur untuk memberi tahu operator jika gagal.

  • Pekerjaan Wartung.DBCC Periksa DB belum diatur untuk memberi tahu operator jika gagal.

  • Pekerjaan Wartung.Index neu erstellen belum diatur untuk memberi tahu operator jika gagal.

  • Pekerjaan Wartung.Statistiken aktualisieren belum diatur untuk memberi tahu operator jika gagal.

  • Pekerjaan Wartung.Transactionlog Backup belum diatur untuk memberi tahu operator jika gagal.

  • Pekerjaan Wartung.Vollbackup SystemDB belum diatur untuk memberi tahu operator jika gagal.

  • Pekerjaan Wartung.Vollbackup UserDB belum diatur untuk memberi tahu operator jika gagal.

• Tidak Ada Peringatan untuk Korupsi - Peringatan SQL Server Agent tidak ada untuk kesalahan 823, 824, dan 825. Ketiga kesalahan ini dapat memberi Anda pemberitahuan tentang kegagalan perangkat keras awal. Mengaktifkannya dapat mencegah Anda patah hati.

• Tidak Ada Peringatan untuk Sev 19-25 - Peringatan SQL Server Agent tidak ada untuk tingkat keparahan 19 hingga 25. Ini adalah beberapa kesalahan SQL Server yang sangat parah. Mengetahui bahwa ini terjadi dapat membuat Anda pulih dari kesalahan lebih cepat.

• Not All Alerts Configured - Tidak semua peringatan SQL Server Agent telah dikonfigurasi. Ini adalah cara gratis dan mudah untuk mendapatkan pemberitahuan tentang korupsi, kegagalan pekerjaan, atau pemadaman besar bahkan sebelum sistem pemantauan mengambilnya.

Prioritas 200: Konfigurasi Server Non-Default :

• Agent XPs - Opsi sp_configure ini telah diubah. Nilai standarnya adalah 0 dan telah diatur ke 1.

• Database Mail XPs - Opsi sp_configure ini telah diubah. Nilai standarnya adalah 0 dan telah diatur ke 1.

• bahasa teks lengkap default - Opsi sp_configure ini telah diubah. Nilai standarnya adalah 1033 dan telah ditetapkan ke 1031.

• bahasa default - Opsi sp_configure ini telah diubah. Nilai standarnya adalah 0 dan telah diatur ke 1.

• filestream access level - Opsi sp_configure ini telah diubah. Nilai standarnya adalah 0 dan telah diatur ke 1.

• derajat paralelisme maksimum - Opsi sp_configure ini telah diubah. Nilai standarnya adalah 0 dan telah diatur ke 4.

• max server memory (MB) - Opsi sp_configure ini telah diubah. Nilai standarnya adalah 2147483647 dan telah ditetapkan ke 115000.

• min server memory (MB) - Opsi sp_configure ini telah diubah. Nilai standarnya adalah 0 dan telah diatur ke 10000.

• koneksi admin jarak jauh - Opsi sp_configure ini telah diubah. Nilai standarnya adalah 0 dan telah diatur ke 1.

Prioritas 200: Kinerja :

• ambang biaya untuk paralelisme - Set ke 5, nilai standarnya. Mengubah pengaturan sp_configure ini dapat mengurangi waktu tunggu CXPACKET.

• Snapshot Backups Terjadi - 9 backup yang terlihat snapshot telah terjadi dalam dua minggu terakhir, menunjukkan bahwa IO mungkin membeku.

Prioritas 210: Konfigurasi Basis Data Non-Default :

• Baca Committed Snapshot Isolasi Diaktifkan - Pengaturan basis data ini bukan default.

  • D3PR

  • FINP

• Pemicu Rekursif Diaktifkan - Pengaturan basis data ini bukan default.

  • DEMO77

  • PROD77

• Snapshot Isolasi Diaktifkan FINP - Pengaturan basis data ini bukan default.

Prioritas 240: Tunggu Statistik :

• 1 - ASYNC_NETWORK_IO - 225.9 jam menunggu, 143,5 menit waktu tunggu rata-rata per jam, menunggu sinyal 0,2%, tugas menunggu 2146022, waktu tunggu rata-rata 378,9 ms.

• 2 - CXPACKET - 43.1 jam menunggu, 27,4 menit waktu tunggu rata-rata per jam, menunggu sinyal 1,5%, tugas menunggu 32608391, waktu tunggu rata-rata 4,8 ms.

Prioritas 250: Informasi :

• SQL Server berjalan di bawah akun Layanan NT

  • Saya menjalankan NT Service \ MSSQL $ INFOR. Saya berharap saya memiliki akun layanan Direktori Aktif.

  • Saya menjalankan NT Service \ SQLAgent $ INFOR. Saya berharap saya memiliki akun layanan Direktori Aktif.

Prioritas 250: Info Server :

• Isi Jejak Default - Jejak default menampung data 760 jam antara 3 September 2017 20:34 dan 5 Okt 2017 12:50 PM. File jejak default terletak di: C: \ Program Files \ Microsoft SQL Server \ MSSQL13.INFOR \ MSSQL \ Log

• Drive C Space - 21308.00MB gratis di drive C

• Drive D Space - 280008.00MB gratis di D drive
• Drive E Space - 281618.00MB gratis di drive E

• Drive F Space - 60193.00MB gratis di drive F

• Perangkat keras - Prosesor logis: 4. Memori fisik: 128GB.

• Perangkat Keras - NUMA Konfigurasi - Node: 0 Negara: ONLINE Penjadwal online: 4 Penjadwal offline: 0 Grup Prosesor: 0 Node memori: 0 Memori VAS Cadangan GB: 281

• Server Restart Terakhir - 1 Okt 2017 2:21 PM

• Nama Server - BWINPDB \ INFOR

• Jasa

  • Layanan: SQL Server (INFOR) berjalan di bawah akun layanan NT Service \ MSSQL $ INFOR. Waktu startup terakhir: 1 Okt 2017 2:22 PM. Jenis startup: Otomatis, Sedang Berjalan.

  • Layanan: SQL Server-Agent (INFOR) berjalan di bawah akun layanan NT Service \ SQLAgent $ INFOR. Waktu startup terakhir: tidak ditampilkan .. Jenis startup: Otomatis, saat ini Berjalan.

• SQL Server Restart Terakhir - 1 Okt 2017 2:22 PM

• Layanan SQL Server - Versi: 13.0.4001.0. Level Patch: SP1. Edisi: Edisi Standar (64-bit). Diaktifkan AlwaysOn: 0. Status AlwaysOn Mgr: 2

• Server Virtual - Ketik: (HYPERVISOR)

• Versi Windows - Anda menjalankan versi Windows yang cukup modern: Server 2012R2 era, versi 6.3

Prioritas 254: Rundate :

• Log Kapten: menata sesuatu dan sesuatu ...

EDIT:

Saya sudah mempelajari panduan praktik terbaik tentang pengaturan sql server dengan vmware, dan kami telah mengatur sebagian besar sesuai dengan makalah ini. Padahal, hyperthreading tidak diaktifkan dan NUMA tidak aktif pada host vmware. SQL Server diatur ke NUMA.

EDIT:

Saya telah mengeluarkan RECONFIGURE setelah mengatur thresold untuk paralelisme ke 50, juga pengaturan MAXDOP saya tidak dikonfigurasi.

Saya juga memeriksa dengan admin vmware kami, sepertinya saya salah informasi. CPU kami disetel ke 2.6GHz, bukan 4.6 GHz. Saya sudah mengoreksi informasi di atas.

EDIT:

Kami mencoba mengatur beberapa jaringan yang terkait dengan vmwarekb dan panduan ini . Kami juga menambahkan 4 core lagi ke VM. Penggunaan CPU tetap sama.

Seperti yang dibahas terakhir kali Anda menanyakan pertanyaan ini , penantian teratas Anda adalah ASYNC_NETWORK_IO. SQL Server sedang duduk menunggu mesin di ujung pipa untuk mencerna baris berikutnya dari hasil permintaan.

Saya mendapat info ini dari menunggu statistik hasil sp_Blitz (terima kasih telah menempelkan itu di):

1 - ASYNC_NETWORK_IO - 225.9 jam menunggu, 143,5 menit waktu tunggu rata-rata per jam, menunggu sinyal 0,2%, tugas menunggu 2146022, waktu tunggu rata-rata 378,9 ms.

Jangan mematikan pemecahan masalah utas CPU - itu tidak terkait. Fokus pada tipe tunggu utama Anda dan hal-hal yang akan menyebabkan tipe tunggu itu.

Untuk memecahkan masalah ini lebih jauh, jalankan sp_WhoIsActive atau sp_BlitzFirst (penafian: Saya salah satu penulisnya) - keduanya akan mencantumkan kueri yang sedang berjalan saat ini. Lihat kolom info tunggu, cari pertanyaan yang menunggu ASYNC_NETWORK_IO, dan lihat aplikasi & server tempat mereka menjalankannya.

Dari sana, Anda dapat mencoba:

• Memeriksa untuk melihat apakah server aplikasi itu kekurangan daya (seperti apakah mereka dimaksimalkan pada CPU, atau paging ke disk) dan tune mereka
• Bekerja dengan pengembang aplikasi untuk melihat apakah mereka melakukan pemrosesan baris demi baris pada hasil (seperti untuk setiap baris yang kembali dari SQL Server, aplikasi berbunyi dan melakukan beberapa pemrosesan sebelum meminta baris hasil berikutnya)
• Bekerja dengan pengembang aplikasi untuk memilih lebih sedikit data (seperti lebih sedikit baris atau lebih sedikit kolom jika mereka tidak membutuhkan semua data - kadang-kadang Anda melihat ini ketika orang-orang secara tidak sengaja melakukan SELECT * dan membawa kembali lebih banyak data dari yang mereka butuhkan, atau mereka meminta semua baris ketika mereka hanya benar-benar membutuhkan 1000 teratas)

Perbarui dengan sp_WhoIsActive - di tangkapan layar sp_WhoIsActive yang Anda poskan, Anda memiliki beberapa pertanyaan yang menunggu di ASYNC_NETWORK_IO. Untuk itu, lihat instruksi di atas.

Di sisa kueri, lihat kolom "status" sp_WhoIsActive - mayoritas dari mereka "tidur." Itu berarti mereka tidak berfungsi sama sekali - mereka sedang menunggu aplikasi di ujung lain pipa untuk mengirim perintah berikutnya. Mereka memiliki transaksi terbuka (lihat kolom "open_tran_count") tetapi tidak ada yang bisa dilakukan SQL Server untuk mempercepat transaksi yang tidak berjalan. Pertanyaan ini telah terbuka selama lebih dari empat puluh menit (kolom pertama di sp_WhoIsActive. Mereka tidak melakukan apa-apa lagi. Anda harus membuat orang-orang itu melakukan transaksi dan menutup koneksi mereka. Ini bukan masalah penyesuaian kinerja.

Semua yang kami lihat di sini mengarah ke skenario di mana kami menunggu di aplikasi.

Untuk menjawab pertanyaan saya sendiri. ASYNC_NETWORK_IO sebenarnya bukan masalah sebenarnya. Kami memperbaiki masalah kinerja kami dengan mengikuti panduan ini untuk beban kerja sensitif latensi:

Praktik Terbaik untuk Penyesuaian Kinerja Beban Kerja Sensitif-Latensi di vSphere VMs

Saya menandai pengaturan yang kami terapkan pada sistem kami dengan warna kuning di sini:

Saya pikir pengaturan dengan dampak paling besar adalah konfigurasi Numa dan pengaturan sensitivitas latensi ke tinggi . Yang keduanya diperlukan untuk kejelasan mengalokasikan / memesan core CPU fisik dan RAM untuk VM.

Kami juga menambahkan lebih banyak core ke VM dan sekarang perlu meningkatkan lisensi SQL Server kami dari Standard ke Enterprise.

Sepertinya Windows melaporkan kecepatan clock inti CPU Anda 4,6Ghz sebagai 2,6Ghz ... Saya akan menjalankan alat seperti CPU-Z untuk memeriksa berapa kecepatan mereka sebenarnya berjalan, dan kemudian melihat mengubah pengaturan daya di baik Windows maupun BIOS / OS Manajemen untuk menonaktifkan pengaturan penghematan daya apa pun yang mungkin memperlambat kecepatan inti.