Hibernating: Major impact on authentication!
Hello, Considering that all things indicate that there might be a problem with the DB, I did some tweaks in PostgreSQL and took off the cron.hourly job. Gonna watch out for problems then, thanks! --------------------------------------------------------- Hi, Freeradius 1.1.4 is randomly losing connection to both databases and it's causing total loss in the authentication process: Info: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0 Info: rlm_sql (sql_postgresql): There are no DB handles to use! skipped 0, tried to connect 0 Info: The maximum number of threads (32) are active, cannot spawn new thread to handle request Running either in multi or single threaded mode, that messages appeared 47.099,00 times since Jan 27! Freeradius is configured with 32 max_servers and 32 connections to each DB. There's no starving since no accounting is being used and the server have to handle just 3 auths per second. Every time this happens, no one can authenticate and doing a restart in Freeradius solves the problem. To circumvent the problem, I've added a cron.hourly job so each hour a "service radiusd restart" is issued. As this is random, it's hard to debug, but at the same time freeradius loses the connection, several other applications can successfully connect/ maintain previous established connections to the databases. I've enabled all sorts of debug in the databases trying to better understand why freeradius is doing this, but there was no luck. I've installed the latest CVS and the same problem appeared, please help!
Mr. Franco, I have not looked at the DB connection code, but is there a connection timer on the DB connection. That is, does the connection get dropped and restarted occasionally or does it persist until the connection dies? If the latter, the problem could be that the long running connections are not allowing the indexes and table spaces to be maintained properly. This could cause bloat and performance problems over time. After a restart it would clear up since now the vacuum DB maintenance process can clear the outstanding blocks. A restart of each connection handle every few thousand or so queries by the radius server would solve that problem. Just an idea. Ken On Mon, Feb 05, 2007 at 06:30:57PM -0200, Guilherme Franco wrote:
Hello,
Considering that all things indicate that there might be a problem with the DB, I did some tweaks in PostgreSQL and took off the cron.hourly job.
Gonna watch out for problems then, thanks!
---------------------------------------------------------
Hi,
Freeradius 1.1.4 is randomly losing connection to both databases and it's causing total loss in the authentication process:
Info: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0 Info: rlm_sql (sql_postgresql): There are no DB handles to use! skipped 0, tried to connect 0 Info: The maximum number of threads (32) are active, cannot spawn new thread to handle request
Running either in multi or single threaded mode, that messages appeared 47.099,00 times since Jan 27! Freeradius is configured with 32 max_servers and 32 connections to each DB. There's no starving since no accounting is being used and the server have to handle just 3 auths per second.
Every time this happens, no one can authenticate and doing a restart in Freeradius solves the problem. To circumvent the problem, I've added a cron.hourly job so each hour a "service radiusd restart" is issued.
As this is random, it's hard to debug, but at the same time freeradius loses the connection, several other applications can successfully connect/ maintain previous established connections to the databases. I've enabled all sorts of debug in the databases trying to better understand why freeradius is doing this, but there was no luck.
I've installed the latest CVS and the same problem appeared, please help!
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Kenneth Marshall wrote:
Mr. Franco,
I have not looked at the DB connection code, but is there a connection timer on the DB connection. That is, does the connection get dropped
No
If the latter, the problem could be that the long running connections are not allowing the indexes and table spaces to be maintained properly. This could cause bloat and performance problems over time. After a
At least on Postgres, this is NOT correct. Open *transactions* block such activity. However the base rlm_sql doesn't use transactions because they're un-needed, and the rlm_sql_ippool module executes very short running transactions indeed. I believe the OP is running Postgres, but if anyone finds themselves running a database where maintaining long-running connections blocks maintenance jobs, I would recommend the un-install it immediately.
On Tue, Feb 06, 2007 at 09:14:47AM +0000, Phil Mayers wrote:
Kenneth Marshall wrote:
Mr. Franco,
I have not looked at the DB connection code, but is there a connection timer on the DB connection. That is, does the connection get dropped
No
If the latter, the problem could be that the long running connections are not allowing the indexes and table spaces to be maintained properly. This could cause bloat and performance problems over time. After a
At least on Postgres, this is NOT correct.
Open *transactions* block such activity. However the base rlm_sql doesn't use transactions because they're un-needed, and the rlm_sql_ippool module executes very short running transactions indeed.
I believe the OP is running Postgres, but if anyone finds themselves running a database where maintaining long-running connections blocks maintenance jobs, I would recommend the un-install it immediately. -
True. It is not freeradius' job to manage the DB. Are there any other databases on the server that could have a long running transaction and are preventing the clean-up of the ippool DB? Ken
participants (3)
-
Guilherme Franco -
Kenneth Marshall -
Phil Mayers