radrelay (mode) from cvs head

[Peter Nixon]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20061010/5b7802d8/attachment.pgp>