On 14 Jan 2014, at 21:25, Brian Julin <BJulin@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@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2