 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I was trying to do a render of a HUGE pile of .pov files using a bash
session. When I came back the next morning, I found that the system was
locked up, and that it had essentially stopped mid-render.
I am trying to diagnose the problem. (At first I worried it a quirk of
linux or KDE and thoroughly embarassed myself on my local LUG email list.)
So here's my current top readout when things appear to be running well.
Suppose I find another alleged system lock-up tomorrow morning and am able
to get top to run. What kinds of things could go wrong, and how would I
differentiate between a problem in KDE's abruptly sending system to sleep,
or my use of povray using up all the memory, memory leaks, etc?
Thanks.
----------------------------------------------------
top - 12:37:18 up 5:55, 1 user, load average: 1.13, 1.26, 1.23
Tasks: 81 total, 2 running, 79 sleeping, 0 stopped, 0 zombie
Cpu(s): 97.3% us, 2.7% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 515984k total, 509000k used, 6984k free, 76864k buffers
Swap: 2963984k total, 0k used, 2963984k free, 153340k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9969 greg 25 0 8196 3884 2132 R 93.2 0.8 17:18.41 povray
8865 root 15 0 126m 50m 2652 S 4.3 10.0 2:20.25 Xorg
9937 greg 15 0 30188 16m 13m S 3.0 3.3 0:14.38 konsole
1 root 16 0 1560 524 456 S 0.0 0.1 0:00.95 init
2 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0
3 root 10 -5 0 0 0 S 0.0 0.0 0:00.18 events/0
4 root 16 -5 0 0 0 S 0.0 0.0 0:00.01 khelper
5 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kthread
7 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 kacpid
--------------------------------------------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
gregjohn spake:
> I was trying to do a render of a HUGE pile of .pov files using a bash
> session. When I came back the next morning, I found that the system was
> locked up, and that it had essentially stopped mid-render.
>
> I am trying to diagnose the problem. (At first I worried it a quirk of
> linux or KDE and thoroughly embarassed myself on my local LUG email list.)
>
> So here's my current top readout when things appear to be running well.
>
> Suppose I find another alleged system lock-up tomorrow morning and am able
> to get top to run. What kinds of things could go wrong, and how would I
> differentiate between a problem in KDE's abruptly sending system to
> sleep, or my use of povray using up all the memory, memory leaks, etc?
>
> Thanks.
Hmm - is it just a lockup of KDE? I. e. the rest of the system is still
responsive?
I've had this a few times (like, 2 or 3 times a -year-) on my system (FC3
with 2.6.15.3 kernel) while using KDE and rendering. I've got an older KDE
(3.3) and when the lockup happens my desktop freezes in total, I have to do
the three finger salute (control-alt-backspace) to get back to a prompt. I
start up in runlevel 3 always (text) so I drop back to a text terminal
instead of GDM / its FC3 equivalent. But I do doubt if this has anything to
do with Pov.
Not that this helps a lot - in my experience, if POV tries to push my system
too hard as regards memory (full physical and full virtual) it simply gets
killed. This happened to me -once- only. My system got a bit unresponsive
(as its memory resources where exhausted) but the moment the Pov process
got killed it was back to normal. What kernel version are you using?
As far as I know (if pov uses the normal libc calls for memory management)
those are pretty robust and unlikely to fragment RAM badly enough to slow
down the system or crash it.
Best advice might be to render in runlevel 3 (text mode) and see if it still
locks up? I usually do this - my system boots up in text mode, and I leave
it in text mode for rendering in RL3. If I want to use the GUI, I simply
start it up with "startx" in a terminal. Rendering like that (i. e. in text
mode) I've never had any lockups. Are you sure your hardware is OK? I had a
board with a flaky IDE interface once that did mostly what you described
when I left it rendering overnight...
Kind regards,
--
Stefan Viljoen
Software Support Technician / Programmer
Polar Design Solutions
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks for this analysis.
I've since discovered that I'm not suffering so much from a system lock-up
but the aggravating but possibly normal effects of the odd thing I was
doing.
Odd thing I was doing: a bash script to render every one of 3000 *.pov
files in a directory, some buggy, some involving massive parsing time, some
involving massive radiosity calc times.
Soooo, coming back to the box after letting it run overnight, I would shake
mouse and see the screen. But the various components of the KDE session
were unresponsive. I for example, could not access files with konqueror.
They never came back to a usable state. (In computing terms, this means
they didn't come back within the three to four minutes it took to exhaust
my patience. They *did* however come back on another day when I gave it a
full ten minutes.) I guess this is understandable given the massive
undertaking of CPU resources in the background.
Stefan Viljoen <spamnot@<removethis>polard.com> wrote:
> gregjohn spake:
>
> > I was trying to do a render of a HUGE pile of .pov files using a bash
> > session. When I came back the next morning, I found that the system was
> > locked up, and that it had essentially stopped mid-render.
> >
> > I am trying to diagnose the problem. (At first I worried it a quirk of
> > linux or KDE and thoroughly embarassed myself on my local LUG email list.)
> >
> > So here's my current top readout when things appear to be running well.
> >
> > Suppose I find another alleged system lock-up tomorrow morning and am able
> > to get top to run. What kinds of things could go wrong, and how would I
> > differentiate between a problem in KDE's abruptly sending system to
> > sleep, or my use of povray using up all the memory, memory leaks, etc?
> >
> > Thanks.
>
> Hmm - is it just a lockup of KDE? I. e. the rest of the system is still
> responsive?
>
> I've had this a few times (like, 2 or 3 times a -year-) on my system (FC3
> with 2.6.15.3 kernel) while using KDE and rendering. I've got an older KDE
> (3.3) and when the lockup happens my desktop freezes in total, I have to do
> the three finger salute (control-alt-backspace) to get back to a prompt. I
> start up in runlevel 3 always (text) so I drop back to a text terminal
> instead of GDM / its FC3 equivalent. But I do doubt if this has anything to
> do with Pov.
>
> Not that this helps a lot - in my experience, if POV tries to push my system
> too hard as regards memory (full physical and full virtual) it simply gets
> killed. This happened to me -once- only. My system got a bit unresponsive
> (as its memory resources where exhausted) but the moment the Pov process
> got killed it was back to normal. What kernel version are you using?
>
> As far as I know (if pov uses the normal libc calls for memory management)
> those are pretty robust and unlikely to fragment RAM badly enough to slow
> down the system or crash it.
>
> Best advice might be to render in runlevel 3 (text mode) and see if it still
> locks up? I usually do this - my system boots up in text mode, and I leave
> it in text mode for rendering in RL3. If I want to use the GUI, I simply
> start it up with "startx" in a terminal. Rendering like that (i. e. in text
> mode) I've never had any lockups. Are you sure your hardware is OK? I had a
> board with a flaky IDE interface once that did mostly what you described
> when I left it rendering overnight...
>
> Kind regards,
>
> --
> Stefan Viljoen
> Software Support Technician / Programmer
> Polar Design Solutions
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 03 Apr 2006 08:53:22 -0400, gregjohn wrote:
> They *did* however come back on another day when
> I gave it a full ten minutes.
Are you doing something like a 'renice -20 `pidof povray`' in your script?
That's the only thing I've done that causes this sort of behaviour...
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
