1. Этот сайт использует файлы cookie. Продолжая пользоваться данным сайтом, Вы соглашаетесь на использование нами Ваших файлов cookie. Узнать больше.

Аномально высокая загрузка CPU после профилактики 21.12.10

Тема в разделе "Архив", создана пользователем Radix, 24 дек 2010.

?

Наблюдается ли у Вас подобная проблема?

  1. Да, проблема для меня актуальна

    84,4%
  2. Нет, проблем с необычной загрузкой CPU не испытываю

    15,6%
Статус темы:
Закрыта.
  1. Radix

    Radix Innova Group

    Регистрация:
    10.02.10
    Сообщения:
    5.539
    Симпатии:
    222
    уважаемые пользователи!

    выделяем отдельный топик для обсуждения проблемы связанной с необычно сильной загрузкой cpu при игре в lineage 2.

    прежде всего интересует та группа пользователей, которые столкнулась с данным эффектом после проведения профилактических работ 21.12.10 (обновлен gameshielddll до версии 3).
    опишите свой случай (как было, что стало, что меняли или не меняли ничего), прикрепите dxdiag отчет о своей системе. попытаемся вместе все проанализировать и найти закономерности, которые, возможно, помогут решить данный вопрос.

    ---
    что нам понадобится прежде всего для анализа:
    • process explorer
    • windows server 2003 resource kit tools или более узкий вариант:krview (заявлена работа далеко не на всех ос, т.к. набор достаточно старый, но попробовать стоит - у меня на win 7 работает, к примеру)
    • ваш dxdiag отчет: пуск - выполнить - ввести dxdiag - в самой программе после анализа сохранить отчет в файл.
    • msinfo32 отчет: пуск - выполнить - ввести msinfo32 - в самой программе после анализа сохранить отчет в файл.
    • скриншот загрузки cpu из диспетчера задач или process explorer.

    что с этим делать:
    • дожидаемся интенсивной загрузки cpu
    • в process explorer смотрим, какой процесс нагружает cpu
    • попутно снимаем скриншоты нагрузки
    • открываем командную строку: пуск - выполнить - вводим cmd - ок
    • перетаскиваем в окно утилиту kernrate.exe (из архива, который скачали ранее). пока не нажимаем enter
    • ловим момент нагрузки, запускаем утилиту kernrate.exe нажатием enter в командном окне
    • ждем пару секунд (4-5 не больше)
    • нажимаем в командном окне ctrl+c (т.е. прерываем сбор статистики)
    • копируем полученный лог и отправляем на форум
    • делаем отчеты msinfo32, dxdiag и отправляем их на форум.
     
    Последнее редактирование модератором: 24 дек 2010
  2. Radix

    Radix Innova Group

    Регистрация:
    10.02.10
    Сообщения:
    5.539
    Симпатии:
    222
    через files.mail.ru или аналогичные...
     
  3. Radix

    Radix Innova Group

    Регистрация:
    10.02.10
    Сообщения:
    5.539
    Симпатии:
    222
    damnessar, скажем так. я предлагаю помощь от себя и (если кто-то захочет помогать в разборе и систематизации) представителей коммьюнити. примешивать сюда технических специалистов компании не нужно (хотя, безусловно, они будут следить и вносить поправки-дополнения в ход нашего обсуждения, если таковое случится, и им также интересны результаты данной работы). полигон технических специалистов - прежде всего система "саппорт". также вы и тут можете увидеть их топики. но решено выделить отдельный - проще анализировать.

    тестирование же было, и для данной версии - достаточно продолжительное, а проблема выявилась далеко не у многих (смотрите общую тему по проблемам профилактики). даже для меня составляет сейчас трудность найти пользователей, которые могут поделиться информацией об этом. не верите моим словам - не вопрос. на форуме есть группа тестеров среди пользователей - спросите у них, какие недочеты они заметили, сколько проходило тестирование, какие варианты были найдены и т.п. на этом вводную часть считаю законеченной. если что-то интересно - пишите в лс, не будем засорять топик.

    p.s. к решению никого не принуждаю, не нужен топик - он сам уйдет вниз странички, если не будет активности.


    ---

    непосредственно к проблеме. нагрузка именно после профилактики? что в системе меняли/обновлялось ли программное обеспечение? есть ли возможность воспользоваться process explorer-ом для анализа пиковой загрузки?
     
    Последнее редактирование модератором: 24 дек 2010
  4. Radix

    Radix Innova Group

    Регистрация:
    10.02.10
    Сообщения:
    5.539
    Симпатии:
    222
    я поправил пост выше. если не затруднит - уточните пару моментов.
     
  5. Radix

    Radix Innova Group

    Регистрация:
    10.02.10
    Сообщения:
    5.539
    Симпатии:
    222
    вечер, пятница, я уже плохо соображаю и не понял, что означает эта фраза. не могли бы уточнить? что за главная рабочая программа?
    по поводу видеокамеры - требовалось установить для корректной работы чего? машины/оборудования?
    случаем соответствующую "горячую клавишу/комбинацию" не нажимаете, на которую может реагировать система?
     
  6. tigran13

    tigran13 User

    Регистрация:
    23.12.10
    Сообщения:
    11
    Симпатии:
    0
    всё дело в том, что я не играл до профилактики, я как бы перса даже создать не могу из-за зависания л2, поэтому я не знаю, было ли это у меня до обновления)
     
  7. Radix

    Radix Innova Group

    Регистрация:
    10.02.10
    Сообщения:
    5.539
    Симпатии:
    222
    dxdiag отчет сделайте пожалуйста.
    пуск - выполнить - введите dxdiag - ок
    запустится программа, в которой нужно нажать нечто вроде "сохранить все сведения..." и выбрать имя файла для сохранения отчета. отчет присылайте мне через файлообменники.
     
  8. Anthonym

    Anthonym User

    Регистрация:
    18.12.09
    Сообщения:
    9
    Симпатии:
    0
    win7 x64 . цп-amd athlon(tm) 64 x2 dual core processor 5200+ (2 cpus), ~2.6ghz
    при старте загрузка цп 60%. мб и раньше так было. но теперь при входе в игру очень сильно притормаживает в игре, потом как бы все нормализуется. при это загрузка цп остается такая же около 60%.
    p/s. кроме dxdiag что еще скинуть для полноты "картины"?
     
  9. Radix

    Radix Innova Group

    Регистрация:
    10.02.10
    Сообщения:
    5.539
    Симпатии:
    222
    anthonym, не знаю, можно помочь ли в вашем случае снизить нагрузку. попробуйте посмотреть в process explorer http://technet.microsoft.com/en-us/sysinternals/bb896653, что нагружает систему.
    вот у товарища tigran13 - явно "неполадки" в ядре ос, т.к. не столь игра загружает процессор, сколько системные процессы. как у вас - нужно смотреть.
     
  10. tigran13

    tigran13 User

    Регистрация:
    23.12.10
    Сообщения:
    11
    Симпатии:
    0
  11. 1234vik4321

    1234vik4321 User

    Регистрация:
    03.02.10
    Сообщения:
    5.153
    Симпатии:
    252
    что вот? картинка то ему зачем? читай внимательно что он просит
     
  12. tigran13

    tigran13 User

    Регистрация:
    23.12.10
    Сообщения:
    11
    Симпатии:
    0
  13. Radix

    Radix Innova Group

    Регистрация:
    10.02.10
    Сообщения:
    5.539
    Симпатии:
    222
    скачайте: krview, установите. затем выполните следующие шаги:
    • открываем командную строку: пуск - выполнить - вводим cmd - ок
    • перетаскиваем в окно утилиту kernrate_i386_xp.exe (из архива, который скачали ранее). пока не нажимаем enter (см. картинки под спойлером):
      http://i036.**********/1012/e2/afdada65e3a8.jpg
      http://i038.**********/1012/86/6fbad2070a15.jpg
      enter пока не жмем! ждем, как появится нагрузка на процессор!
    • ловим момент нагрузки, запускаем утилиту kernrate_i386_xp.exe нажатием enter в командном окне
    • ждем пару секунд (4-5 не больше)
    • нажимаем в командном окне ctrl+c (т.е. прерываем сбор статистики)
    • копируем полученный лог и отправляем на форум
    важно поймать именно момент нагрузки на процессор (если она постоянна, то без проблем)
     
    Последнее редактирование модератором: 24 дек 2010
  14. tigran13

    tigran13 User

    Регистрация:
    23.12.10
    Сообщения:
    11
    Симпатии:
    0
    kernel profile (pid = 0): source= time,
    using kernrate default rate of 25000 events/hit
    starting to collect profile data

    ***> press ctrl-c to finish collecting profile data
    ===> finished collecting data, starting to process results

    ------------overall summary:--------------

    p0 k 0:00:00.281 ( 6.1%) u 0:00:00.000 ( 0.0%) i 0:00:04.296 (93.9%) dpc
    0:00:00.000 ( 0.0%) interrupt 0:00:00.000 ( 0.0%)
    interrupts= 4287, interrupt rate= 936/sec.


    total profile time = 4578 msec

    bytesstart bytesstop byt
    esdiff.
    available physical memory , 1286582272, 1288298496, 1716
    224
    available pagefile(s) , 4337405952, 4336816128, -589
    824
    available virtual , 2132418560, 2131636224, -782
    336
    available extended virtual , 0, 0,
    0

    total avg. rate
    context switches , 3861, 843/sec.
    system calls , 11307, 2470/sec.
    page faults , 531, 116/sec.
    i/o read operations , 157, 34/sec.
    i/o write operations , 101, 22/sec.
    i/o other operations , 918, 201/sec.
    i/o read bytes , 144827, 922/ i/o
    i/o write bytes , 191904, 1900/ i/o
    i/o other bytes , 180090, 196/ i/o

    -----------------------------

    results for kernel mode:
    -----------------------------

    outputresults: kernelmodulecount = 142
    percentage in the following table is based on the total hits for the kernel

    time 1713 hits, 25000 events per hit --------
    module hits msec %total events/sec
    hal 1661 4578 96 % 9070554
    ntkrnlpa 21 4578 1 % 114678
    spider 13 4578 0 % 70991
    win32k 13 4578 0 % 70991
    fltmgr 2 4578 0 % 10921
    tcpip 1 4578 0 % 5460
    ntfs 1 4578 0 % 5460
    dwprot 1 4578 0 % 5460

    ================================= end of run ==================================
    ============================== normal end of run ==============================
     
  15. Radix

    Radix Innova Group

    Регистрация:
    10.02.10
    Сообщения:
    5.539
    Симпатии:
    222
    это в момент сильной нагрузки? а что даст та же команда только если приписать к ней:
    -z hal.dll

    т.е. получится нечто вроде
    kernrate_i386_xp.exe -z hal.dll
    методика запуска та же.
     
  16. tigran13

    tigran13 User

    Регистрация:
    23.12.10
    Сообщения:
    11
    Симпатии:
    0
    /==============================\
    < kernrate log >
    \==============================/
    date: 2010/12/24 time: 22:01:16
    machine name: tigran
    number of processors: 1
    processor_architecture: x86
    processor_level: 15
    processor_revision: 2f02
    physical memory: 2048 mb
    pagefile total: 4962 mb
    virtual total: 2047 mb
    pagefile1: \??\d:\pagefile.sys, 3069mb
    os version: 5.1 build 2600 service-pack: 3.0
    windir: c:\windows

    kernrate user-specified command line:
    c:\documents and settings\╥шуёрэ\╨рсюўшщ ёєюы\krview\krview\kernrate_i386_xp.exe
    -z hal.dll


    kernel profile (pid = 0): source= time,
    using kernrate default rate of 25000 events/hit
     
  17. Radix

    Radix Innova Group

    Регистрация:
    10.02.10
    Сообщения:
    5.539
    Симпатии:
    222
    он вроде еще статистику не стал собирать
    а кстати скачайте process explorer и посмотрите, что из компонента system нагружает систему? hardware interrupts или еще что-то?
     
    Последнее редактирование модератором: 24 дек 2010
  18. tigran13

    tigran13 User

    Регистрация:
    23.12.10
    Сообщения:
    11
    Симпатии:
    0
    заскринить всё окно проги?
     
  19. Radix

    Radix Innova Group

    Регистрация:
    10.02.10
    Сообщения:
    5.539
    Симпатии:
    222
    как удобнее, можно и все.
    и все таки запустите kernrate еще раз - только подождите пока собирать статистику начнет. он наверное отладочные символы просто скачивал для работы - поэтому результатов не выдал, т.к. его прервали еще до начала сбора.
     
  20. tigran13

    tigran13 User

    Регистрация:
    23.12.10
    Сообщения:
    11
    Симпатии:
    0
    ------------overall summary:--------------

    p0 k 0:02:08.015 ( 8.9%) u 0:21:48.328 (91.1%) i 0:00:00.000 ( 0.0%) dpc
    0:00:44.718 ( 3.1%) interrupt 0:00:03.703 ( 0.3%)
    interrupts= 2358894, interrupt rate= 1642/sec.


    total profile time = 147853 msec

    bytesstart bytesstop byt
    esdiff.
    available physical memory , 793317376, 764411904, -28905
    472
    available pagefile(s) , 3725602816, 3705257984, -20344
    832
    available virtual , 2132275200, 2131636224, -638
    976
    available extended virtual , 0, 0,
    0

    total avg. rate
    context switches , 2644836, 1841/sec.
    system calls , 12353734, 8601/sec.
    page faults , 599507, 417/sec.
    i/o read operations , 38107, 27/sec.
    i/o write operations , 21405, 15/sec.
    i/o other operations , 353561, 246/sec.
    i/o read bytes , 35435976, 930/ i/o
    i/o write bytes , 38410680, 1794/ i/o
    i/o other bytes , 50362568, 142/ i/o

    -----------------------------

    results for kernel mode:
    -----------------------------

    outputresults: kernelmodulecount = 145
    percentage in the following table is based on the total hits for the kernel

    time 81585 hits, 25000 events per hit --------
    module hits msec %total events/sec
    ntkrnlpa 27385 1436343 33 % 476644
    alcxwdm 17536 1436343 21 % 305219
    hal 11483 1436343 14 % 199865
    win32k 8334 1436343 10 % 145055
    spider 8325 1436343 10 % 144899
    dwprot 1426 1436343 1 % 24819
    ati3duag 1205 1436343 1 % 20973
    ntfs 741 1436343 0 % 12897
    atikvmag 721 1436343 0 % 12549
    portcls 715 1436343 0 % 12444
    aswsp 555 1436343 0 % 9659
    spce 415 1436343 0 % 7223
    dxg 396 1436343 0 % 6892
    fltmgr 290 1436343 0 % 5047
    ati2cqag 286 1436343 0 % 4977
    tcpip 224 1436343 0 % 3898
    nvatabus 205 1436343 0 % 3568
    ks 203 1436343 0 % 3533
    aswmon2 181 1436343 0 % 3150
    ati2dvag 151 1436343 0 % 2628
    aswtdi 114 1436343 0 % 1984
    ndis 82 1436343 0 % 1427
    sysaudio 61 1436343 0 % 1061
    npfs 53 1436343 0 % 922
    tdi 50 1436343 0 % 870
    usbport 45 1436343 0 % 783
    nvnrm 44 1436343 0 % 765
    sr 42 1436343 0 % 731
    watchdog 37 1436343 0 % 643
    frost 32 1436343 0 % 556
    afd 24 1436343 0 % 417
    nvenetfd 19 1436343 0 % 330
    ksecdd 17 1436343 0 % 295
    ndiswan 14 1436343 0 % 243
    psched 13 1436343 0 % 226
    classpnp 13 1436343 0 % 226
    scsiport 11 1436343 0 % 191
    hidclass 10 1436343 0 % 174
    aswfsblk 9 1436343 0 % 156
    atkdisp 9 1436343 0 % 156
    amnppj4y 9 1436343 0 % 156
    nwlnkspx 8 1436343 0 % 139
    wanarp 8 1436343 0 % 139
    netbt 8 1436343 0 % 139
    aqkq643n 7 1436343 0 % 121
    pxhelp20 7 1436343 0 % 121
    kmixer 6 1436343 0 % 104
    usbohci 6 1436343 0 % 104
    acpi 6 1436343 0 % 104
    lmouke 5 1436343 0 % 87
    hidparse 5 1436343 0 % 87
    usbhub 5 1436343 0 % 87
    ipnat 4 1436343 0 % 69
    raspppoe 3 1436343 0 % 52
    sfhlp02 3 1436343 0 % 52
    wdmaud 2 1436343 0 % 34
    nwlnkipx 2 1436343 0 % 34
    rasacd 2 1436343 0 % 34
    imapi 2 1436343 0 % 34
    nwlnknb 1 1436343 0 % 17
    hidusb 1 1436343 0 % 17
    usbccgp 1 1436343 0 % 17
    ipsec 1 1436343 0 % 17
    ati2mtag 1 1436343 0 % 17
    cdrom 1 1436343 0 % 17
    mup 1 1436343 0 % 17
    disk 1 1436343 0 % 17
    volsnap 1 1436343 0 % 17
    partmgr 1 1436343 0 % 17
    ftdisk 1 1436343 0 % 17

    ===> processing zoomed module hal.dll...


    ----- zoomed module hal.dll (bucket size = 16 bytes, rounding down) --------
    percentage in the following table is based on the total hits for this zoom modul
    e

    time 11483 hits, 25000 events per hit --------
    module hits msec %total events/sec
    halmakebeep 3902 1436343 34 % 67915
    read_port_uchar 1911 1436343 17 % 33261
    haldisablesysteminterrupt 1153 1436343 10 % 20068
    read_port_ushort 882 1436343 7 % 15351
    kflowerirql 484 1436343 4 % 8424
    kegetcurrentirql 395 1436343 3 % 6875
    halbeginsysteminterrupt 374 1436343 3 % 6509
    exreleasefastmutex 295 1436343 2 % 5134
    kfreleasespinlock 252 1436343 2 % 4386
    exacquirefastmutex 193 1436343 1 % 3359
    kfraiseirql 189 1436343 1 % 3289
    keraiseirqltodpclevel 167 1436343 1 % 2906
    write_port_ushort 132 1436343 1 % 2297
    read_port_buffer_uchar 124 1436343 1 % 2158
    read_port_ulong 124 1436343 1 % 2158
    kfacquirespinlock 121 1436343 1 % 2106
    write_port_ulong 82 1436343 0 % 1427
    kereleaseinstackqueuedspinlock 60 1436343 0 % 1044
    halclearsoftwareinterrupt 59 1436343 0 % 1026
    read_port_buffer_ulong 58 1436343 0 % 1009
    write_port_uchar 50 1436343 0 % 870
    kereleasequeuedspinlock 46 1436343 0 % 800
    keraiseirqltosynchlevel 25 1436343 0 % 435
    kequeryperformancecounter 18 1436343 0 % 313
    halendsysteminterrupt 17 1436343 0 % 295
    halcalibrateperformancecounter 16 1436343 0 % 278
    keacquireinstackqueuedspinlock 16 1436343 0 % 278
    keacquireinstackqueuedspinlockraisetosynch 15 1436343 0 %
    261
    halrequestsoftwareinterrupt 14 1436343 0 % 243
    halrequestipi 13 1436343 0 % 226
    kestallexecutionprocessor 12 1436343 0 % 208
    write_port_buffer_ulong 6 1436343 0 % 104
    iofreemapregisters 4 1436343 0 % 69
    halallocateadapterchannel 3 1436343 0 % 52
    halreaddmacounter 1 1436343 0 % 17
    halfreecommonbuffer 1 1436343 0 % 17

    ================================= end of run ==================================
    ============================== normal end of run ==============================
     
Статус темы:
Закрыта.