[linux] proces met een extreme "TIME" (deel 2)

Pagina: 1
Acties:

  • Sir Isaac
  • Registratie: September 2002
  • Laatst online: 21-05-2025
OK nu met wat meer info:
In "top" zie ik dat een process 332836 minute cpu tijd heeft gebruikt. Dit zijn 231 dagen. Maar mijn uptime is "slechts" 53 dagen. Er klopt dus iets niet. Iemand een idee wat dat zou kunnen zijn?

code:
1
2
3
4
5
6
7
ps aux | cut "alle niet relevante processen"
USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
frits    27173 99.9  7.4 39248 38248 ?       RN   Feb28 333061:22 ./simclient

top:
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
27173 frits     35  10 39248  37m  516 R 90.0  7.4 333067:47 simclient


Het process is een simulatie programma dat zijn werk bij een server ophaalt en netjes mijn cpu aan het werkt houdt.

Verwijderd

Het TIME veld is een niet een absolute waarde. Dit is het totaal aan cpu slices wat dit proces gekregen heeft. Wellicht dat je een kernel draait waar er een bug in het algoritme wat dit berekend zit, dus welke kernel gebruik je? (net zoals het intri is om iets meer info over je distro en eventueel over dat simulatie programma)

[ Voor 3% gewijzigd door Verwijderd op 13-04-2005 13:20 ]


  • Sir Isaac
  • Registratie: September 2002
  • Laatst online: 21-05-2025
Ik heb een 2.6.10 kernel, zelf gecompileerd uit de debian sources. De machine waar het om gaat, heeft een 1Ghz Athlon Thunderbird processor.
De eerste drie weken gaf TIME wel een reele waarde aan. Inmiddels zou dit proces 333946 minuten draaien, dat is 232 dagen, een dag meer dan gisteren, dus de toename van de TIME klopt wel. (dit proces gebruikt permanent 90% van mijn CPU). Dat zou dus op een of andere overflow kunnen duiden.
Vaak heb ik Folding@Home draaien, en bij dat programma heb ik dit nooit gezien. Maar die start te core die de daadwerkelijke berekeningen uitvoert na iedere job opnieuw. Over de simulatie kan ik niet zo veel zeggen. Het gaat om een (niet door mijzelf) in C geschreven programma dat een Monte Carlo simulatie uitvoert.

  • deadinspace
  • Registratie: Juni 2001
  • Laatst online: 17:20

deadinspace

The what goes where now?

Welke Debian tree draai je? Stable (Woody/3.0), Testing (Sarge) of Unstable(Sid)?

Als je Woody draait: Die is niet 2.6-ready. Aangezien in 2.6 de timer frequentie is verhoogd van 100 naar 1000 Hz verbaast zo'n effect me niet zo veel :) Er zijn updates packages te vinden om 2.6 op Woody te draaien zonder dergelijke problemen (googlen op 'debian bunk').

Als je Sarge of Sid draait, dan is er iets mis. Waarschijnlijk een bug in procps, misschien in de kernel.

  • Sir Isaac
  • Registratie: September 2002
  • Laatst online: 21-05-2025
Dan is er dus iets mis: ik draai Sarge op deze machine. Wat kan ik doen om het probleem meer te lokaliseren? Ik heb de bugs in bugs.debian.org doorgenomen maar ben hem niet tegengekomen.

  • deadinspace
  • Registratie: Juni 2001
  • Laatst online: 17:20

deadinspace

The what goes where now?

Hmm, geef eens de output van
code:
1
cat /proc/27173/stat

  • Sir Isaac
  • Registratie: September 2002
  • Laatst online: 21-05-2025
code:
1
27173 (simclient) R 1 27173 27168 0 -1 0 10228302 0 10386 0 1979785315 33451958 0 0 35 10 1 0 88275268 40189952 9562 4294967295 134512640 134522535 3221224864 3221224208 3047065670 0 0 1 0 0 0 0 17 0 0 0

[ Voor 4% gewijzigd door Sir Isaac op 14-04-2005 21:15 ]


  • deadinspace
  • Registratie: Juni 2001
  • Laatst online: 17:20

deadinspace

The what goes where now?

Hmm. In die output is 1979785315 de user time van het process, en 33451958 de system time, beiden gemeten in de naar buiten geexporteerde lengte van timer ticks, wat op normale GNU/Linux systemen nog altijd 1/100 seconde is (ook op 2.6 systemen blijkbaar).

Als ik het dan zelf uitreken, kom ik op (1979785315 + 33451958) / 100 / 60 / 60 / 24 = 233 dagen inderdaad.

Stel, het zou in 1/1000 seconden zijn, dan wordt het dus 23 dagen werkelijke CPU time. Dat lijkt me wat weinig voor 53 dagen @ 90% CPU. Bovendien zou de CPU time dan met ongeveer 10 CPU-dagen moeten toenemen per echte dag.

Het lijkt erop dat de procps tools de tijd gewoon correct uitlezen en omrekenen. Het lijkt er ook op dat de tijd in /proc goed toeneemt, alleen... Het getal wat er staat is te groot. Het enige wat verder in me op komt is dat er geheugencorruptie is opgetreden, waardoor die waarde in het process structure van simclient in de kernel fout is.

  • Sir Isaac
  • Registratie: September 2002
  • Laatst online: 21-05-2025
Dus simclient herstarten en over drie weken verder kijken?

  • deadinspace
  • Registratie: Juni 2001
  • Laatst online: 17:20

deadinspace

The what goes where now?

Herstarten zal niet nodig zijn lijkt me... Als de utime van dat process het enige is wat fout is, dan is er niks aan de hand verder, het is alleen raar.

  • Sir Isaac
  • Registratie: September 2002
  • Laatst online: 21-05-2025
Ik wil alleen herstarten om te kijken of het reproduceert. Als dat zo is moeten we toch wat verder kijken.

  • deadinspace
  • Registratie: Juni 2001
  • Laatst online: 17:20

deadinspace

The what goes where now?

Ah, op die manier. Lijkt me prima. Je zou zelfs een `` ps auxf | grep simclient >> /een/of/andere/logfile '' oid kunnen cronnen, dan zie je wanneer het gebeurt (als het weer gebeurt).

[ Voor 7% gewijzigd door deadinspace op 15-04-2005 17:16 ]

Pagina: 1