Борьба за производительность или кто отнимал процессорное время
Началось все с «Неваляшки». О том, что это такое и для чего это было надо описано тут: http://habrahabr.ru/company/oktell/blog/108726/. То есть, мы имели четыре работающих сервера call-центра, одинаково настроенных и с примерно одинаковой конфигурацией внешних и внутренних линий, пользователей и настройкой внутренней БД. На каждый из серверов со стороны оператора связи поступала равномерная звонковая нагрузка, но сервера реагировали на это по разному!
N Конфигурация сервера и операционная система
1 T1300 @ 1.66 1 Гб ОЗУ, Windows 2003 Standard Ed. R2 SP1 32 bit
2 Intel Core Duo E8400 @ 3000 4 Гб ОЗУ, Windows 2003 Standard Ed.SP1 32 bit
3 Intel Pentium 4 3GHz 2 Гб ОЗУ, Windows 2003 Standard Ed. SP2 32 bit
4 E3400 @ 2.60 2 Гб ОЗУ, Windows 2003 Standard Ed. R2 SP2 32 bit
Столкнулись с жалобами на качество связи. Причем, жаловались не на каждый звонок, а на «некоторые». Жаловались на «кваки», очень характерные для VoIP телефонии. Довольно оперативно было выяснено, что причиной появления «кваков» было непредсказуемый рост занятости процессора на одном (первом) из серверов call-центр при возрастании нагрузки. И это при всем притом, что другие сервера такой нагрузки вообще не замечали, и никакого роста нагрузки на процессор при таком же количестве вызовов не наблюдалось. Даже, несмотря на то, что первый сервер был значительно слабее всех остальных, такой картины — роста занятости процессора до 100% — наблюдаться не должно было.
Не стоит, наверное, говорить, что мы прошли стандартный путь «протирки фар», «пинания колес» и пр. В конечном итоге пришли к мнению, что ни настройки самого call-центр, ни его СУБД, на поведение сервера не влияет. Отправной точкой для понимания сущности проблемы послужил тот факт, что в диспетчере задач в списке процессов ни один из процессов не занимал процессорного времени, вместе с тем, на мониторинге быстродействия хронология загрузки процессора показывала непрерывную загрузку процессора ядра на уровне 20%.
Задались целью получить ответ на вопрос чем же занято ядро в том случае, когда нагрузки на все остальные сервисы отсутствуют. Process Explorer — штатная утилита от Microsoft — подсказала, что основным потребителем ресурсов является «Hardware Interrupts». Для дальнейшего анализа причин такого потребления была скачана другая штатная утилита от Microsoft — «Kernrate View». Как и было описано в рекомендациях по использованию, в командной строке выполнили «C:\Program Files\KrView\Kernrates\Kernrate_i386_XP.exe >> log.txt» и, спустя некоторое время, нажав Ctrl-C, остановили. Получили файл log.txt, содержащий информацию вида:
/==============================\
\==============================/
Date: 2010/12/08 Time: 1:09:14
Machine Name: RESERVCC
Number of Processors: 1
PROCESSOR_ARCHITECTURE: x86
PROCESSOR_LEVEL: 6
PROCESSOR_REVISION: 0e08
Physical Memory: 1015 MB
Pagefile Total: 2450 MB
Virtual Total: 2047 MB
PageFile1: \??\C:\pagefile.sys, 1524MB
OS Version: 5.2 Build 3790 Service-Pack: 1.0
WinDir: C:\WINDOWS
Kernrate User-Specified Command Line:
Kernrate_i386_XP.exe
Kernel Profile (PID = 0): Source= Time,
Using Kernrate Default Rate of 25000 events/hit
P0 K 0:00:36.671 (28.5%) U 0:00:09.671 ( 7.5%) I 0:01:22.343 (64.0%) DPC 0:00:29.484 (22.9%) Interrupt 0:00:00.281 ( 0.2%)
Interrupts= 136809, Interrupt Rate= 1063/sec.
Total Profile Time = 128687 msec
Total Avg. Rate
Context Switches, 609407, 4736/sec.
System Calls, 5078088, 39461/sec.
Page Faults, 119817, 931/sec.
I/O Read Operations, 11671, 91/sec.
I/O Write Operations, 209479, 1628/sec.
I/O Other Operations, 229216, 1781/sec.
I/O Read Bytes, 39981700, 3426/ I/O
I/O Write Bytes, 19240135, 92/ I/O
I/O Other Bytes, 7130204725, 31107/ I/O
— Results for Kernel Mode:
— OutputResults: KernelModuleCount = 99
Percentage in the following table is based on the Total Hits for the Kernel
Time 44651 hits, 25000 events per hit — Module Hits msec %Total Events/Sec
intelppm 27457 128685 61 % 5334149
hal 12284 128685 27 % 2386447
ntkrnlpa 2868 128685 6 % 557174
win32k 525 128685 1 % 101993
alder9xp 427 128685 0 % 82954
tcpip 254 128685 0 % 49345
Ntfs 251 128685 0 % 48762
afd 120 128685 0 % 23312
RDPDD 109 128685 0 % 21175
e1e5132 109 128685 0 % 21175
iaStor 97 128685 0 % 18844
NDIS 39 128685 0 % 7576
RDPWD 31 128685 0 % 6022
fltMgr 26 128685 0 % 5051
amon 12 128685 0 % 2331
termdd 10 128685 0 % 1942
CLASSPNP 10 128685 0 % 1942
ftdisk 7 128685 0 % 1359
ipsec 3 128685 0 % 582
Npfs 2 128685 0 % 388
USBPORT 2 128685 0 % 388
volsnap 2 128685 0 % 388
TDTCP 1 128685 0 % 194
rdbss 1 128685 0 % 194
ws2ifsl 1 128685 0 % 194
netbt 1 128685 0 % 194
watchdog 1 128685 0 % 194
PartMgr 1 128685 0 % 194
Далее определяем какой именно драйвер загружает процесс «Hardware Interrupts». В списке лога «Kernrate View» он будет верхним, и рядом в процентах будет показана его доля занимания ядра. Тут стоит обратить внимание, что проценты показывают не общий процент от загрузки системы, а процент загрузки серверного ядра драйверами.
Определили, что этим драйвером является Intelppm (Intel processor power manager). Дальше — google нам в помощь. Интернет велик, могуч и безграничен. Довольно быстро поняли, что проблема с Intelppm возникает, не так уж и часто, вместе с тем, мы были не одни столкнувшиеся с такой бедой. Результат не замедлил себя обнаружить, нашлась статья, в которой не только описывается сама проблема, но и обозначается путь ее решения (Постоянный адрес оригинала статьи тут: http://www.osp.ru/text/print/302/5818429.html)
Далее следуя рекомендациям Стивена Догерти понимаем, что intelppm, является драйвером управления электропитанием процессора, который не нужен на сервере, где питание от аккумулятора и не используется вовсе. Вариантов решений было предложено несколько: переустановка, обновление или остановка неисправного драйвера. Какой варианты выберете вы — смотрите сами, вполне логично тут следовать оригинальным рекомендациям Догерти.
Мы полезли в реестр. Данные драйвера процессора Intel находятся в разделе реестра HKEY_LOCAL_MACHINE/SYSTEM/Current Control Set/Services/intelppm. Для отключения драевера intelppm изменили значение параметра Start с 1 на 4. Специалисты Microsoft, конечно, рекомендуют делать резервную копию реестра, но мы то с вами русские люди, да и что там один параметр поменять с 1 на 4. 
Рестарт помог убедиться, что загрузка процессора в среднем находится в пределах 60-70% даже при полной(!) загрузке сервера call-центр звонками.
Очень интересно выглядит при этом диспетчер устройств: 
Жалуется, ябедничает, плачет: «Драйвер для этого устройства был отключен. Возможно, необходимые функции исполняет другой драйвер. (Код 32), Нажмите кнопку „Диагностика“, чтобы запустить мастер диагностики для данного устройства.» Но на безопасность полетов это уже не влияет 😉
Как исправить Intelppm.sys BSOD на Windows 7,8 или 10
BSOD (синий экран смерти), указывающий на intelppm.sys, появляется для некоторых пользователей Windows при попытке установить новое обновление драйвера или при попытке запустить ресурсоемкую игру или приложение. Глядя на код ошибки, он относится к проблеме с драйвером процессора устройства.
При устранении этой конкретной проблемы следует начать с запуска ряда утилит, способных исправить повреждение системных файлов. Несколько затронутых пользователей подтвердили, что им удалось решить эту проблему после быстрого сканирования SFC и DISM. В более серьезных обстоятельствах вам, возможно, придется прибегнуть к более радикальным мерам, таким как чистая установка или восстановление установки вашей версии Windows.
В случае, если вы используете сторонние AV (особенно AVG Antivirus), временно удалите его и посмотрите, остановятся ли BSODы. Несколько пользователей сообщили, что в их случае сторонний антивирус вызывал проблему из-за ложного срабатывания (по подозрению в крипто-майнинге).
Конечно, могут быть другие сторонние программы, которые могут вызывать такое поведение после вмешательства в драйвер процессора. Вот почему вы должны также уделить время достижению чистого состояния загрузки и следить за ситуацией, чтобы убедиться, что проблема все еще возникает. Если сбои прекращаются, вы можете выборочно включить отключенные элементы автозапуска и процессы, чтобы выяснить, какой виновник вызывает проблему.
Если вы вручную разогнали напряжение и частоту вашего процессора, верните их значения по умолчанию. Более высокие, чем обычно, температуры или недостаточное энергопотребление блока питания — это действительные причины, по которым вы можете увидеть сбои, связанные с intelppm.sys.
В некоторых моделях сбой BIOS также может быть причиной этого неожиданного BSOD. В этом случае установка последней доступной прошивки для вашего графического процессора должна решить эту проблему для вас. Кроме того, если вы никогда не делали этого раньше, вам также следует очистить батарею CMOS, чтобы убедиться, что нет вложенных журналов, которые могли бы вызвать эту проблему.
Запуск сканирования DISM и SFC
Как оказалось, вы можете увидеть BSOD, указывающий на intelppm.sys из-за некоторого типа повреждения системных файлов, которое в конечном итоге влияет на драйвер чипсета. Если этот сценарий применим, скорее всего, вы сможете устранить эту нестабильность, полагаясь на пару встроенных утилит, способных исправлять поврежденные экземпляры (DISM и SFC).
Если вы подозреваете, что имеете дело с поврежденными данными, вам следует начать с тщательного сканирования системных файлов. Эта утилита прекрасно работает без подключения к Интернету. Он использует локально сохраненный архив для сравнения потенциально поврежденных файлов со списком исправных эквивалентов.
Запуск SFC
Примечание. Если вы запускаете этот тип сканирования, не прерывайте его до завершения операции. Закрытие CMD с повышенными правами в середине операции может создать дополнительные логические ошибки, которые могут вызвать другие проблемы.
После завершения операции перезагрузите компьютер и дождитесь завершения следующего запуска. После того, как ваш компьютер снова загрузится, перейдите к сканированию DISM.
Сканирование системных файлов
Примечание. Помните, что для обслуживания образов развертывания и управления ими используется подкомпонент Центра обновления Windows для загрузки исправных копий, которые будут использоваться для замены поврежденных экземпляров.
После завершения сканирования DISM перезагрузите компьютер еще раз и проследите за ситуацией после завершения следующего запуска. Если та же проблема все еще возникает, перейдите к следующему потенциальному решению ниже.
Удаление стороннего AV
Как выяснилось, несколько пользователей, которые часто сталкивались с intelppm.sys при выполнении ресурсоемкого приложения, требующего много ресурсов процессора, обнаружили, что в их случае проблема была вызвана чрезмерно защитным комплектом AV.
Оказывается, что некоторые AV-пакеты могут в конечном итоге вызывать BSOD, указывающий на intelppm.sys, после ложного срабатывания, связанного с подозрениями в крипто-майнинге. В большинстве случаев AVG Antivirus идентифицируется как сторонний AV-пакет, который запускает этот тип поведения.
Если этот сценарий применим, и вы уверены, что на самом деле вы не имеете дело с вредоносным ПО для крипто-майнинга, единственный способ, которым вы сможете решить эту проблему, — это установить ваш текущий AV-пакет или открыть заявку на ошибку с вашей третьей стороной. антивирус.
Имейте в виду, что на большинстве сторонних AV-пакетов невозможно заблокировать их проверку и мониторинг использования процессора и процессов ядра. Таким образом, если ваш AV действительно вызывает это, единственный способ предотвратить возникновение критических сбоев — это вообще удалить сторонний пакет AV и посмотреть, прекратились ли BSODы:
Если вы все еще имеете дело с частыми BSOD, указывающими на файл intelppm.sys, перейдите к следующему потенциальному исправлению ниже.
Выполнение Чистой загрузки
Как сообщают некоторые затронутые пользователи, эта проблема также может возникать из-за некоторого типа стороннего конфликта, который возникает между двумя процессами или приложениями, которые в конечном итоге вызывают критический сбой. Если этот сценарий применим, составление списка потенциальных преступников практически невозможно, учитывая, что список потенциальных конфликтов практически бесконечен.
Однако существует процедура, которая позволит вам определить, действительно ли эта проблема вызвана конфликтом третьей стороны. Загрузив компьютер в чистое состояние загрузки, вы убедитесь, что ни один из сторонних элементов не может быть запущен, поэтому, если сбои intelppm.sys прекратятся, вы точно будете знать, что проблема была вызвана сторонним элементом.
Загрузив компьютер в чистом состоянии загрузки, вы обеспечите запуск только собственных процессов Windows и элементов автозагрузки.
Если критический сбой BSOD, указывающий на штраф intelppm.sys, больше не происходит, вы успешно подтвердили, что конфликт третьей стороны ранее вызывал проблему. В этом случае систематически повторно активируйте каждый процесс и элементы запуска, которые вы ранее отключили, и посмотрите, исправлена ли проблема в настоящее время.
Если та же проблема все еще возникает, перейдите к следующему потенциальному решению ниже.
Сброс разогнанных частот (если применимо)
Как оказалось, вы также можете увидеть эту ошибку в случае, когда вы используете разогнанные частоты и напряжения для вашего процессора. Более высокие, чем обычно, температуры в сочетании с ненадлежащим блоком охлаждения могут создать случаи, когда ЦПУ вынужден отключать питание, чтобы предотвратить повреждение, вызванное чрезмерным нагревом.
Другая возможность состоит в том, что ваш ПК использует блок питания ниже номинального и он не может обеспечить достаточное количество энергии для удовлетворения потребностей, чему способствует более высокое напряжение.
Если этот сценарий применим, и вы ранее разогнали значения по умолчанию вашего ЦП, вернитесь к значениям по умолчанию и повторите действия, которые ранее вызывали BSOD, указывающий на файл intelppm.sys.
Если критические сбои больше не происходят, когда разгон отключен, поиграйте со значениями, пока вы не достигнете стабильного состояния, или инвестируйте в более эффективную систему охлаждения для вашего процессора.
В случае, если эта проблема не применима, перейдите к следующему потенциальному решению ниже.
Обновить версию BIOS (если применимо)
Как оказалось, BSOD, указывающие на диск ЦП, также могут быть вызваны сбоями BIOS. Было подтверждено, что это происходит на ноутбуках Lenovo, но могут быть и другие производители с таким же поведением.
Если вы планируете обновить версию BIOS, пытаясь решить эту проблему, имейте в виду, что процесс будет сильно различаться в зависимости от производителя вашей материнской платы. В настоящее время большинство производителей имеют свои собственные утилиты для прошивки, которые облегчат этот процесс.
Если вы хотите пройти через это, откройте поисковую систему и выполните запрос типа «* Модель вашей материнской платы * + Обновление BIOS». Из списка результатов найдите официальную документацию и внимательно ее прочитайте, поймите риски и поймите весь процесс до его начала.
Важно: установка обновления BIOS может привести к поломке материнской платы, если вы не будете придерживаться шагов, описанных в документации. Если вы никогда не обновляли BIOS раньше, мы рекомендуем держаться подальше от этого возможного исправления.
Если вы уже используете последнюю версию BIOS или не хотите обновляться, перейдите к следующему потенциальному исправлению ниже.
Очистка CMOS
Если вы ранее не очищали батарею CMOS, вы должны сделать это и посмотреть, перестанут ли происходить сбои BSOD. Возможно, что вложенные журналы, оставленные вашей ЦП, вызывают этот тип нестабильности. Если этот сценарий применим, вы сможете исправить его, очистив батарею CMOS (дополнительный металлооксидный полупроводник).
На настольных компьютерах и ноутбуках батарея CMOS, также известная как RTC или NVRAM, отвечает за хранение различной информации, связанной с процессами вашего компьютера. Очистите его, чтобы запустить последовательность загрузки заново (без использования каких-либо данных, сохраненных в предыдущих сеансах).
Если вы хотите очистить CMOS в попытке исправить критические ошибки, связанные с intelppm.sys, следуйте инструкциям ниже:
Если проблема все еще возникает, перейдите к следующему потенциальному решению ниже.
Сброс каждого компонента Windows
Если ни одно из возможных исправлений, приведенных выше, не позволило вам решить проблему, и вы все еще видите частые BSOD, указывающие на файл intelppm.sys, скорее всего, вы имеете дело с каким-либо типом повреждения, которое не может быть решено традиционным способом. Если этот сценарий применим, вы должны выполнить сброс всех файлов, связанных с Windows.
Если эта операция работает и критическая ошибка прекращается, вы успешно подтвердили, что проблема связана с программным обеспечением.
Чтобы сбросить все соответствующие компоненты Windows, у вас обычно есть 2 различных пути вперед:
Если вы уже выполнили чистую установку / восстановление и по-прежнему испытываете тот же тип BSOD, существует очень высокая вероятность того, что вы на самом деле имеете дело с аппаратной проблемой (скорее всего с неисправным процессором Intel). В этом случае вам следует отнести компьютер к квалифицированному специалисту.
