[Zope] zope2.2.0 and what is high load
Bak @ kedai
bak@nstp.com.my
Fri, 11 Aug 2000 09:59:55 +0800
On Thu, 10 Aug 2000, Chris McDonough wrote:
> It sounds like your load may not be very small.
>
> Your -t25 setting to threads does not help too much, because the number
> of database connections is hard-limited to 7 in the ZODB source.
>
> It might help to visit the debug section of the control_panel to get an
> understanding of how many threads are actually being used at any given
> moment. If you find that all 7 threads are being continually used
> simultaneously, and your box can handle more threads (e.g. it's not CPU-
> or RAM-bound already), we can probably figure out how to bump you up to
> more database connection threads per client by changing the source.
> This should really be a knob somewhere.
>
i went to each Zeo client control_panel, and see that there's a mzximum of
four connections open at any given time. this is the number of onnections
right after update snapshot/refresh /auto refresh statement in control_panel.
to confirm, i went to all other zope 2.2.0 instance that i got, - yes, only
four spaces available. i remember seing the number 4 is mentioned in z2.py
----from z2.py----
# The size of the thread pool, if ZODB3 is used.
NUMBER_OF_THREADS=4
---end--------
CPU and RAM is plenty in one of the boxes (4 G RAM, 2 CPUs) and quite limited
in another (700k RAM and 2CPUs).
why wouldn't increasing the number of threads with -t25 affect the way zope
behave? do i need to change it in z2.py? what are the things that i should
know before i do that? will this have effect on connections that access data
from rdb? sorry if i sound like a fool here, (maybe i am :)), but i don't
get zope that deep yet.
> There is also a profiling facility inside Control_Panel/debug that does
> some sort of automated performance compilation for you, though I've
> never had a reason to use it. When it's running, it also purportedly
> slows Zope down quite a bit.
>
profiling is not enabled since i dont really know the heck it does.
> Or, of course, you could always throw in another ZEO client if you're
> getting hit too hard to handle the load.
>
this will be the last resort because it cost us dollars
> I suggest that you:
>
> 1) Monitor your Zope clients' thread usages by using their debug
> facilities.
done. as mentioned above, the number of connections is four at most. what
else should i look for in the debugInfo?
> 2) Monitor your Zope clients' general CPU and memory usages via vmstat
> or top or what-have you.
----
9:45am up 21 days, 20:29, 4 users, load average: 1.73, 1.63, 1.59
318 processes: 314 sleeping, 4 running, 0 zombie, 0 stopped
CPU states: 109.0% user, 17.0% system, 0.0% nice, 76.9% idle
CPU0 states: 51.5% user, 8.2% system, 0.0% nice, 39.2% idle
CPU1 states: 57.1% user, 8.3% system, 0.0% nice, 33.5% idle
Mem: 776788K av, 770932K used, 5856K free, 580284K shrd, 144312K buff
Swap: 134616K av, 1540K used, 133076K free 378260K cached
PID USER PRI NI SIZE RSS SHARE LC STAT %CPU %MEM TIME COMMAND
8907 nobody 18 0 70080 68M 1816 3 R 10.9 9.0 50:30 python
8921 nobody 5 0 70080 68M 1816 3 S 10.7 9.0 38:24 python
8924 nobody 17 0 70080 68M 1816 3 S 10.1 9.0 31:33 python
8914 nobody 6 0 70080 68M 1816 2 S 7.6 9.0 45:43 python
8920 nobody 11 0 70080 68M 1816 2 S 7.2 9.0 44:23 python
15165 root 17 0 948 948 648 2 R 6.8 0.1 0:03 top
8919 nobody 11 0 70080 68M 1816 2 S 5.3 9.0 40:27 python
8930 nobody 4 0 70080 68M 1816 3 S 4.2 9.0 30:31 python
8922 nobody 6 0 70080 68M 1816 2 S 4.0 9.0 36:01 python
8928 nobody 12 0 70080 68M 1816 3 S 4.0 9.0 36:49 python
8923 nobody 5 0 70080 68M 1816 3 S 3.8 9.0 36:27 python
8925 nobody 10 0 70080 68M 1816 3 S 3.8 9.0 42:51 python
8927 nobody 3 0 70080 68M 1816 3 S 3.8 9.0 35:40 python
8915 nobody 3 0 70080 68M 1816 2 S 3.7 9.0 36:08 python
8917 nobody 10 0 70080 68M 1816 2 S 3.7 9.0 39:04 python
8918 nobody 5 0 70080 68M 1816 2 S 3.7 9.0 32:25 python
8931 nobody 5 0 70080 68M 1816 3 S 3.7 9.0 32:34 python
8926 nobody 10 0 70080 68M 1816 2 S 3.5 9.0 31:47 python
8932 nobody 10 0 70080 68M 1816 3 S 3.5 9.0 34:38 python
8933 nobody 10 0 70080 68M 1816 2 S 3.5 9.0 37:53 python
8916 nobody 7 0 70080 68M 1816 2 R 3.1 9.0 41:20 python
13664 postgres 2 0 3696 3696 3204 3 S 1.4 0.4 1:54 postmaster
8561 postgres 2 0 3716 3716 3208 2 S 1.2 0.4 8:06 postmaster
8560 postgres 2 0 3724 3724 3220 2 S 1.1 0.4 8:18 postmaster
8563 postgres 2 0 3740 3740 3212 3 S 0.9 0.4 8:01 postmaster
13825 postgres 2 0 3644 3644 3164 3 S 0.9 0.4 1:00 postmaster
---end top-----
most of the z2 threads are used, although only 3-4 are used heavily. what
does this show?
>
> Then report back your findings and we'll see if we can spot a
> bottleneck.
thanks