Загальні відомості
Microsoft SQL Server 2005 використовує лічильник ПРОЦЕСОРІВ із високою роздільною здатністю, щоб забезпечити можливість використання функції microsecond хронометражу. Мікросекунда – один мільйонний другий (або один тисячний на мілісекунди). Однак значення хронометражу SQL Server можуть бути неправильними, якщо використовуються технології, які змінюють частоти процесора. Наприклад, ця проблема може виникати під час використання будь-якого з наведених нижче технологій.
-
Степінг процесора
-
Тихий технологія AMD Cook'n
-
Різні енергетичні схеми
У цій статті наведено методи та додаткові відомості, які допоможуть вирішити цю проблему.
Ознаки
Якщо ви використовуєте оператор "УСТАНОВИТИ СТАТИСТИКУ часу" для відображення виконання, аналізу та компіляції сервера, ви можете отримати неправильні значення. Наприклад, може бути повідомлення про те, що час виконання SQL Server є ще більшим, ніж ПРОЦЕСОРНИЙ час. Ця проблема може негативно вплинути на точність Настроювання продуктивності. Ця проблема виникає, якщо ви використовуєте один із технологій, перелічених у розділі "зведення" на сервері.
Причина
Ця проблема виникає через те, що під час використання цих технологій змінюються частоти процесора. SQL Server 2005 використовує лічильник ПРОЦЕСОРІВ із високою роздільною здатністю, щоб забезпечити можливості мікросекундної хронометражу. Якщо частоти процесора змінюються, щоб економити енергію та знизити продуктивність тепла, може бути неправильна тривалість обчислення.
Спосіб вирішення
Відомості про пакет оновлень
Щоб вирішити цю проблему, отримайте найновіший пакет оновлень для SQL Server 2005. Щоб отримати докладні відомості, клацніть цей номер статті, щоб переглянути статтю в базі знань Microsoft Knowledge Base:
913089 Отримання найновішого пакета оновлень для SQL Server 2005Примітка . У SQL Server 2005 Service Pack 3 і в пізніші пакети оновлень не використовується позначка часу для процесора. Ці версії SQL Server 2005 використовують надійніший таймер, який має максимальну точність у 1 мілісекунди.
Стан
Цю проблему було спочатку виправлено в SQL Server 2005 Service Pack 3.
Інші способи вирішення
SQL Server 2005 потребує відомих і стабільних точок даних для виконання точної настройки продуктивності. Якщо на комп'ютері активовано динамічне настроювання частоти процесора, їх можна вимкнути, щоб процесори могли утримувати постійну частоту частоти, перш ніж відстежувати та настроювати продуктивність SQL Server. Для цього використовуйте наведені нижче способи.
Настроювання схеми живлення на комп'ютері для примусового того, що процесори залишаться на максимальній частоті
Для цього виконайте описані нижче дії.
-
Натисніть кнопку Пуск, виберіть команду виконати, введіть powercfg. cplі натисніть кнопку OK.
-
У діалоговому вікні Властивості параметрів електроживлення натисніть кнопку завжди в списку Power схем .
-
Клацніть OK.
Може відбутися дрейф. Дрейф – це розбіжність між значеннями частоти процесора. Щоб отримати докладніші відомості, ознайомтеся з розділом "дрейф". У цьому випадку потрібно перезавантажити Microsoft Windows, щоб повторно синхронізувати частоти всіх процесорів після змінення схеми живлення. Якщо ви не можете перезавантажити комп'ютер, увімкніть використання процесорів SQL Server, щоб уникнути потоків робочих процесів SQL Server від переходу між ЦП. Після цього не потрібно перезавантажувати комп'ютер, навіть якщо відбувається розбіжність між значеннями ПРОЦЕСОРНОЇ частоти. Щоб увімкнути близькість процесора SQL Server для всіх процесорів на сервері, потрібно використовувати іншу маску, залежно від кількості логічних процесорів, які знаходяться на сервері. У таблиці нижче наведено приклади сценаріїв.
|
Номер процесора |
Твердження для ввімкнення подібності процесорів |
|---|---|
|
2 процесори |
символ подібності sp_configure "Exec", 0x00000003GOreconfigureGO |
|
04 процесори |
"маска" sp_configure ", 0x0000000FGOreconfigureGO" Exec " |
|
08 процесорів |
символ подібності sp_configure "Exec", 0X000000ffgoreeconefiurego |
|
16 процесорів |
символ подібності sp_configure "Exec", 0X0000fffieeconguurego |
|
Процесори 32 |
маска "середній sp_configure" ("", "0Xffff") |
Примітка. Це може бути недостатньо для вимкнення функцій варіаційної частоти процесора на рівні BIOS. Різні утиліти сторонніх постачальників можуть змінювати частоти процесора. Деякі впровадження дають змогу змінювати частоту, навіть якщо процесори доступні в розділі Максимальна система Power схема. У цьому випадку потрібно відключити ці сторонні утиліти, коли ви виконуєте Настроювання продуктивності в SQL Server 2005.
Використання сторонніх утиліт і драйверів для синхронізації частот процесора та лічильників ПРОЦЕСОРНИХ годинників
У разі виникнення рідкісних подій система може вимагати від виробника оновлення, щоб вирішити проблеми з частотою процесора. Радимо перевірити систему для найновішої версії BIOS, мікрокоманд і оновлень мікропрограм, якщо ви підозрюєте, що система може мати проблему.
Додаткові відомості
Microsoft SQL Server 2000 і попередні версії SQL Server використовують механізми хронометражу Windows. Механізми хронометражу використовують мілісекунди-прецизійні значення. Зазвичай це точність від 10 до 15 мс. Однак точність може бути великою, як і 55 MS. Запити SQL Server часто виконуються в межах однозначних прольотів у мілісекунди або мікросекундної проміжки часу. Ця точність вимагає таймера з високою роздільною здатністю. Таким чином, ці версії SQL Server повідомляють про тривалість певних запитів у вигляді 0 мс. Таким чином, важко Відстежувати продуктивність і настроїти продуктивність SQL Server у попередніх версіях SQL Server. SQL Server 2005 покращує точність, використовуючи лічильник ПРОЦЕСОРІВ високої роздільної здатності, щоб забезпечити можливості мікросекундної синхронізації. Під час використання технологій, перелічених у розділі "зведення", значення часу, що повідомляються, можуть бути неправильними. Ця проблема може вплинути на перелічені нижче об'єкти та функції.
-
Трасування подій:
-
Подія " Увага "
-
Події на вузлі "Збережена процедура"
-
Події в вузлі TSQL
-
Події в вузлі "об'єкти"
-
Події в вузлі "транзакції"
-
-
Динамічні подання керування:
-
sys.dm_exec_query_stats
-
sys.dm_exec_requests
-
sys.dm_exec_sessions
-
sys.dm_io_pending_io_requests
-
sys.dm_os_ring_buffers
-
sys.dm_os_sys_info
-
sys.dm_io_virtual_file_stats
-
sys.dm_os_wait_stats
-
-
Інструкція з НАСТРОЮВАННЯ ЧАСОВОЇ статистики
-
Системна таблиця sysprocesses
Після інсталяції пакета оновлень 2 (SP2) SQL Server 2005 під час входу в журнал помилок сталася помилка під час роботи сервера SQL Server, коли SQL Server виявляє, що таймер високої роздільної здатності не синхронізовано між процесорами. Повідомлення про помилку вказує на те, що хронометраж продуктивності може бути неточним, і користувачі повинні використовувати дані про продуктивність з обережністю. Текст повідомлення про помилку нагадує одне з таких повідомлень про помилку:
Повідомлення про помилку 1
Лічильник часових штампів ПРОЦЕСОРІВ для планувальника з ідентифікатором 2 не синхронізується з іншими процесорами.
Повідомлення про помилку 2
Частота поділок ПРОЦЕСОРНОГО часу змінилося з 191469 до 1794177 на мілісекунди. Використовуватиметься нова частота
SQL Server використовує інструкції з лічильника в реальному часі (RDTSC), щоб отримати лічильник поділок для 64. Це значення можна розділити на частоту процесора, щоб перетворити значення на мілісекунди. Зміни хронометражу можуть виникати, коли частота процесора або відбувається дрейф.
Степінг процесора
Степінг ПРОЦЕСОРІВ визначається як навмисна зміна частоти процесора. Виконання процесора також можна знати як технології Intel SpeedStep або AMD PowerNow! технології. Коли відбувається виконання процесора, швидкість процесора може збільшитися або зменшити приріст, як-от 50 МГц, щоб зберегти енергію та зменшити продуктивність тепла. Процесори, які знаходяться в межах нерівномірного вузла доступу до пам'яті (NUMA), не мають самостійно настроювати частоти. У наведеній нижче таблиці показано, як зміни, внесені до процесора, можуть вплинути на обчислення хронометражу.
|
Дії |
RDTSC кліщі |
Кліщі на мілісекунди (частота) |
Час настінного годинника |
|---|---|---|---|
|
Початок пакета |
1 |
200 |
0 |
|
Частота виконання кроку вниз |
200 |
100 |
1ms |
|
Кінцева партія |
500 |
3ms |
|
|
ПІДСУМКИ |
500 |
4ms |
На сервері SQL Server відображаються кліщі RDTSC на початку та наприкінці RDTSC. Потім SQL Server ділить кліщі за частотним значенням. У цьому прикладі наведені нижче обчислення хронометражу трапляються під час використання частотного значення 200 або 100.
-
Частота 200: 500/200 = 2,5 MS
-
Частота 100: 500/100 = 5 мс
Жоден із обчислених термінів не відповідає фактичному часу настінного годинника в 4 мс. Якщо цей обчислення використовується в RPC: завершена подія трасування, дані про Тривалість і час завершення відображаються неправильно. У RPC: завершена подія захоплює початковий час годинника на стіні та кількість поділок процесора. Щоб отримати більшу роздільну здатність, ніж в ОС Windows Server 2005, дані про Тривалість і час кінцевого часу в трасування SQL Server обчислюються за допомогою лічильника, що минув, за кількістю поділок процесора. Стовпець " час " обчислюється, додавши стовпець " Тривалість " до стовпця " час початку ". У цьому прикладі стовпець " час " обчислюється за допомогою неправильного додавання 2,5 MS або 5 MS до часу початку.
Дрейф
Дрейф – це розбіжність у значеннях ПРОЦЕСОРНОГО годинника. Системи, які мають кілька процесорів, можуть створювати різні значення тактової години в той самий момент часу. Хоча це не часто, процесори можуть виникати з плином часу. У наведеному нижче прикладі показано, як зміни в дрейф можуть вплинути на результат для стовпця дані тривалості в SQL Server трасування. У прикладі передбачається, що частота процесора залишається стабільним на 200 кліщів на мілісекунди. У наведеній нижче таблиці показано події в цьому сценарії.
|
Дії |
ПРОЦЕСОР із запланованим Windows |
ПРОЦЕСОР 1 RDTSC |
ПРОЦЕСОР 2 RDTSC |
Час настінного годинника |
|---|---|---|---|---|
|
Початок пакета |
1 |
100 |
1100 |
0 |
|
Кінцева партія |
2 |
900 |
1900 |
4 мс |
|
ПІДСУМКИ |
4 мс |
На сервері SQL Server відображаються кліщі RDTSC, як у точках початку, так і в кінцеву точку. Потім SQL Server ділить RDTSC кліщі за частотним значенням. У цьому прикладі Windows запланував робочі потоки SQL Server на двох різних процесорах. Робоча нитка SQL Server, у якій служби пакета спочатку запускали перший процесор (ЦП 1). Тим не менше, виконання пакетної обробки перервано в деякій точці, а SQL Server надсилала виконання пакетного завдання, що очікує очікування. Коли сервер SQL Server надсилала ланцюжок робочих пристроїв SQL Server, що відповідатимуть цьому пакету до повторного запуску, Windows надіслала потік для запуску на другому ПРОЦЕСОРІ (ЦП 2). Робочий потік SQL Server завершено, що працює на ПРОЦЕСОРІ 2. Через дрейф процесора кінцевий значення, яке було захоплено з ЦП 2, було 1900 замість 900. Цю поведінку можна уникнути, Якщо ввімкнути близькість процесора SQL Server. У цьому прикладі використовуються наведені нижче обчислення хронометражу:
-
Неправильне, але повідомлене значення: (1900 – 100 = 1800)/200 = 9 MS
-
Правильне значення: (900 – 100 = 800)/200 = 4 мс
Значення стовпця " Тривалість " для RPC: завершена подія буде повідомлено як 9 МС замість 4 мс. Цей результат має більш ніж удвічі правильне значення 4 мс. Оповіщення про дрейф додаються до SQL Server 2005, що вказує на те, що результати роботи, наведені раніше, можуть бути ненадійними. У деяких нерозкритих ситуаціях SQL Server 2005 SP2 може повідомляти про попереджувальні повідомлення про таке:
-
Повідомлення про помилкові оповіщення про дрейф
-
Дрейф може бути в десятках мілісекунд, не викликаючи помітних системних ефектів
Ви повинні бути обережні, коли ви оцінюєте результати, пов'язані з продуктивністю, і коли Ви порівнюєте результати, пов'язані з продуктивністю, до хронометражу настінного годинника. Якщо немає ознак інших проблем із продуктивністю, можна ігнорувати попередження про дрейф. Наприклад, зазвичай можна ігнорувати оповіщення про дрейф в таких ситуаціях:
-
Процеси виконуються належним чином.
-
Запити SQL Server не виконуються в незрозумілий візерунок.
-
Ви не бачите ознак інших вузьких місць.
Однак, перш ніж ігнорувати попередження про дрейф, радимо звернутися до виробника, щоб переконатися, що немає відомих проблем із RDTSC. Ви можете використовувати прапор трасування 8033 (– T8033), щоб повернутися до функції звітування в вихідній версії SQL Server 2005 і в SQL Server 2005 SP1. Вихідна версія SQL Server 2005 і SQL Server 2005 SP1 не повідомляють про повідомлення про дрейф попередження. Якщо ви використовуєте вихідну версію версії SQL Server 2005 або SQL Server 2005 SP1 без проблем, зазвичай можна ігнорувати повідомлення.
Чому оператор затримки WAITFOR працює правильно? Які відомості про періодичні системні процеси?
Під час розробки високої роздільної здатності не впливають механізми тайм-відповіді. SQL Server не використовує таймер високої роздільної здатності для дій на основі таймера. Деякі дії в часі базуються на таймеру зменшення роздільної здатності, у якому використовується функція GetTickCount . Ці дії часом включають блокування часу очікування, положення затримки WAITFOR та виявлення взаємоблокування.
Щоб отримати докладні відомості, клацніть наведені нижче номери статей, щоб переглянути статті в базі знань Microsoft Knowledge Base:
938448 Сервер Windows Server 2003 може виникати під час роботи з часово-штампуванням, якщо сервер використовує двоядерні процесори AMD Opteron або багатопроцесорні процесори AMD Opteron
895980 Програми, які використовують функцію QueryPerformanceCounter, можуть працювати неналежним чином в ОС Windows Server 2003 і в операційній системі Windows XPПродукти від сторонніх постачальників, які обговорюються в цій статті, виробляються компаніями незалежних від корпорації Майкрософт. Корпорація Майкрософт не надає жодних гарантій, неявних або інших, про продуктивність або надійність цих продуктів.
