Volle core altijd belast

[frim]

Ik heb een dual core intel iMac, en sinds kort wordt er 1 core steeds volop gebruikt:

code:

Processes:  88 total, 2 running, 86 sleeping... 321 threads            10:05:00
Load Avg:  1.17, 1.32, 1.26     CPU usage:  43.3% user, 17.6% sys, 39.1% idle
SharedLibs: num =  209, resident = 50.4M code, 6.00M data, 17.6M LinkEdit
MemRegions: num = 17143, resident =  545M + 23.3M private,  313M shared
PhysMem:   163M wired,  747M active,  538M inactive, 1.41G used, 84.1M free
VM: 11.1G +  135M   131387(5) pageins, 45451(0) pageouts

  PID COMMAND      %CPU   TIME   #TH #PRTS #MREGS RPRVT  RSHRD  RSIZE  VSIZE
27487 top         14.2%  0:00.45   1    19    20  1.83M+  832K  2.29M+ 26.9M 
   75 WindowServ   4.6% 13:35.87   4   537  1515  8.62M+  175M-  177M-  573M
    1 launchd      2.9% 25:48.88   3   447    21   236K   796K   500K  27.7M
  254 Terminal     2.5%  2:50.98   8   106   200  2.49M+ 22.7M+ 25.8M+  239M
    0 kernel_tas   1.6% 15:28.28  45     2  3986  32.2M     0K  97.6M   972M 
  141 mds          1.2% 10:12.22   8    97    83  4.55M  3.17M  5.44M  45.9M
 4397 Safari       1.0%  8:23.20  12   227  1721   160M  62.9M   211M+  450M
   40 syslogd      0.7%  6:56.26   1    15    19   112K   792K   356K  26.6M
   49 notifyd      0.4%  5:11.23   2   108    21   140K   776K   380K  27.2M

het cpu-verbruik valt niet terug te leiden tot een proces, dus ik kan niets killen om het terug te krijgen.

Het probleem blijft zelfs na een reboot. Als ik uitlog en weer inlog, is het voor de eerste 10-20 seconden goed, daarna krijg ik weer deze rare belasting. Een ander user account aanmaken en daarmee inloggen helpt niet; ik krijg dan nog steeds een hoge cpu-belasting.

Iemand die een idee heeft hoe ik mijn ene core terug kan krijgen?

[Osxy]

Waar uit maak je op dat 1 cpu vol word belast? Bij top werkt het zo bij dual cpu's dat 100% betekend dat de 2 cpu's beide half worden belast, 200% s volle belasting.

[CyBeR]

Log uit-en-in en maak elke seconde een lijstje van processen, en kijk wat er veranderd is nadat je cpu usage weer omhoog schiet?

[storeman]

39,1 procent idle, dat wordt dus niet gebruikt, dat is gewoon te termologie voor

'ik ben voor 39,1 procent uit mijn neus aan het vreten totdat jij weet wat ik kan gaan doen'

[triet]

osxy schreef op vrijdag 08 september 2006 @ 10:16:
Waar uit maak je op dat 1 cpu vol word belast? Bij top werkt het zo bij dual cpu's dat 100% betekend dat de 2 cpu's beide half worden belast, 200% s volle belasting.

Wat jij bedoelt is de load avg. Die is 1.00 bij "100%" belasting en 2.00 bij "200%" belasting. Volgens mij is de CPU usage in procenten wel degelijk een percentage met 100% als max.

[Zwerver]

offtopic:
Waarom praten mensen hier alsof ze er iets vanaf weten maar nog moeten zoeken naar de klepel van de bel? Ik zie echt maar 1 reactie die nuttig is...

[CyBeR]

triet schreef op vrijdag 08 september 2006 @ 10:32:
[...]


Wat jij bedoelt is de load avg. Die is 1.00 bij "100%" belasting en 2.00 bij "200%" belasting. Volgens mij is de CPU usage in procenten wel degelijk een percentage met 100% als max.

Eh, nee. De load average is het gemiddelde aantal processen, over de laatste 1, 5 en 15 minuten (voor elk van de 3 getallen) dat in de run-queue staat te wachten op wat CPU-tijd. Die kun je op een single-processor door vrij simpel over de 500 krijgen door een fork-bommetje te draaien.

[FlorisB]

Als ik jou was zou ik even top onder root draaien, gewoon sudo top.
Volgensmij krijg je nu namelijk niet alles te zien.

[Sa1]

triet schreef op vrijdag 08 september 2006 @ 10:32:
[...]


Wat jij bedoelt is de load avg. Die is 1.00 bij "100%" belasting en 2.00 bij "200%" belasting. Volgens mij is de CPU usage in procenten wel degelijk een percentage met 100% als max.

offtopic:
waar haal jij deze wijsheid vandaan

[Liegebeest]

Wel, als je het heel vies beredeneert kom je er zo op: als 1 proces de hele tijd de CPU vast houd is ie 100% belast. Zijn er twee die de hele tijd willen, dan op 200%.

Natuurlijk is die beredenering aan alle kanten krom

Waar uit maak je op dat 1 cpu vol word belast? Bij top werkt het zo bij dual cpu's dat 100% betekend dat de 2 cpu's beide half worden belast, 200% s volle belasting.

En ook dit is onzin. Wanneer top geen uitsplitsing maakt tussen de verschillende processors, dan telt de cummulatieve capaciteit van alle procs als 100%.

Onder bijvoorbeeld Linux word er bovenin wel een splitsing gemaakt voor elke core/CPU die beschikbaar is, zoals hier onder:

code:

CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle
           total    0.2%    0.0%    0.7%   0.0%     0.0%    0.0%   98.9%
           cpu00    0.5%    0.0%    1.1%   0.0%     0.0%    0.0%   98.2%
           cpu01    0.1%    0.0%    0.5%   0.0%     0.0%    0.0%   99.2%
           cpu02    0.0%    0.0%    0.5%   0.0%     0.0%    0.0%   99.4%
           cpu03    0.3%    0.0%    0.5%   0.0%     0.0%    0.1%   98.8%
Mem:  1025404k av, 1008296k used,   17108k free,       0k shrd,  213740k buff
                    662900k actv,  147268k in_d,   20708k in_c
Swap: 2097112k av,   53292k used, 2043820k free                  557064k cached

Maar dan nog geld dat in de lijst daar onder het gegeven percentage geld op de cummulatieve capaciteit van alle cores bij elkaar.

EDIT:
Overigens kan men er, aan de hand van de top die in den beginne werd gepost, wel van uit gaan dat één van de cores van TS de hele tijd bezig is... Want die 43% plus 17% is alsnog meer dan de helft van het totaal.

[ Voor 80% gewijzigd door Liegebeest op 08-09-2006 11:25 ]

[Abbadon]

Tik eens ps -Au in, dan zie je alle processen incl. %CPU. Ik zie dan meer als wat top mij oplevert.

[edit]
Of top -o cpu (kan zijn dat jouw terminal te klein is en je het proces wat zoveel cpu pakt niet ziet. Met -o cpu zorg je ervoor dat top de lijst op cpu verbruik sorteert).

[ Voor 45% gewijzigd door Abbadon op 08-09-2006 11:41 ]

[frim]

Hier weer even een update
Mijn top output was uiteraard met top -o cpu, anders heeft het weinig relevantie met het probleem. ps -Au laat niet meer zien dan top.

Ik heb in /var/log gekeken, en in /var/log/samba staat een logfile van 16GB:

code:

Vienna:/var/log/samba frim$ tail -30 log.nmbd
  Netbios nameserver version 3.0.10 started.
  Copyright Andrew Tridgell and the Samba Team 1994-2004
[2006/09/13 18:47:40, 0] /SourceCache/samba/samba-92.15/samba/source/nmbd/nmbd.c:main(687)
  standard input is not a socket, assuming -D option
[2006/09/13 18:47:40, 0] /SourceCache/samba/samba-92.15/samba/source/lib/util_sock.c:open_socket_in(724)
  bind failed on port 137 socket_addr = 0.0.0.0.
  Error = Address already in use
[2006/09/13 18:47:40, 0] /SourceCache/samba/samba-92.15/samba/source/nmbd/nmbd.c:main(668)
  Netbios nameserver version 3.0.10 started.
  Copyright Andrew Tridgell and the Samba Team 1994-2004
[2006/09/13 18:47:40, 0] /SourceCache/samba/samba-92.15/samba/source/nmbd/nmbd.c:main(687)
  standard input is not a socket, assuming -D option
[2006/09/13 18:47:40, 0] /SourceCache/samba/samba-92.15/samba/source/lib/util_sock.c:open_socket_in(724)
  bind failed on port 137 socket_addr = 0.0.0.0.
  Error = Address already in use
[2006/09/13 18:47:40, 0] /SourceCache/samba/samba-92.15/samba/source/nmbd/nmbd.c:main(668)
  Netbios nameserver version 3.0.10 started.
  Copyright Andrew Tridgell and the Samba Team 1994-2004
[2006/09/13 18:47:40, 0] /SourceCache/samba/samba-92.15/samba/source/nmbd/nmbd.c:main(687)
  standard input is not a socket, assuming -D option
[2006/09/13 18:47:40, 0] /SourceCache/samba/samba-92.15/samba/source/nmbd/nmbd.c:main(668)
  Netbios nameserver version 3.0.10 started.
  Copyright Andrew Tridgell and the Samba Team 1994-2004
[2006/09/13 18:47:40, 0] /SourceCache/samba/samba-92.15/samba/source/lib/util_sock.c:open_socket_in(724)
  bind failed on port 137 socket_addr = 0.0.0.0.
  Error = Address already in use
[2006/09/13 18:47:41, 0] /SourceCache/samba/samba-92.15/samba/source/nmbd/nmbd.c:main(687)
  standard input is not a socket, assuming -D option

Dit gaf mij het vermoeden dat het misschien aan samba ligt Ik dacht dat ik deze service uit had gezet, maar hij bleek aan te staan. Na hem uit te zetten had ik geen problemen meer voor een tijdje.

Net echter kreeg ik weer dezelfde effecten; een kijken in System Preferences leerde mij dat Windows File Sharing weer aan stond? Ik heb hem weer uitgezet en nu is mijn mac weer voor 95% idle, maar ik snap niet helemaal hoe hij zichzelf aan kan hebben gezet (en wat de problemen zijn die de logfiles opleveren, en waarom ik een hoog cpu-verbruik erdoor krijg).

[Liegebeest]

Q) Waarom zo veel CPU gebruik?
A) Als Samba heel snel gaat staan klapperen (aan-uit-aan-uit-aan-uit-aan-uit-aan-uit-aan-uit-aan-uit-enz), dan vreet dat natuurlijk processor tijd. De werkelijk reusachtige logfile lijkt hier op te wijzen. Zeker ook gezien het feit dat je ziet dat hij zeker meer dan tien keer per seconde op start.

Q) Hoe kan hij zichzelf aan zetten?
A) Meerdere mogelijkheden, die helaas geen van allen onder normale omstandigheden voor komen.

Ik heb even proberen uit te vogelen hoe het onder OS X in hemelsnaam gaat met het (her)starten van UNIX services. Da's toch wat anders dan ik van Solaris en Linux gewend ben

Zo heb ik hier thuis even SMB aangezet, en de poort (139 en 137) luistert ook gewoon. Ik kan er zelfs naar connecten. Maar gek genoeg geeft "lsof" niet aan welk proces er gebruik van maakt.

code:

kilala $ sudo lsof -i4
COMMAND    PID   USER   FD   TYPE     DEVICE SIZE/OFF NODE NAME
syslogd     82   root    5u  IPv4 0x02837e50      0t0  UDP *:syslog
configd     90   root   12u  IPv4 0x02837be0      0t0  UDP *:bootpc
netinfod   120   root    6u  IPv4 0x02837d80      0t0  UDP localhost:netinfo-local
netinfod   120   root    7u  IPv4 0x02a15d8c      0t0  TCP localhost:netinfo-local (LISTEN)
netinfod   120   root    8u  IPv4 0x02b95008      0t0  TCP localhost:netinfo-local->localhost:982 (ESTABLISHED)
mDNSRespo  150 nobody    4u  IPv4 0x02837cb0      0t0  UDP *:mdns
loginwind  190 thomas    7u  IPv4 0x02d75538      0t0  TCP localhost:49239->localhost:ipp (CLOSE_WAIT)
loginwind  190 thomas    8u  IPv4 0x02d74fd0      0t0  TCP localhost:49240->localhost:ipp (CLOSE_WAIT)
Directory  194   root    6u  IPv4 0x02b952bc      0t0  TCP localhost:982->localhost:netinfo-local (ESTABLISHED)
cupsd      254   root    0u  IPv4 0x02ceace4      0t0  TCP localhost:ipp (LISTEN)
cupsd      254   root    2u  IPv4 0x02837b10      0t0  UDP *:ipp
xfs        256   root    3u  IPv4 0x02b91490      0t0  TCP *:font-service (LISTEN)
httpd      259   root   16u  IPv4 0x02cb2824      0t0  TCP *:http (LISTEN)
httpd      260    www   16u  IPv4 0x02cb2824      0t0  TCP *:http (LISTEN)
ntpd       301   root    5u  IPv4 0x02837a40      0t0  UDP *:ntp
ntpd       301   root    6u  IPv4 0x02837970      0t0  UDP localhost:ntp
ntpd       301   root    7u  IPv4 0x028378a0      0t0  UDP 169.254.252.135:ntp
automount  329   root    7u  IPv4 0x028377d0      0t0  UDP localhost:1023
automount  332   root    7u  IPv4 0x02837630      0t0  UDP localhost:1022
iTunes     830 thomas   18u  IPv4 0x02b919f8      0t0  TCP *:daap (LISTEN)
iTunes     830 thomas   28u  IPv4 0x0426f284      0t0  TCP 10.0.1.3:daap->10.0.1.1:blackjack (ESTABLISHED)
xinetd    1202   root    5u  IPv4 0x02837220      0t0  UDP *:netbios-ns
xinetd    1202   root    6u  IPv4 0x043cfce4      0t0  TCP *:netbios-ssn (LISTEN)
telnet    1233 thomas    3u  IPv4 0x02cea77c      0t0  TCP localhost:60632->localhost:netbios-ssn (ESTABLISHED)
smbd      1234   root   19u  IPv4 0x042859f8      0t0  TCP localhost:netbios-ssn->localhost:60632 (ESTABLISHED)
smbd      1234   root   21u  IPv4 0x02837150      0t0  UDP localhost:52653

Ik ga even verder graven

[Liegebeest]

Okay, zo anders is het toch niet

Het ziet er naar uit dat SMB en vergelijkbare dingen toch gewoon inder "xinetd" draaien. Als je in /etc/xinetd.d kijkt zie je als het goed is een file met de naam smbd. Die ziet er als volgt uit:

code:

service netbios-ssn
{
        disable = yes
        socket_type     = stream
        protocol        = tcp
        mdns            = no
        wait            = no
        user            = root
        server          = /usr/sbin/smbd
        groups          = yes
        flags           = REUSE
        log_on_success  =
        log_on_failure  =
}

Die "disable" parameter word als het goed is door OS X automagisch op "no" gezet als jij het vinkje plaats in System Preferences -> Sharing.

Q) Kan je voor mij de inhoud van jou smbd file copy/pasten?

Q) Kan je voor mij bevestigen dat de flag "disable" bij jou mee veranderd als je SMB sharing aan en uit zet? Dus dat ie van "yes", naar "no", naar "yes" gaat?

Q) Kan je voor mij nakijken of een van de andere files uit /etc/xinetd.d een verwijzing naar "/usr/sbin/smbd" of een andere "smbd" heeft?

Want ik denk dat het tweevoudig is:
1. Jou SMB daemon word om de een of andere reden geforceerd aan gehouden. OF via het originele smbd config file, of via een extra file die door OS X System Preferences word genegeerd.
2. Die vele herstarts komen doordat iemand jou SMB shares probeert aan te spreken. Onder het motto van script kiddies zou ik zeggen, wegens de grote hoeveelheid mislukte pogingen. Het lukt ze alleen geen verbinding te maken, omdat de config file voor SMBd niet goed is ingesteld. Hij gebruikt een verkeerde flag die OS X niet lijkt te kennen.

EDIT:
Een beetje extra uitleg... De "inetd" (Inet Daemon) en z'n afstammeling "xinetd" zijn software die bedoeld zijn om automatisch programma's op te starten, naar gelang welke netwerk poort word aangesproken. Zo kan je inetd bijvoorbeeld zo instellen dat ze automatisch een FTP server process start als er iemand naar poort 21 connect, of in dit geval een SMB server process als iemand poort 139 probeert aan te spreken.

Op zich een heel mooi mechanisme, want als er geen verkeer is, zijn er ook geen processen. Zo bespaar je wat CPU tijd en RAM. Maar het kan dus ook worden misbruikt, in de vorm van Denial of Service aanvallen. Iets waar hetgeen jij ondergaat op lijkt. Iets of iemand probeert -heel- vaak jou SMB shares aan te spreken, waardoor je systeem over de zeik gaat.

Q) Hangt je systeem direct aan het Internet?

Q) Heb je onlangs nieuwe software geinstalleerd (of programmaatjes gedraaid) die uit minder betrouwbare bron afkomstig zijn?

[ Voor 22% gewijzigd door Liegebeest op 13-09-2006 20:53 ]

[burne]

cailin_coilleach schreef op vrijdag 08 september 2006 @ 11:17:
Overigens kan men er, aan de hand van de top die in den beginne werd gepost, wel van uit gaan dat één van de cores van TS de hele tijd bezig is... Want die 43% plus 17% is alsnog meer dan de helft van het totaal.

Nee, dat kan je niet. Het enige wat je kunt zeggen is dat er 1 taak is die voortdurend *wil* draaien, en dus onafgebroken in de run-queue staat. Dat zou zelfs een dode nfs-mount kunnen zijn, die geen meetbare hoeveelheden CPU snoept, maar wel je load met 1 opkrikt door de manier waarop NFS omgaat met sockets.

[Q]

code:

bind failed on port 137 socket_addr = 0.0.0.0.
  Error = Address already in use

Als samba is uitgeschakeld en je dus geen hoge belasting hebt. Zou je dan nog eens een

netstat -an | grep LISTEN

kunnen doen? Case sensitive. Cp eens wat je ziet.

[Liegebeest]

Burne:
Grappig dat je over de load avg begint, want ik heb het toch werkelijk over de CPU percentages... En dus niet de load Overigens waren we die discussie nu al redelijkerwijs voorbij. We zijn nu op zoek naar de oorzaak van het probleem, wat lijkt te liggen bij een flippende SMB service.

Q:
137 is een UDP poort, die verschijnt niet met LISTEN in de lijst.

code:

Sango $ netstat -an | grep 137
udp4       0      0  *.137                  *.*                    
Sango $ netstat -an | grep 139
tcp4       0      0  *.139                  *.*                    LISTEN

Het is dan beter om te doen: netstat -an | grep udp4 | grep 137. Poortje 139 zal wel horen te verschijnen als je grepped op LISTEN.

[ Voor 25% gewijzigd door Liegebeest op 13-09-2006 23:05 ]

[ppl]

cailin_coilleach schreef op vrijdag 08 september 2006 @ 11:17:
EDIT:
Overigens kan men er, aan de hand van de top die in den beginne werd gepost, wel van uit gaan dat één van de cores van TS de hele tijd bezig is... Want die 43% plus 17% is alsnog meer dan de helft van het totaal.

Er staat dat 43% cpu usage komt door processen die door de user zijn gestart, 17% is door het systeem gestart. Er staat dus helemaal nergens wat waar draait en je kunt dat er ook niet uit afleiden.
Daarnaast is dit ook een contradictie van hetgeen je er net daarboven neerzet:

En ook dit is onzin. Wanneer top geen uitsplitsing maakt tussen de verschillende processors, dan telt de cummulatieve capaciteit van alle procs als 100%.

Je kunt met top wel switchen tussen layout waarin het 1 cpu weergeeft of waarin het 2 cpu's weer geeft. Het is dan ook niet ondenkbaar dat in MacOS X het eerste de default waarde is waarmee top wordt gestart. Als ik op mijn ubuntu doos de manual bekijk van top dan staat daar dat de single cpu optie op on is gezet by default. Je ziet dus maar 1 cpu regel ongeacht het aantal cpu's die je hebt. De switch hiervoor schijnt 'l" (kleine letter L) te zijn. Verderop in de manual vind ik onder het kopje "2. FIELDS / Columns - 2a. DESCRIPTIONS of Fields" het volgende:

k: %CPU -- CPU usage
The task’s share of the elapsed CPU time since the last screen
update, expressed as a percentage of total CPU time. In a true SMP
environment, if ’Irix mode’ is Off, top will operate in number of
CPUs. You toggle ’Irix/Solaris’ modes with the ’I’ interactive com‐
mand.

Ik ben dan ook benieuwd waaruit men concludeert dat 1 core veel staat te doen en de ander niet aangezien de geposte top output hier niets van laat zien en dus kennelijk by default met Irix/Solaris mode op On draait. Mogelijk dat het bij MacOS X anders gaat (er zit bijv. verschil tussen de top op FreeBSD en top op Debian/Ubuntu), maar ik verwacht eigenlijk van niet.

[Verwijderd]

CyBeR schreef op vrijdag 08 september 2006 @ 10:19:
Log uit-en-in en maak elke seconde een lijstje van processen, en kijk wat er veranderd is nadat je cpu usage weer omhoog schiet?

Misschien is het handiger om gewoon

top -d 1

te doen?