sql >> Databáze >  >> RDS >> Database

The Zombie PerfMon Counter That Never Die!

Jedna z věcí, která je na internetu skvělá a zároveň hrozná, je ta, že jakmile je něco zveřejněno v éteru, v podstatě to nikdy nezmizí. (Jednoho dne si to politici uvědomí. Jejich konzistentnost můžeme snadno ověřit fakty.) Kvůli dlouhé životnosti obsahu zveřejněného na internetu se z mnoha témat ladění výkonu stávají „zombie“. Zastřelíme je, ale oni se stále vracejí!

Jinými slovy, tato stará doporučení byla doporučený postup již dávno navržený pro konkrétní verzi serveru SQL Server, ale nyní je nevhodný pro novější verzi. Není pro mě neobvyklé, když mluvím na konferenci, že narazím na někoho, kdo stále lpí na nastaveních a technikách, které nebyly od dob SQL Server 2000 dobrým zvykem. Návod SQL Server 2000 Operations Guide on Capacity/Storage obsahuje mnoho " doporučené postupy, které byly velmi specifické pro jednotlivé verze a dnes již neplatí.

Zde je příklad. % Disk Time a Disk Queue Length Čítače PerfMon byly důrazně doporučeny jako klíčové indikátory výkonu I/O. SQL Server vrhá velké množství I/O na disky pomocí scatter/gather, aby se maximalizovalo využití diskového I/O subsystému. Tento přístup vede ke krátkým shlukům dlouhých hloubek fronty během kontrolních bodů a předčítání pro instanci SQL Server. Někdy je zátěž serveru taková, že váš disk nestíhá držet krok s I/O, který je do něj vložen, a když k tomu dojde, uvidíte také dlouhé fronty. Scénář krátkého výbuchu není problém. Scénář prodlužování délky fronty je obvykle problém. Je to tedy dobrá praxe?

Jedním slovem, moc ne.

Tyto čítače mohou být stále užitečné v instanci serveru SQL Server, který má pouze jeden pevný disk (ačkoli to je nadmíru v dnešní době vzácné). Proč?

Čítač PerfMon % Disk Time je falešná metrika výkonu z několika důvodů. Nebere v úvahu asynchronní požadavky I/O. Nemůže říci, jaký může být skutečný profil výkonu pro základní sadu RAID, protože obsahují více diskových jednotek. Čítač PerfMon Disk Queue Length je také většinou k ničemu, s výjimkou serverů SQL s jedním fyzickým diskem, protože mezipaměť řadiče pevného disku zatemňuje, kolik I/O operací ve frontě skutečně čeká nebo ne. Ve skutečnosti mají některé pevné disky dokonce i malé mezipaměti pro zápis, což dále kalí vodu v tom, zda je I/O skutečně ve frontě, v mezipaměti někde mezi operačním systémem a diskem, nebo se konečně dostal až na doraz. do CMOS na disku.

Lepší čítače I/O PerfMon

Místo použití těchto čítačů PerfMon použijte Avg Disk Reads/sec , Avg Disk Writes/sec a Avg Disk Transfers/sec ke sledování výkonu diskových subsystémů. Tyto čítače sledují průměrný počet I/O čtení, zápisu I/O a kombinovaných I/O čtení a zápisu, ke kterým došlo v poslední sekundě. Občas rád sleduji stejné metriky podle objemu dat spíše než podle rychlosti I/O operací. Chcete-li získat tato data, možná budete chtít vyzkoušet tyto čítače PerfMon pro konkrétní svazky: Avg Disk Transfer Bytes/sec , Avg Disk Read Bytes/sec a Avg Disk Write Bytes/sec .

Pro výkon SQL Server I/O použijte Dynamic Management Views (DMV)

A pokud jste nežili v jeskyni, měli byste se ujistit, že používáte SQL Server Dynamic Management Views (DMV) ke kontrole I/O výkonu pro nejnovější verze SQL Server. Některé z mých oblíbených DMV pro I/O zahrnují:

  • sys.dm_os_wait_stats
  • sys.dm_os_waiting_tasks
  • sys.dm_os_performance_counters
  • sys.dm_io_virtual_file_stats
  • sys.dm_io_pending_io_requests
  • sys.dm_db_index_operational_stats
  • sys.dm_db_index_usage_stats

Jak tedy sledujete metriky I/O výkonu? Které z nich používáte?

Těším se, až se ozvete!

Užijte si to,
-Kev
–Sledujte mě na Twitteru!


  1. Kolik databázových indexů je příliš mnoho?

  2. SQL Server BULK INSERT z Linuxu

  3. SQL mezi operátory

  4. Aktualizace profilu pošty databáze v SQL Server (T-SQL)