On Tue, 21 Oct 2003, Graeme Hinchliffe wrote: > > > When the database is used heavily by another process freeradius eats > > > loads of CPU, becomes unresponsive and eventually just dies. This only seems > > > to happen when another process (such as mysql_dump) is ran on the database. > > > > radiusd should never die. Check for any core dumps. In any case if you are using > > mysqldump it will acquire a global lock on the db and not allow the radiusd sql > > queries to run. As a result the radiusd process will become unresponsive (though > > it should not eat loads of CPU) > > That fits with what happens, I think I got the order slightly out. To be more > precises: > > The radiusd runs happily. mysqldump starts and radiusd complains about > unresponsive children, the number of threads increases until the mysqldump > finishes, at which point the number of threads begins to drop. The no of > threads gets to about 20 (initial start value is 5).. at which point the > daemon locks up and consumes lots of CPU. It has to be kill -9'd to stop and > then restart.
That's bad. Try running it like radiusd -xxx and send back the results. It would be nice if you upgraded to 0.9.2 first though. > > I always thought that the lock would be to stop writes to the db? not reads? I think it's a global lock though i am not sure. In any case you are using radiusd for accounting right (which means writing to the db)? > > -- > ----- > Graeme Hinchliffe (BSc) > Core Team Member > Zen Internet (http://www.zen.co.uk) > > ICQ 3842605 (link) > > Direct: 0845 058 9074 > Main : 0845 058 9000 > Fax : 0845 058 9005 > > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > -- Kostas Kalevras Network Operations Center [EMAIL PROTECTED] National Technical University of Athens, Greece Work Phone: +30 210 7721861 'Go back to the shadow' Gandalf - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
