Re: [Sqlrelay-discussion] current connections counter in scaler

[David M. <dav...@fi...>]

Yeah, I noticed that there could potentially be an issue with that, but 
the fix looked fairly invasive and I didn't want to mess anything up at 
the last minute before the release.  Looking at it now though, we 
probably should fix it.

Wouldn't it be better if the sqlr-connection processes increment and 
decrement the value in the shm in all cases, and the scaler just reads 
the value from the shm?  The code would be simpler.

The only issue I could see with that is if the sqlr-connections are 
killed with a SIGKILL, then they would fail to decrement the counter, 
though I think the same thing would happen if the scaler were 
incrementing and decrementing the counter.  If you kill a process with 
SIGKILL, does it create a zombie until the parent waits on it?

Dave

On 06/27/2011 09:47 AM, Renat Sabitov wrote:
> Hi David,
>
> I am afraid there is an issue with counting currentconnections. From 
> one perspective it is counted with countConnections() from shm. From 
> another this variable is changed by incConnections() and 
> decConnections().
>
> I made the patch with fork() to have 100% correct information on how 
> many connections are started by scaler, because connection processes 
> not always incremented and decremented currentconnections value in 
> shared memory. With my patch, scaler do not look on shm, but do 
> counting by itself.
>
> There is a problem in my patch: scaler do not care about connections 
> started manually or by the sqlr-start.
>
> With your adoption of the patch currentconnections in scaler is 
> changed by two ways, and this is actually an issue.
>
> I think that scaler should take control under shm->totalconnections 
> for dynamically spawned connections. I've created a patch against 
> current CVS, please take a look and write your thoughts.
>
> I tested patch by killing connections with SIGKILL. Only the first 
> connection (= not spawned) was unable to decrement counter, therefore 
> status shows 2 connections in scaler's view with only 1 process 
> started. Please notice buggy status of open connections/cursors, this 
> is the result of my massacre.
>
>   Open   Server Connections:  13
>   Opened Server Connections:  57
>
>   Open   Client Connections:  34203
>   Opened Client Connections:  34203
>
>   Open   Server Cursors:      65
>   Opened Server Cursors:      294
>
>   Times  New Cursor Used:     68578
>   Times  Cursor Reused:       68592
>
>   Total  Queries:             68587
>   Total  Errors:              0
>
>   Forked Listeners:           0
>
> Scaler's view:
>   Connections:                2
>   Sessions:                   2
>
> Semaphores:
>   +---------------------------------------------+
>   | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |  10 |
>   +---+---+---+---+---+---+---+---+---+---+-----+
>   | 1 | 1 | 1 | 3 | 1 | 1 | 0 | 0 | 0 | 1 |   0 |
>   +---------------------------------------------+
>
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
>
> _______________________________________________________
> Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting
>                http://www.doteasy.com
>
>
> _______________________________________________
> Sqlrelay-discussion mailing list
> Sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion
>
>
> _______________________________________________________
> Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting
>                http://www.doteasy.com



_______________________________________________________
Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting
              http://www.doteasy.com