Автор Тема: в /proc/loadavg се показват грешни стойности  (Прочетена 1883 пъти)

laskov

  • Напреднали
  • *****
  • Публикации: 3166
    • Профил
от там и информацията за натоварването в top е грешна. Този проблем го имам на всичките Olinuxino-A20, където нулево натоварване се показва като 1
Код:
top - 14:41:19 up  5:28,  2 users,  load average: 1.05, 1.04, 1.05
Tasks:  72 total,   2 running,  70 sleeping,   0 stopped,   0 zombie
%Cpu0  :  0.3 us,  0.3 sy,  0.0 ni, 99.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  :  0.0 us,  1.3 sy,  0.0 ni, 98.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:    830948 total,    50276 used,   780672 free,     2648 buffers
KiB Swap:        0 total,        0 used,        0 free,    28372 cached

 uname -a
Linux turn3 3.4.67+ #6 SMP PREEMPT Fri Nov 1 17:32:40 EET 2013 armv7l GNU/Linux

 cat /etc/debian_version
7.7


и на IBM x3650, където нулево натоварване се показва като почти 3
Код:
top - 17:06:35 up  4:56,  6 users,  load average: 4.93, 4.93, 4.97
Tasks: 168 total,   1 running, 167 sleeping,   0 stopped,   0 zombie
top - 17:06:48 up  4:56,  6 users,  load average: 4.95, 4.93, 4.97
Tasks: 168 total,   1 running, 167 sleeping,   0 stopped,   0 zombie
Cpu0  : 91.8%us,  0.0%sy,  0.0%ni,  8.2%id,  0.0%wa,  0.0%hi,  0.0%si, 0.0%st
Cpu1  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si, 0.0%st
Cpu2  :  0.3%us,  0.3%sy,  0.0%ni, 99.3%id,  0.0%wa,  0.0%hi,  0.0%si, 0.0%st
Cpu3  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si, 0.0%st
Mem:   8160512k total,  6253872k used,  1906640k free,    62032k buffers
Swap:  4194300k total,        0k used,  4194300k free,  4221228k cached

 uname -a
Linux vn1 3.10.17 #2 SMP Fri Feb 14 16:45:28 CST 2014 x86_64 Intel(R)
Xeon(TM) CPU 3.00GHz GenuineIntel GNU/Linux
 cat /etc/slackware-version
Slackware 14.1

Как да го оправя ?

//след доста време :) :
"Оправило" се е след компилиране и стартиране на ново ядро. Под "оправило" имам предвид, че при липса на натоварване показва стойности близки до нулата.
« Последна редакция: Oct 02, 2015, 17:12 от laskov »
Активен

Не си мислете, че понеже Вие мислите правилно, всички мислят като Вас! Затова, когато има избори, идете и гласувайте, за да не сте изненадани после от резултата, и за да не твърди всяка партия, че тя е спечелила, а Б.Б. (С.С., ...) е загубил, а трети да управлява.  Наздраве!  [_]3

BRADATA

  • Напреднали
  • *****
  • Публикации: 833
  • Distribution: Slackware/Mint/CentOS
  • Window Manager: console/KDE/LXDE
    • Профил
    • WWW
Ами не можеш да го оправиш :)
Прочети тук и ще разбереш защо ;)

http://blog.scoutapp.com/articles/2009/07/31/understanding-load-averages
Активен

laskov

  • Напреднали
  • *****
  • Публикации: 3166
    • Профил
Оффф, не обичам да не може! :)

Обаче ето една друга машина:
Код:
top - 18:27:02 up 33 days, 19:14,  1 user,  load average: 0.04, 0.05, 0.05
Tasks: 133 total,   1 running, 132 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.0%us,  0.0%sy,  0.0%ni, 99.7%id,  0.3%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  0.0%us,  0.0%sy,  0.0%ni, 89.0%id, 11.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   4035932k total,  3670840k used,   365092k free,   340324k buffers
Swap:  2097148k total,    17944k used,  2079204k free,  2340388k cached
« Последна редакция: Aug 10, 2015, 18:28 от laskov »
Активен

Не си мислете, че понеже Вие мислите правилно, всички мислят като Вас! Затова, когато има избори, идете и гласувайте, за да не сте изненадани после от резултата, и за да не твърди всяка партия, че тя е спечелила, а Б.Б. (С.С., ...) е загубил, а трети да управлява.  Наздраве!  [_]3

BRADATA

  • Напреднали
  • *****
  • Публикации: 833
  • Distribution: Slackware/Mint/CentOS
  • Window Manager: console/KDE/LXDE
    • Профил
    • WWW
Ами това е положението :) Зависи какво търкаляш на машината.... Ето два примера и от мен :)
Код:
top - 20:01:43 up  9:32,  1 user,  load average: 0.30, 0.26, 0.26
Tasks: 132 total,   3 running, 129 sleeping,   0 stopped,   0 zombie
Cpu0  : 22.7%us, 17.3%sy,  0.0%ni, 47.3%id,  0.3%wa,  0.0%hi, 12.4%si,  0.0%st
Cpu1  :  0.7%us,  2.5%sy,  0.0%ni, 96.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  : 13.2%us, 12.9%sy,  0.0%ni, 74.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   1880248k total,  1524792k used,   355456k free,    46464k buffers
Swap:  4030460k total,        0k used,  4030460k free,  1197636k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 1557 root      20   0 83572  11m  10m R 38.9  0.7 173:01.93 pmacctd
 1558 root      20   0 91304  19m 4660 S 16.6  1.1  83:15.92 pmacctd
 1559 root      20   0 88136  16m 4660 R 14.0  0.9  58:21.50 pmacctd
 3448 root      20   0 15028 1312  984 R  0.3  0.1   0:00.10 top

и :)
Код:
top - 19:08:42 up 346 days, 22:31,  1 user,  load average: 14.44, 16.62, 17.04
Tasks: 301 total,   3 running, 298 sleeping,   0 stopped,   0 zombie
Cpu0  : 17.8%us,  1.7%sy, 55.6%ni, 21.5%id,  0.3%wa,  0.0%hi,  3.0%si,  0.0%st
Cpu1  : 22.1%us,  1.0%sy, 49.5%ni, 27.1%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu2  : 25.1%us,  1.0%sy, 40.5%ni, 33.4%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  : 18.4%us,  1.0%sy, 49.8%ni, 30.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu4  : 16.3%us,  1.3%sy, 53.0%ni, 29.0%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu5  : 13.3%us,  1.0%sy, 59.3%ni, 26.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu6  : 20.1%us,  1.0%sy, 47.7%ni, 31.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu7  : 14.8%us,  0.7%sy, 51.3%ni, 33.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu8  : 75.4%us,  0.3%sy, 13.0%ni, 11.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu9  : 17.0%us,  0.3%sy, 56.0%ni, 26.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu10 : 21.5%us,  0.7%sy, 42.4%ni, 35.4%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu11 : 24.1%us,  1.0%sy, 44.5%ni, 30.4%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu12 : 19.5%us,  1.3%sy, 40.3%ni, 38.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu13 : 22.9%us,  1.7%sy, 32.2%ni, 42.9%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu14 : 17.6%us,  1.0%sy, 42.9%ni, 38.5%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu15 : 16.3%us,  1.3%sy, 42.7%ni, 39.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu16 : 16.6%us,  1.0%sy, 44.9%ni, 37.5%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu17 : 16.9%us,  1.0%sy, 38.9%ni, 43.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu18 : 14.0%us,  0.7%sy, 46.2%ni, 39.1%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu19 : 11.7%us,  1.0%sy, 51.2%ni, 36.1%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu20 :  8.6%us,  0.7%sy, 30.7%ni, 59.7%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu21 : 17.7%us,  1.3%sy, 36.0%ni, 44.7%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu22 : 16.7%us,  0.7%sy, 44.5%ni, 38.1%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu23 : 14.1%us,  1.0%sy, 40.6%ni, 44.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  65482576k total, 29520712k used, 35961864k free,    74528k buffers
Swap:  7815584k total,        0k used,  7815584k free,  2001440k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 6288 root      20   0 1474m 579m 4572 S  233  0.9   3570:46 ffmpeg
 5428 root      20   0 1474m 580m 4568 R  215  0.9   3343:13 ffmpeg
 7049 root      20   0 1481m 584m 4696 S  203  0.9   3567:34 ffmpeg
28691 root      20   0 1474m 577m 4564 S  177  0.9   1932:06 ffmpeg
 6371 root      20   0 1474m 576m 4572 S  165  0.9   3260:31 ffmpeg
 5393 root      20   0 1474m 579m 4620 S  159  0.9   2821:34 ffmpeg
24998 root      20   0 1474m 578m 4628 S  152  0.9   1334:46 ffmpeg
28516 root      20   0 1477m 580m 4580 S  148  0.9   2018:42 ffmpeg
22136 root      20   0 1131m 1.1g  764 R  100  1.8 862:54.22 logrotate
 5385 root      20   0  421m 394m 2356 S    5  0.6  83:18.28 ffserver
20494 root      20   0  3036 1224  840 R    1  0.0   0:00.07 top

Извода е ако числото в loadavg е по-малко от броя на тредовете (реални цпу + хипертрединг) работиш неоптимално. Т.е. имаш свободни ресурси. Ако е равно на - имаш 100% уплътнени мощности. Ако е по-голямо - закъсал си :) Има чакащи на опашката необслужени процеси...
Активен

pennywise

  • Гост
Мда ама той ги минава на едната машина. Може да провериш дали нямаш някой процес икса много да пише с iotop.
Активен

BRADATA

  • Напреднали
  • *****
  • Публикации: 833
  • Distribution: Slackware/Mint/CentOS
  • Window Manager: console/KDE/LXDE
    • Профил
    • WWW
Ами и аз това съм написал... Има нещо, дето държи ЦПУ-то. И аз мисля, че хипервайзора (ако е на тази машина)
Активен

gat3way

  • Напреднали
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Възможно е да са грешни (историята познава много случаи на бъгливи ядра със сбъркан accounting).

По-възможно е обаче да не са грешни. Разминаването идва, защото очакванията за това какво показва loadavg и stat са едни, реалността е друга.

loadavg няма нищо общо с утилизацията на процесорните ресурси. Поне не пряко. loadavg вади интегрирани показанията за броя на процесите в runqueue-а (т.е такива които са running/uninterruptable sleep). В кода на scheduler-а в ядрото условно казано има "места, където правим измервания", които пазят някъде броя на процесите в опашката чакаща процесорно време и timestamp. loadavg просто смята средни стойности за някакви периоди от време на база средния брой на тези процеси в някакъв интервал от време, благодарение на отчетените стойности и на timestamp-ите.

По абсолютно същият начин, в кода на ядрото има "места, където правим измервания" където се пази timestamp и "тип работа" - изпълнение на usermode код, kernelmode код, прекъсвания и т.н. Тези места са обикновено при "превключване" между процеси, при извикване на syscall-ове, при вдигане на прекъсвания и т.н.

Така, когато четеш /proc/stat, знаеш колко микросекунди ядрото е прекарало в изпълнение на тези няколко неща. top съответно чете този файл от procfs през равни интервали от време и му се сервира информация за процесорното натоварване в последния интервал.

Дотук добре и в идеалния случай, loadavg и stat щяха да вадят стойности, които взаимно да се "подкрепят". Обаче в реалният свят винаги е по-шарено. Например точно тези "места където правим замервания" се изпълняват в периоди от време, които /proc/stat не отчита - това е т.наречения scheduling overhead и за него статистика не се вади - на теория вероятно не е проблемно да се смята по-прецизно, на практика това ще доведе до разхищение на процесорни ресурси и електроенергия за глупости - поради което не се прави. Така че сметките, които ти ги вади ядрото и съответно top не отговарят на истината.

Допълнително, в x86 света има нещо, наречено SMI режим, което е абсолютно извън контрола на операционната система - те се обслужват от handler-и инсталирани от BIOS-а на машината и отнемат допълнително време за което операционната система няма никаква идея - на практика за нея това са като периоди на "амнезия" където й се губи време без тя да има никаква идея за това.


Та това е относително лесно да се илюстрира. Може да врътнем на bash един безкраен цикъл, който нон-стоп изпълнява някаква бърза команда - примерно while true; do id 2>/dev/null; done

Моята машина е 6-ядрена, значи изпълняваме паралелно 6 такива цикъла и отиваме да видим какво ще ни извади top:


Код:
top - 23:26:26 up 40 min, 12 users,  load average: 6.86, 5.78, 3.99
Tasks: 287 total,   4 running, 283 sleeping,   0 stopped,   0 zombie
%Cpu0  : 42.6 us, 47.7 sy,  0.0 ni,  9.1 id,  0.0 wa,  0.0 hi,  0.7 si,  0.0 st
%Cpu1  : 39.3 us, 51.2 sy,  0.0 ni,  8.8 id,  0.0 wa,  0.0 hi,  0.7 si,  0.0 st
%Cpu2  : 37.8 us, 52.4 sy,  0.0 ni,  8.8 id,  0.3 wa,  0.0 hi,  0.7 si,  0.0 st
%Cpu3  : 40.3 us, 48.5 sy,  0.0 ni, 10.8 id,  0.0 wa,  0.0 hi,  0.3 si,  0.0 st
%Cpu4  : 39.2 us, 49.8 sy,  0.0 ni,  9.6 id,  0.3 wa,  0.0 hi,  1.0 si,  0.0 st
%Cpu5  : 39.6 us, 49.1 sy,  0.0 ni, 10.6 id,  0.0 wa,  0.0 hi,  0.7 si,  0.0 st
KiB Mem:   8111324 total,  4512784 used,  3598540 free,   620716 buffers
KiB Swap:  3903484 total,        0 used,  3903484 free.   937520 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                       
 2809 gat3way   20   0   25364   5796   1784 S  27.6  0.1   2:33.36 bash                                                                         
 2813 gat3way   20   0   25364   5804   1792 R  27.6  0.1   2:33.00 bash                                                                         
 2805 gat3way   20   0   25364   5808   1792 S  27.3  0.1   2:33.60 bash                                                                         
 2820 gat3way   20   0   25364   5796   1784 S  26.9  0.1   2:32.32 bash                                                                         
 2826 gat3way   20   0   25368   5812   1792 S  26.9  0.1   3:04.86 bash                                                                         
 5395 gat3way   20   0   25348   5784   1792 R  26.3  0.1   1:14.00 bash                                                                         
 1378 root      20   0  511976 235920 178044 S  11.3  2.9   5:51.41 Xorg                                                                         
 2728 gat3way    9 -11  674148   8924   5596 S   7.0  0.1   3:42.38 pulseaudio                                                                   
 2834 gat3way   20   0  577564  34532  23444 S   4.7  0.4   2:30.51 pavucontrol                                                                   
 2855 gat3way   20   0  928028  55600   8936 S   4.3  0.7   2:21.91 fldigi                                                                       
 2624 gat3way   20   0 3040100  92456  69448 S   3.7  1.1   1:12.99 kwin                                                                         
 2790 gat3way   20   0  473168  38332  22396 S   2.3  0.5   0:22.75 konsole                                                                       

Както се вижда, според /proc/stat, всеки процесор има около 10% idle time, докато loadavg ни е над 6, демек евентуално би следвало да имаме процеси, биещи се и чакащи за процесорно време и процесорите да са нон-стоп утилизирани.

Това не е добър пример (цикленето на изпълнение на външни изпълними файлове). Вероятно далеч по-идеален пример би бил да се драсне една програмка, която цикли sched_yield() и тогава разминаванията ще са доста по-радикални.

Та като цяло идеята е - не се доверявайте на тези неща, те не са много истински. Те са едно добро приближение, да, но не бива човек да ги взема прекалено буквално.
Активен

"Knowledge is power" - France is Bacon

laskov

  • Напреднали
  • *****
  • Публикации: 3166
    • Профил
Мда ама той ги минава на едната машина. Може да провериш дали нямаш някой процес икса много да пише с iotop.
Ами и аз това съм написал... Има нещо, дето държи ЦПУ-то. И аз мисля, че хипервайзора (ако е на тази машина)
:) Това беше преди да добавя "-machine accel=kvm -cpu host" към опциите за стартиране на qemu. След това нещата "литнаха"  :)

Благодаря за разясненията относно loadavg!
Активен

Не си мислете, че понеже Вие мислите правилно, всички мислят като Вас! Затова, когато има избори, идете и гласувайте, за да не сте изненадани после от резултата, и за да не твърди всяка партия, че тя е спечелила, а Б.Б. (С.С., ...) е загубил, а трети да управлява.  Наздраве!  [_]3

Подобни теми
Заглавие Започната от Отговора Прегледи Последна публикация
proc system
Общ форум
kennedy 0 1110 Последна публикация Aug 18, 2004, 23:12
от kennedy
lilo: /proc/misc: No entry for device-mapper found
Настройка на програми
botzko 3 1968 Последна публикация Nov 09, 2008, 18:18
от botzko
/proc source code
Общ форум
rcbandit 8 3964 Последна публикация Sep 13, 2011, 14:14
от romeo_ninov
Какво показва "timestamp" в/proc/schedstat? Не намериам инфо. в документацията..
Настройка на програми
noobforthewin 8 2168 Последна публикация Jul 25, 2013, 14:57
от gat3way
/proc question
Настройка на програми
beliconfused 6 2008 Последна публикация Aug 25, 2017, 15:51
от 4096bits