Re: [Dbbalancer-users] Re: [ dbbalancer-Bugs-477967 ] Configuration of backing off strategy
Status: Alpha
Brought to you by:
xperience
Menu
▾
▴
Re: [Dbbalancer-users] Re: [ dbbalancer-Bugs-477967 ] Configuration of backing off strategy
|
From: Andrew M. <an...@ca...> - 2001-11-04 19:09:57
|
On Mon, 2001-11-05 at 01:15, Daniel Varela Santoalla wrote: > > > > In the event that all back-end connections are in use, > > it would be reasonable to put the request into a queue, > > holding it in abeyance for a [configurable] period of > > time before finally giving up and returning the > > connection failure to the client. > > Well, I think that's what happens now, not at the connection level but at the > thread pool level. Given that the thread number is equal to the connections > number (which is the logical approach), if all the connections are busy is > because all the threads are also busy. Then it is DBThreadPool who enqueues > (via its activation_queue_ attribute) all new requests. Of course this > doesn't work if there's a bigger number of threads than connections, but this > situation should never happen unless configured so, because even the growing > and shrinking of pools go synchronized (thread and conns at the same time and > equivalent number). > > Please tell me if you found a different behaviour, cos it surely could be a > bug. I tried setting: daemon.init-db-connections=1 daemon.min-db-connections=1 daemon.max-db-connections=1 And connecting several times in quick succession. I saw a lot more failures than I was hoping for. Watching the process of finding a connection also appeared to have almost no wait: (1024, 07:50:19.047101) Connection received. (1024, 07:50:19.047286) Waiting for a connection to server socket. (5126, 07:50:19.047384) Pool 0 is going to be asked for a connection... (5126 07:50:19.047446) DBPool::getPooledConnection(): Checking Pool 0, Conn 0, NConns 1. (5126, 07:50:19.047505) Connection 0::0 is NOT free!!!. (5126, 07:50:19.047557) Pool 0 won't give us a connection (try 0)!!! (5126, 07:50:19.047607) Pool 0 is going to be asked for a connection... (5126 07:50:19.047657) DBPool::getPooledConnection(): Checking Pool 0, Conn 0, NConns 1. (5126, 07:50:19.047709) Connection 0::0 is NOT free!!!. (5126, 07:50:19.047758) Pool 0 won't give us a connection (try 1)!!! (5126, 07:50:19.047808) Pool 0 is going to be asked for a connection... (5126 07:50:19.047858) DBPool::getPooledConnection(): Checking Pool 0, Conn 0, NConns 1. (5126, 07:50:19.047910) Connection 0::0 is NOT free!!!. (5126, 07:50:19.047959) Pool 0 won't give us a connection (try 2)!!! (5126, 07:50:19.048009) Pool 0 is going to be asked for a connection... (5126 07:50:19.048059) DBPool::getPooledConnection(): Checking Pool 0, Conn 0, NConns 1. (5126, 07:50:19.048111) Connection 0::0 is NOT free!!!. (5126, 07:50:19.048160) Pool 0 won't give us a connection (try 3)!!! (5126, 07:50:19.048210) Pool 0 is going to be asked for a connection... (5126 07:50:19.048260) DBPool::getPooledConnection(): Checking Pool 0, Conn 0, NConns 1. (5126, 07:50:19.048312) Connection 0::0 is NOT free!!!. (5126, 07:50:19.048361) Pool 0 won't give us a connection (try 4)!!! (5126, 07:50:19.048411) Pool 0 is going to be asked for a connection... (5126 07:50:19.048460) DBPool::getPooledConnection(): Checking Pool 0, Conn 0, NConns 1. (5126, 07:50:19.048512) Connection 0::0 is NOT free!!!. (5126, 07:50:19.048561) Pool 0 won't give us a connection (try 5)!!! (5126, 07:50:19.048611) Pool 0 is going to be asked for a connection... (5126 07:50:19.048661) DBPool::getPooledConnection(): Checking Pool 0, Conn 0, NConns 1. (5126, 07:50:19.048713) Connection 0::0 is NOT free!!!. (5126, 07:50:19.048762) Pool 0 won't give us a connection (try 6)!!! (5126, 07:50:19.048812) Pool 0 is going to be asked for a connection... (5126 07:50:19.048862) DBPool::getPooledConnection(): Checking Pool 0, Conn 0, NConns 1. (5126, 07:50:19.048914) Connection 0::0 is NOT free!!!. (5126, 07:50:19.048963) Pool 0 won't give us a connection (try 7)!!! (5126, 07:50:19.049013) Pool 0 is going to be asked for a connection... (5126 07:50:19.049093) DBPool::getPooledConnection(): Checking Pool 0, Conn 0, NConns 1. (5126, 07:50:19.049145) Connection 0::0 is NOT free!!!. (5126, 07:50:19.049194) Pool 0 won't give us a connection (try 8)!!! (5126, 07:50:19.049244) Pool 0 is going to be asked for a connection... (5126 07:50:19.049294) DBPool::getPooledConnection(): Checking Pool 0, Conn 0, NConns 1. (5126, 07:50:19.049346) Connection 0::0 is NOT free!!!. (5126, 07:50:19.049394) Pool 0 won't give us a connection (try 9)!!! (5126, 07:50:19.049445) Impossible to get a connection after 10 tries!!! (5126, 07:50:19.049494) We have not been able to get a connection. Closing client connection. (4101, 07:50:19.082427) 1 descriptors modified. (4101, 07:50:19.082540) Received 47 bytes from BE socket. HEXDUMP 47 bytes 50 62 6c 61 6e 6b 00 54 00 01 64 65 74 61 69 6c Pblank.T..detail 5f 68 69 74 00 00 00 00 17 00 04 ff ff ff ff 44 _hit...........D 80 00 00 00 05 31 43 53 45 4c 45 43 54 00 5a .....1CSELECT.Z (4101, 07:50:19.082700) Sent 47 bytes to FE socket. ************** handleConnectionLoop (it: 56) ************* (4101, 07:50:19.089890) 1 descriptors modified. (4101, 07:50:19.090006) Data in FE socket. (4101) End of connection intercepted. (4101, 07:50:19.090106) Received 2 bytes from FE socket. (4101, 07:50:19.090180) Connection: 0::0 has finished. Now FREE! What I was expecting to see was that the connections were serialised, so that the time to respond should have increased to include the time to wait for previous connections to finish. As you can see from the above example the _total_ wait for 10 attempts was 0.00184 of a second: (5126, 07:50:19.047505) Connection 0::0 is NOT free!!!. (5126, 07:50:19.049346) Connection 0::0 is NOT free!!!. Had we been able to wait for only 0.05 of a second we would have seen: (4101, 07:50:19.090180) Connection: 0::0 has finished. Now FREE! So it looks like a bug... Ideally I would see the number of attempts and the first retry delay as configurable. I would then multiply the retry wait by 1.5 for each subsequent retry. > What DBBalancer should also make better is the strategy to adaptively modify > the number of threads and conns. Now it checks the average length of the > latest 3 checks of the queue, but, while this avoids overreacting to fast > bursts of requests, it's is quite slow on adapting. Sounds like you are saying that it would not be a good idea to set: daemon.reaper-delay=60 I had assumed that this only applied to _reaping_, not starting up... I think a straightforward approach would be to start connections immediately if you find none available but are below daemon.max-db-connections - this would make things responsive to a quickly ramping load. I consider reaping those when they haven't been used as a _much_ lower priority, hence my setting of the reaper delay to a higher level. > > Hand in hand with this, it would be good to get > > statistics of connections handled / connections queued > > / connections dropped dumped to syslog every > > [configurable] seconds. These statistics would enable > > the system admin to tune the numbers of client and > > server connections. > > Some of these are already available. In fact, in DEBUG mode, DBThreadPool > dumps the length and average (3 last checks) length of its queue. Anyway they > should be augmented with more data, that's true. It's not debugging information, it's management information, so I want to be able to accumulate it on a busy website over several days before (perhaps) turning it off. Naturally I _don't_ want to be logging every query during that time :-) Cheers, Andrew. -- -------------------------------------------------------------------- Andrew @ Catalyst .Net.NZ Ltd, PO Box 11-053, Manners St, Wellington WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St DDI: +64(4)916-7201 MOB: +64(21)635-694 OFFICE: +64(4)499-2267 |
