Едно от нещата, които са едновременно страхотни и ужасни за интернет, е, че след като нещо бъде публикувано в ефира, то по същество никога не изчезва. (Някой ден политиците ще осъзнаят това. Ние можем лесно да проверим тяхната последователност.) Поради дълготрайността на съдържанието, публикувано в интернет, много теми за настройка на производителността се превръщат в „зомбита“. Застреляме ги, но те продължават да се връщат!
С други думи, тези стари препоръки бяха препоръчана най-добра практика отдавна, за конкретна версия на SQL Server, но сега са неподходящи за по-новата версия. Не е необичайно, когато говоря на конференция, да срещна някой, който все още се придържа към настройки и техники, които не са били добра практика от дните на SQL Server 2000. Ръководството за операции на SQL Server 2000 за капацитет/съхранение съдържа много " най-добри практики", които бяха много специфични за версията и вече не се прилагат днес.
Ето един пример. % Disk Time и Disk Queue Length Броячите на PerfMon бяха силно препоръчани като ключови показатели за ефективност за I/O производителност. SQL Server хвърля много I/O на дисковете, използвайки Scatter/Gather, за да увеличи максимално използването на базираната на диск I/O подсистема. Този подход води до кратки изблици на дълги дълбочини на опашка по време на контролни точки и четене напред за екземпляр на SQL Server. Понякога работното натоварване на сървъра е такова, че вашият диск не може да се справи с I/O, насочен към него, и когато това се случи, ще видите и дълги дължини на опашките. Сценарият за кратък взрив не е проблем. Сценарият за удължаване на дължината на опашката обикновено е проблем. Така че това добра практика ли е?
С една дума, не толкова.
Тези броячи все още могат да бъдат от полза за екземпляр на SQL Server, който има само един твърд диск (въпреки че това е изключително рядко в наши дни). Защо?
Броячът на PerfMon % Disk Time е фалшив показател за ефективност по няколко причини. Той не взема предвид асинхронните заявки за вход/изход. Той не може да каже какъв може да бъде реалният профил на производителност за основен RAID набор, тъй като те съдържат множество дискови устройства. Броячът на PerfMon Disk Queue Length също е предимно безполезен, с изключение на SQL сървъри с един физически диск, тъй като кешът на контролера на твърдия диск скрива колко I/O операции действително чакат на опашката или не. Всъщност някои твърди дискове дори имат и малки кешове за запис, което допълнително замъглява въпроса дали I/O наистина е на опашка, в кеша някъде между операционната система и диска, или най-накрая е стигнал до края към CMOS на диска.
По-добри I/O PerfMon броячи
Вместо да използвате тези PerfMon броячи, използвайте Avg Disk Reads/sec , Avg Disk Writes/sec и Avg Disk Transfers/sec за проследяване на производителността на дисковите подсистеми. Тези броячи проследяват средния брой входове/изходи за четене, вход/изход за запис и комбинирани входове/изходи за четене и запис, възникнали през последната секунда. Понякога обичам да проследявам едни и същи показатели по обем данни, а не по скорост на I/O операции. Така че, за да получите тези данни, може да искате да опитате тези специфични за обема PerfMon броячи: Avg Disk Transfer Bytes/sec , Avg Disk Read Bytes/sec и Avg Disk Write Bytes/sec .
За I/O производителност на SQL Server, използвайте динамични изгледи за управление (DMV)
И освен ако не сте живели в пещера, трябва да се уверите, че използвате изгледите за динамично управление (DMV) на SQL Server, за да проверите производителността на I/O за последните версии на SQL Server. Някои от любимите ми DMV за I/O включват:
- 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
И така, как проследявате показателите за I/O ефективност? Кои от тях използвате?
Очаквам с нетърпение да се чуя от вас!
Насладете се,
-Kev
–Последвайте ме в Twitter!
