Workload in freeradius? platform
Fajar A. Nugraha
list at fajar.net
Sat Oct 15 01:34:00 CEST 2011
On Fri, Oct 14, 2011 at 10:47 PM, Guillaume Sigui <gsigui at live.fr> wrote:
> Ok, sorry. I explain below with more details:
Guillaume, let me put this another way.
Most of the things you've wrote is irrelevant to this list.
This list is freeradius mailing list. Not alcatel list, not mysql
list, not some support for an ISP.
You asked a question "why is freeradius slow". Then you were given a
response "which part of it is slow". Then you posted a lot of
information, but none of which is really relevant. Then you posted log
of radiusd -X starting up, but without it receiving any packets at
all, thus making it almost useless for diagnostic purposes.
Do you understand now why some people here have expressed frustration
reading your post, even to go as far as unsubscribing you?
I'm going to assume that you don't deliberately intend to do so, and
that you simply don't know where to look. Here's a hint: when
freeradius is slow, usually it's the backend that's slow. The backend
- a database (e.g. Mysql)
- another radius server (when running proxy configuration)
How can you find out what's slow? One way (but not the only way) would be:
- run freeradius in debugging mode
- send access-request and/or accounting packets for ONE session
- see where it's slow
Usually that means you need to have a test server, with freeradius
installed, using the same backend that your production server uses.
After you find out what's causing the slowness, then
freeradius-related part is complete. You'll need to work on whatever
it is on the backend that's causing the slowness.
Now, since you say
> - each server has his own database server, so there are 04 database servers.
> It's Mysql 5.
Then most likely the problem is in the database. Usual causes:
- there are too many accounting records (e.g. several millions), and
your configuration scans the records every time an authentication
occurs (e.g. for simultaneous-check)
- the table structurs has non-optimal index, or your queries are
non-optimal that it uses many full table scans
- your db server performance simply sucks
Are you still with me so far?
Now if my previous guess is correct, then to further diagnose this
problem you need a DBA. If you don't have the skills needed, hire one.
A DBA would be able to determine whether or not MySQL is REALLY the
cause of slowness, and he'll also be able to do some steps to improve
If you DON'T have a DBA, and DON'T intend to hire one, then I can only
say sorry, but no ammount of mail posted to any mailing list will be
able to help you. You'll just annoy others.
More information about the Freeradius-Users