You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Leo Simons <le...@apache.org> on 2004/02/19 17:51:59 UTC
gumpy memory size
last night's run is still running (that's about 14 hours). Memory
usage...454mb:
1642 ajack 30 15 454M 201M 154M R N 1.5 80.7 34:08 0 python
do we have a memory leak somewhere?
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
Re: gumpy memory size
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
Last thing in log is this:
INFO:gump:Document run using [<gump.document.forrest.ForrestDocumenter
instance at 0x99df2f4>]
i.e. running forrest. That said, I can see no reason, why waiting for
soemthing to run might cause this Gumpy to grow. That said, I hate how I
coded the 'tear down' code in Python, it was (is) a mega kludge since Python
doesn't seem mature enough for process management at that level.
BTW: I ran forrest by hand for grins.
validate-xdocs:
/data3/gump/forrest/src/documentation/content/xdocs/xml-forrest/work/build_x
ml-forrest_xml-forrest-scratchpad-forrestdoc-ws.xml:1:1: Premature end of
file.
BUILD FAILED
/home/ajack/opt/forrest/forrest.build.xml:761: Could not validate document
/data3/gump/forrest/src/documentation/content/xdocs/xml-forrest/work/build_x
ml-forrest_xml-forrest-scratchpad-forrestdoc-ws.xml
Now, that didn't take long, so Gumpy ought have moved on. With --debug we'll
see if it did (and if the problems were in nagging, or RSS, or ... ???)
[I've not added anything new recently, that ought be there, or ought be
running other than in unit tests.]
BTW: We saw this error when we were low on disk space. Maybe it is a stray
file that wasn't cleaned up, but it seems odd it showed up again. I'll
delete it and see what gives next run.
regards
Adam
Re: gumpy memory size
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> 1642 ajack 30 15 454M 201M 154M R N 1.5 80.7 34:08 0 python
>
> do we have a memory leak somewhere?
Python is a hard language to debug, at least for me & especially at the size
of things that a Gump workspace generates. Any Python folks know how to get
inside this thing?
Gumpy internals are getting a little out of control, but nothing that ought
cause this. If I run a copy w/ --debug maybe I can see where it was at when
it grew.
regards
Adam
Re: gumpy memory size
Posted by Leo Simons <le...@apache.org>.
Adam R. B. Jack wrote:
> I'm watching a Gumpy run, and it's memory usage is minute in comparison:
>
> 18013 ajack 16 0 24116 5324 1028 S 1.3 0.5 3:20 0 python
that's neat. I haven't been monitoring very closely, but it seems that
gumpy is doing much better now. Less garbage processes as well. The
other night gumpy was running in parallel with X and a playing XMMS (mp3
player), and it finished before 9:00am.
>>last night's run is still running (that's about 14 hours). Memory
>>usage...454mb:
>> 1642 ajack 30 15 454M 201M 154M R N 1.5 80.7 34:08 0 python
>>do we have a memory leak somewhere?
>
> Could it be that Gumpy was niced so low that Python's garbage collection
> loop (I assume it has one) wasn't kicking in? Long shot, but I wonder.
hum. I actually decreased gump's priority (from 10 to 15) a while back
in your crontab. Maybe that did the trick ;)
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: gumpy memory size
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
I'm watching a Gumpy run, and it's memory usage is minute in comparison:
18013 ajack 16 0 24116 5324 1028 S 1.3 0.5 3:20 0 python
> last night's run is still running (that's about 14 hours). Memory
> usage...454mb:
> 1642 ajack 30 15 454M 201M 154M R N 1.5 80.7 34:08 0 python
> do we have a memory leak somewhere?
Could it be that Gumpy was niced so low that Python's garbage collection
loop (I assume it has one) wasn't kicking in? Long shot, but I wonder.
For anybody whose looked at the logs a little while back, you'd've seen I
tried to detect resources (via Python call) but it doesn't appear to be
fully implemented & reports '0' for memory usage.
Anyways, memory usage doesn't seem to be a problem right now.
BTW: I did put a lock into gumpy.py, not that this is finished/fully
deployed yet.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: gumpy memory size
Posted by Leo Simons <le...@apache.org>.
I'm now seeing:
[root@lsd root]# ps -aux | grep ajack
ajack 1551 0.0 0.0 3560 4 ? S Feb19 0:00 /bin/sh
-c cd /data3/gump/gump; /bin/nice -n 15 /bin/bash
/data3/gump/gump/gumpy.sh | /bin/mail -s 'LSD Gump' ajack@trysybase.com
ajack 1557 0.0 0.0 2840 4 ? SN Feb19 0:00 /bin/bash
/data3/gump/gump/gumpy.sh
ajack 1558 0.0 0.0 2448 4 ? S Feb19 0:00 /bin/mail
-s LSD Gump ajack@trysybase.com
ajack 1642 2.2 49.3 622296 126064 ? RN Feb19 41:25 python
gump/integrate.py -w ../lsd.xml all
ajack 29912 0.0 0.1 3336 384 ? S 02:00 0:00 /bin/sh
-c cd /data3/gump/gump; /bin/nice -n 15 /bin/bash
/data3/gump/gump/gumpy.sh all --debug
ajack 29916 0.0 0.1 2984 400 ? SN 02:00 0:00 /bin/bash
/data3/gump/gump/gumpy.sh all --debug
ajack 30001 0.7 8.4 50448 21536 ? SN 02:00 2:37 python
gump/integrate.py -w ../lsd.xml all all --debug
ajack 10417 0.0 0.3 2904 796 ? SN 08:06 0:00 sh -c
java -Djava.awt.headless=true
-Xbootclasspath/p:/data3/gump/xml-xerces2/java/build/xercesImpl.jar:/data3/gump/xml-xerces2/java/build/xmlParserAPIs.jar
org.apache.tools.ant.Main -Dbuild.clonevm=true
-Dgump.merge=/data3/gump/gump/work/merge.xml -Dbuild.
ajack 10418 14.7 21.4 223004 54768 ? SN 08:06 0:08 java
-Djava.awt.headless=true
-Xbootclasspath/p:/data3/gump/xml-xerces2/java/build/xercesImpl.jar:/data3/gump/xml-xerces2/java/build/xmlParserAPIs.jar
org.apache.tools.ant.Main -Dbuild.clonevm=true
-Dgump.merge=/data3/gump/gump/work/merge.xml -Dbuild.syscla
ajack 10524 60.0 4.4 218956 11272 ? SN 08:07 0:00
/usr/java/j2sdk1.4.2/jre/bin/java -Dbasedir=. -classpath
/usr/java/j2sdk1.4.2/lib/tools.jar:/data3/gump/jakarta-commons/jelly/target/classes:/data3/gump/jakarta-commons/jelly/target/test-classes:/data3/gump/ant/dist/lib/ant-stylebook.jar:/data3/gump/ant/dis
root 10535 0.0 0.2 4388 580 pts/3 R 08:07 0:00 grep ajack
IOW, the new instance started while the old was still sleeping (which is
probably defunct). I've now killed the old one (saved some relevant
/proc data in ~ajack/procstuff). The new one is still runnning.
I think we need to update the shell scripts to write out a pid, and have
the next gump run kill the old one (with a warning!). I'll go and see
about that.
Let's hope the --debug helps us determine what part of the code to
inspect :D
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
Re: gumpy memory size
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> last night's run is still running (that's about 14 hours). Memory
> usage...454mb:
>
> 1642 ajack 30 15 454M 201M 154M R N 1.5 80.7 34:08 0 python
>
Interestingly while still merrily tinkering along we see 545M...
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
1642 ajack 30 15 545M 167M 24440 D N 0.3 67.1 38:40 0 python
... what kinda of beastie is Gumpy? A hog, it seems...
Ok, so maybe Python is as fluffy as Java w/ garbage collected object, and
maybe Gumpy is greedy, but I can't see what would do this. The 'big stuff'
(the build outputs) are kept in files, not memory. All that ought be in
memory are the object (admittedly many) that represent the annotated run
tree.
1) What is causing this? How does one introspect Python memory?
2) What was causing Gumpy to still be running @ 80% CPU 14 hours later?
regard
Adam