Титла: в /proc/loadavg се показват грешни стойности
Публикувано от: laskov в Aug 10, 2015, 15:17
от там и информацията за натоварването в 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
Как да го оправя ? //след доста време :) : "Оправило" се е след компилиране и стартиране на ново ядро. Под "оправило" имам предвид, че при липса на натоварване показва стойности близки до нулата.
Титла: Re: в /proc/loadavg се показват грешни стойности
Публикувано от: BRADATA в Aug 10, 2015, 15:38
Ами не можеш да го оправиш :)
Прочети тук и ще разбереш защо ;)
http://blog.scoutapp.com/articles/2009/07/31/understanding-load-averages
Титла: Re: в /proc/loadavg се показват грешни стойности
Публикувано от: laskov в Aug 10, 2015, 18:17
Оффф, не обичам да не може! :) Обаче ето една друга машина: 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
Титла: Re: в /proc/loadavg се показват грешни стойности
Публикувано от: BRADATA в Aug 10, 2015, 19:25
Ами това е положението :) Зависи какво търкаляш на машината.... Ето два примера и от мен :) 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% уплътнени мощности. Ако е по-голямо - закъсал си :) Има чакащи на опашката необслужени процеси...
Титла: Re: в /proc/loadavg се показват грешни стойности
Публикувано от: pennywise в Aug 10, 2015, 19:51
Мда ама той ги минава на едната машина. Може да провериш дали нямаш някой процес икса много да пише с iotop.
Титла: Re: в /proc/loadavg се показват грешни стойности
Публикувано от: BRADATA в Aug 10, 2015, 20:23
Ами и аз това съм написал... Има нещо, дето държи ЦПУ-то. И аз мисля, че хипервайзора (ако е на тази машина)
Титла: Re: в /proc/loadavg се показват грешни стойности
Публикувано от: gat3way в Aug 10, 2015, 23:54
Възможно е да са грешни (историята познава много случаи на бъгливи ядра със сбъркан 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() и тогава разминаванията ще са доста по-радикални. Та като цяло идеята е - не се доверявайте на тези неща, те не са много истински. Те са едно добро приближение, да, но не бива човек да ги взема прекалено буквално.
Титла: Re: в /proc/loadavg се показват грешни стойности
Публикувано от: laskov в Aug 11, 2015, 16:44
Мда ама той ги минава на едната машина. Може да провериш дали нямаш някой процес икса много да пише с iotop.
Ами и аз това съм написал... Има нещо, дето държи ЦПУ-то. И аз мисля, че хипервайзора (ако е на тази машина)
:) Това беше преди да добавя "-machine accel=kvm -cpu host" към опциите за стартиране на qemu. След това нещата "литнаха" :) Благодаря за разясненията относно loadavg!
|