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