Re: Freeradius 3.0.8 Can't create UNIX socket and Too many open files
Hi Ales, You do not modify startup scripts, you raise your limits in /etc/security/limits.conf like this * soft nofile 10240 * soft nproc 10240 But then, you only do that in high-load web servers or in email servers. I do not understand why you would need to do that in a FreeRadius server. Regards
Message: 5 Date: Tue, 28 Apr 2015 16:06:00 +0200 From: Aleš Rygl <ales@rygl.net> To: <freeradius-users@lists.freeradius.org> Subject: Re: Freeradius 3.0.8 Can't create UNIX socket and Too many open files Message-ID: <3d7a8a13084d661d6a5fbe5d1aabf703@rygl.net> Content-Type: text/plain; charset=UTF-8
Hello Alan,
you were right of course. Would it make sense to modify Debian startup script to raise the default value of 2048?
Regards
Ales
-- Regards, -- Rui Ribeiro Senior Sysadm ISCTE-IUL https://www.linkedin.com/pub/rui-ribeiro/16/ab8/434
Hi Rui,
* soft nofile 10240
* soft nproc 10240
But then, you only do that in high-load web servers or in email servers. I do not understand why you would need to do that in a FreeRadius server.
I had to raise them because freeradius daemon was complaining to the log about problems with opening some files. Either the mysql socket or the detail log file. The server is pretty loaded (up to1.600 req/s in peaks). I have about 600 connection to the DB. It looks that problem appeares when the rate goes over 1.100 req/s. Of course the bottleneck is the DB. On the other hand there is not too much to do on the DB side. Having ~1 million of sessions in a InnoDB table with the rates mentioned above is not easy. Nevertheless I am trying to tune the best config for this purpose... Ales
On Apr 28, 2015, at 2:27 PM, Rygl Aleš <ales@rygl.net> wrote:
I had to raise them because freeradius daemon was complaining to the log about problems with opening some files. Either the mysql socket or the detail log file. The server is pretty loaded (up to1.600 req/s in peaks). I have about 600 connection to the DB.
Again, that's likely a problem with the DB.
It looks that problem appeares when the rate goes over 1.100 req/s. Of course the bottleneck is the DB. On the other hand there is not too much to do on the DB side. Having ~1 million of sessions in a InnoDB table with the rates mentioned above is not easy. Nevertheless I am trying to tune the best config for this purpose...
Don't tune FreeRADIUS. Tune the DB. It's the source of the problems. Why are there 1M rows in the InnoDB table? If they're historical, move them to a separate table. Have one "live" session table, and another"historical" table for closed sessions. Fix your schema so that it has the correct indices. No amount of poking FreeRADIUS will make the database run faster. Any changes to FreeRADIUS just work around the issue. They don't fix the issue. Alan DeKok.
Hello Alan
Again, that's likely a problem with the DB.
Don't tune FreeRADIUS. Tune the DB. It's the source of the problems.
Most of possisble config params of the DB is already tuned. Innodb_flush_method, innodb_flush_log_at_trx_commit, innodb_io_capacity, binary logging is disabled...
Why are there 1M rows in the InnoDB table? If they're historical, move them to a separate table. Have one "live" session table, and another"historical" table for closed sessions. Fix your schema so that it has the correct indices.
We have ~1M of records in radacct table and all of them are on-line sessions. That's the problem. I am cleaning closed sessions every 20s, which removes ~2k records to the "historical" table. Maybe some partitioning or data split could help here.
No amount of poking FreeRADIUS will make the database run faster. Any changes to FreeRADIUS just work around the issue. They don't fix the issue.
I guess I am touching the limits of the DB here. Regards Ales
On Apr 28, 2015, at 5:04 PM, Rygl Aleš <ales@rygl.net> wrote:
We have ~1M of records in radacct table and all of them are on-line sessions. That's the problem. I am cleaning closed sessions every 20s, which removes ~2k records to the "historical" table. Maybe some partitioning or data split could help here.
Ah... 99% of the time people have 1M records, they're historical records. In your situation, you should throw more CPU / disk / memory at the problem. Maybe sharding. With 1M online users, you *don't* want to have a single point of failure. Alan DeKok.
On 29 Apr 2015, at 08:55, Alan DeKok <aland@deployingradius.com> wrote:
On Apr 28, 2015, at 5:04 PM, Rygl Aleš <ales@rygl.net> wrote:
We have ~1M of records in radacct table and all of them are on-line sessions. That's the problem. I am cleaning closed sessions every 20s, which removes ~2k records to the "historical" table. Maybe some partitioning or data split could help here.
Ah... 99% of the time people have 1M records, they're historical records.
In your situation, you should throw more CPU / disk / memory at the problem. Maybe sharding. With 1M online users, you *don't* want to have a single point of failure.
Get rid of Maria, switch to REDIS 3.0. -Arran
Hi,
In your situation, you should throw more CPU / disk / memory at the problem. Maybe sharding. With 1M online users, you *don't* want to have a single point of failure.
Get rid of Maria, switch to REDIS 3.0.
PostgreSQL :-) alan
In your situation, you should throw more CPU / disk / memory at the problem. Maybe sharding. With 1M online users, you *don't* want to have a single point of failure.
Get rid of Maria, switch to REDIS 3.0.
Does FreeRADIUS have a native support for it? Ales
On Apr 29, 2015, at 11:59 AM, Rygl Aleš <ales@rygl.net> wrote:
Get rid of Maria, switch to REDIS 3.0.
Does FreeRADIUS have a native support for it?
Yes. See rlm_redis. It's not a drop-in replacement for accounting sessions in SQL. Alan DeKok.
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Rui Ribeiro -
Rygl Aleš