[Zope] Problems with restarts, memory usage, DB connections, FastCGI ?? Help!

[Charlie Reiman]

> -----Original Message-----
> From: Jean-Francois.Doyon@CCRS.NRCan.gc.ca
> [mailto:Jean-Francois.Doyon@CCRS.NRCan.gc.ca]
> Sent: Thursday, October 24, 2002 10:21 AM
> To: creiman@kefta.com; zope@zope.org
> Subject: RE: [Zope] Problems with restarts, memory usage, DB
> connections, FastCGI ?? Help!
>
>
> Charlie,
>
> Thanks for the insights, this should proove useful.
>
> About the momory, to be honest, I'm not convinced that's it.
> Yesterday for
> instance, Zope showed that behavior TWICE in one day, the first time it
> recovered itself, the second, I restarted.  But, throughtout all
> this, there
> was PLENTY of swap available (My swap space is 2GB). I've NEVER seen the
> swap usage go beyond ~150MB actually.

Well, keep in mind swap is irrelevant here. It's physical memory that
matters. If you are swapping heavily, it's too late. That's why I suggested
looking into top and ps. Under solaris, ps will show the RSS (resident set
size) which corresponds to the physical memory currently being used by the
process. I have this little script in my bin directory (named "fatties", I'm
ashamed to admit):

#!/bin/sh
echo "%MEM  RSS     USER   PID %CPU COMMAND"
ps -ef -o pmem,rss,user,pid,pcpu,comm | sort -nr +1 | head -10

That lists the top 10 consumers of physical memory on the system. Top can do
this as well and it's easier to use but it defaults to sorting by CPU load.

If you determine you are running low on physical memory, you then need to
figure out why. The big file uploads are top suspects but there is always
the possibility of a leak. But since you claim the situation clears itself
up, I'm inclined to blame the big file uploads.

> >From what you're saying, I think this issue of one thread per
> request might
> be the problem. I'm going to start by tackling this. It's the easiest and
> cheapest way for now.  The issue of long requests (People adding
> data/content) mixed with the heavy load of the server (i.e. requests per
> second), and it is forseeable that this would happen.
>
> The issue of the large images is allways in my mind, but since that only
> happens occasionally, and in batches (It was going on this week), I'm
> willing to risk it for the increased convenience.
>
> While on the topic, I'm just curious as to why the processes/threads are
> structured as such:
>
>  |-python2.1,11334) /usr/local/Zope-2.5.0/z2.py -F /tmp/fcgi/zope.soc -w -
> -p - -f - -D
>   |   `-python2.1,11337) /usr/local/Zope-2.5.0/z2.py -F /tmp/fcgi/zope.soc
> -w - -p - -f - -D
>   |       `-python2.1,11353) /usr/local/Zope-2.5.0/z2.py -F
> /tmp/fcgi/zope.soc -w - -p - -f - -D
>   |           |-python2.1,11354) /usr/local/Zope-2.5.0/z2.py -F
> /tmp/fcgi/zope.soc -w - -p - -f - -D
>   |           |-python2.1,11355) /usr/local/Zope-2.5.0/z2.py -F
> /tmp/fcgi/zope.soc -w - -p - -f - -D
>   |           |-python2.1,11356) /usr/local/Zope-2.5.0/z2.py -F
> /tmp/fcgi/zope.soc -w - -p - -f - -D
>   |           `-python2.1,11357) /usr/local/Zope-2.5.0/z2.py -F
> /tmp/fcgi/zope.soc -w - -p - -f - -D
>
> One talks to one talks to one talks to four ... Also, if I'm seeing it in
> PS, is it really a thread ? Or a process ? ps -m isn't
> implemented on unix,
> therefore can't show threads, so what am I seeing ???

I cannot say for certain. It's common for server processes to wrap worker
threads with helpers that pick them up if they crash so that might be it. It
might also be a side effect of your OS.