"No DB handles" workaround

[Arran Cudbard-Bell]

On 14 Jan 2014, at 21:25, Brian Julin <BJulin at clarku.edu> wrote:

> 
> 
>> Pete Ashdown wrote:
> 
>> Our SQL server is a 24 core, 32GB, SSD backed server with very light
>> loads.  A slowquery log showed nothing of interest, so we started
>> looking in other directions.
>> 
>> What we found is that if the thread pool max_servers > sql num_sql_socks
>> this error will occur.  I haven't looked at the code, but I am guessing
>> that it is locking one SQL socket per thread, and if you have more
>> threads than sockets, then you will start seeing this error.  We set
>> max_servers and num_sql_socks both to 15 and we haven't seen the error
>> since.

Whilst the error message doesn't really help determine the root cause of the problem there are very few scenarios where having more workers than SQL connections is a valid configuration.

v3.0.x has much better reporting in this area, and will tell you if you hit the connection pool limit.

> Well, your database was obviously not fast enough to outpace the rate
> at which FR can put requests into threads :-)
> 
> IN 3.0 the num_sql_socks is replaced by the more generic "max" option
> in the connection pool config.  In case this is still an issue there for anyone.

Yes. This allows the connection pool to expand if required. Unless there's a very good reason for it not to be, max should be the same as the maximum number of workers.

One good reason for it not to be, would be to limit the number of parallel queries executing on one database instance. If you know that after a certain number of parallel queries total query throughput does not increase, you may set max to that number, and then use the redundant module to write the packets out to a detail file instead.

This may then allow you to clear the request queue fast enough to avoid dropping new requests, or have the NAS time out during transient load spikes.

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20140114/575eb2b7/attachment.pgp>