On Mon 09 Oct 2006 16:44, Michael Griego wrote:
On Oct 9, 2006, at 8:01 AM, Peter Nixon wrote:
In multi threaded mode we constantly get:
Mon Oct 9 15:48:46 2006 : Info: rlm_sql (sql-acct): There are no DB handles to use! skipped 0, tried to connect 0 Mon Oct 9 15:48:46 2006 : Info: rlm_sql (sql-acct): There are no DB handles to use! skipped 0, tried to connect 0 Mon Oct 9 15:48:46 2006 : Info: rlm_sql (sql-acct): There are no DB handles to use! skipped 0, tried to connect 0
I just recently started switching from a MySQL backend to a PostgreSQL backend, and I'm getting these as well now. Something, IMO, seems to be up with the PGSQL module code as I don't recall having this problem with the MySQL backend. The symptoms at the moment are the server will leak memory like crazy, and I'll start getting the above when enough memory has been leaked that the disk starts going crazy swapping pages in and out, causing the PGSQL processes to stay in an iowait state until they can get a shot at the disk.
Hmm. We don't have the swapping etc but maybe thats because we are keeping too close an eye on it. When radiusd restarts it consumes around 4M or ram but a check of my primary server shows it using 59M at present but still happily authing users (from postgres) and writing detail files. I quick restart dropped it back down again. On the other hand radrelay always seems to stop reading the file and just now it was using 29M or ram, but with a 35M unprocessed spool file. A restart causes it to process the file as expected but by the time it finished the spool it was back up to 24M of ram (inside a minute) so there definately seems to be a per request memory leak. Both are running single threaded.
I have 2 SQL modules, one for autz, which is running against a Slony slave/replica database that FR only ever performs SELECTs on, and ane for accounting.
As I state above I see it for both autz (radiusd) AND accounting (radrelay)
I start seeing the above against my autz database. I upped the number of SQL sockets for that module to 10, but it didn't really do anything since the real problem seems to be the leak, and running out of sockets is only really a symptom brought on by disk activity.
I run 50 sockets per instance.
MySQL only ever had the default 5 sockets, and it had no problem keeping up. The tables are, of course, properly indexed and tested for query speed.
Like I said, my current suspicion is something in the rlm_sql_postgresql module code, maybe a per-query leak, but I'm not sure.
I have not tested with any other database type as yet so I haven't confirmed your postgres suspision although I will try to do that today.
Oh, and this is all with the CVS HEAD.
Sure :-) -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc