[Catalyst] Zeus and Catalyst

Duncan Garland Duncan.Garland at motortrak.com
Fri Jan 14 11:02:08 GMT 2011


It's beginning to look like this might be a problem with the way the concurrency of the fastcgi processes is configured.

Most of our other fastcgi scripts handle their own concurrency and start with something like this:

for (my $i = 0; $i < 10; $i++) {
    if (fork() == 0) {

For this reason the concurrency setting in Zeus was set to 0. However, I don't think the Catalyst process forks, at least not by default. I've never seen more than one Catalyst process running. The lock-ups may just have been overload.

Yesterday at about 11am we set the Zeus concurrency to 5. We haven't had a lock up since, so that's obviously helped.

However, the whole mode of operation of the system has changed and there has been a performance hit.

When a request arrives, we get multiple catalyst processes spawned. These hang around for a while, handle the request and die within a couple of minutes. When the next request arrives, the processes have to be started up again.

That's analogous to cgi operation and not what we had before. I thought that fastcgi processes were supposed to handle requests in a loop and I was expecting at least one of the processes to persistent for a significant period of time (eg 30 minutes).

Is this correct operation?



From: Peter Edwards [mailto:peter at dragonstaff.co.uk]
Sent: 12 January 2011 10:55
To: The elegant MVC web framework
Subject: Re: [Catalyst] Zeus and Catalyst

On 12 January 2011 09:02, Duncan Garland <Duncan.Garland at motortrak.com<mailto:Duncan.Garland at motortrak.com>> wrote:

0x0000003bbe20d8e0 in __read_nocancel () from /lib64/libpthread.so.0
(gdb) (gdb) #0  0x0000003bbe20d8e0 in __read_nocancel () from /lib64/libpthread.so.0
No symbol table info available.
#1  0x00002ac7089512a2 in snttread () from /oracle/product/10.2.0/db_1/lib/libclntsh.so.10.1
#14 0x00002ac70861bb27 in OCIStmtExecute () from /oracle/product/10.2.0/db_1/lib/libclntsh.so.10.1
#15 0x00002ac70803adc9 in ora_describe (h=0x108af110, imp_sth=0x15fdfa10) at oci8.c:1997
       my_perl = <value optimized out>
       imp_dbh = 0x15594520
       long_readlen = 6553500
       num_fields = <value optimized out>
       num_errors = <value optimized out>
       has_longs = <value optimized out>
       est_width = <value optimized out>
       nested_cursors = <value optimized out>
       i = <value optimized out>
       status = <value optimized out>

When you execute an Oracle statement OCIStmtExecute () it gets stuck in __read_nocancel ().
Looks like it's either blocked waiting on an uncommitted session elsewhere or you've hit an Oracle bug.
Use the Oracle tools to see what other queries are hanging around when it happens.
See if there are reports of deadlocks or anything in the db error log.

You can also check out



This kind of weirdness is one of the reasons I'm not an Oracle lover :-~

Regards, Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20110114/0354723e/attachment.htm

More information about the Catalyst mailing list