Hi, im running freeradius 1.0.5 + postgres 8.0.3 on a dual xeon, gentoo 2005.1, all is working ok, but i have another server with the same hardware specs that i recently "upgraded" from gentoo to freebsd 5.3, the server was running apache + postgres and, wow , great diference, better performance, so postgres definitely liked freebsd, what about freeradius?, i have read on the website that it is developed on debian but it compiles on freebsd, what is your experience with freebsd , good?, bad? , any gotchas?. Should i migrate to freebsd or stay with gentoo?, my personal preference is bsd, but im worried of any obscure future that only works on linux api's ,etc thanks in advance, Miguel
Miguel wrote:
Hi, im running freeradius 1.0.5 + postgres 8.0.3 on a dual xeon, gentoo 2005.1, all is working ok, but i have another server with the same hardware specs that i recently "upgraded" from gentoo to freebsd 5.3, the server was running apache + postgres and, wow , great diference, better performance, so postgres definitely liked freebsd, what about freeradius?, i have read on the website that it is developed on debian but it compiles on freebsd, what is your experience with freebsd , good?, bad? , any gotchas?. Should i migrate to freebsd or stay with gentoo?, my personal preference is bsd, but im worried of any obscure future that only works on linux api's ,etc
I have never had any problems with freeradius on freebsd. You should consider updating your FreeBSD to 5.4. Roy
Hi, im running freeradius 1.0.5 + postgres 8.0.3 on a dual xeon, gentoo 2005.1, all is working ok, but i have another server with the same hardware specs that i recently "upgraded" from gentoo to freebsd 5.3, the server was running apache + postgres and, wow , great diference, better performance, so postgres definitely liked freebsd, what about freeradius?, i have read on the website that it is developed on debian but it compiles on freebsd, what is your experience with freebsd , good?, bad? , any gotchas?. Should i migrate to freebsd or stay with gentoo?, my personal preference is bsd, but im worried of any obscure future that only works on linux api's ,etc
Been using freeradius on freebsd exclusively for several years now. Started with freeradius .8 on freebsd 4.6 I think. Now, I'm running freeradius 1.0.5 on freebsd 5.4. We handle about 75,000 logins per day between 3 servers and are using openldap as a backend, which stores about 400,000 users. We use radrelay to push all the accounting into a mysql db. Its been working perfectly, no issues ever with freeradius or freebsd (can't say the same for harddrives and motherboards though - so you should build redundancy into your architecture). I'm going to write up our architecture one of these days and I'll submit a copy to freeradius, but I'm re-designing everything right now to keep recent, add more redundancy, and simply things. So I've been too busy. There is an old document of the original system I put in, in the doc folder called ldap_howto.txt. Anyway, I'd suggest installing freeradius from the freebsd ports tree since they've got the most recent version in there right now. The ports are just so easy to maintain. However, I do have it running on a few machines compiled from source before the ports tree was updated. Anyway, I'm on the list and read it often, so if you've got freebsd specific questions, feel free to ask. -Dusty Doris BTW this is fun to look at. Below is the last of our old systems, that I haven't replaced yet. Will be doing so in the next few weeks, though. I don't think I've ever touched them more than a few times and only to make config changes. They're just proxy radius servers and only get about 1000-2000 logins per day from some old systems and proxy everything over to our 3 real servers, but I still like the stats. [root@proxy-radius2:~] # radiusd -v radiusd: FreeRADIUS Version 0.8.1, for host i386-unknown-freebsd4.7, built on Mar 26 2003 at 14:36:24 [root@proxy-radius2:~] # w 1:03AM up 932 days, 15:06, 1 user, load averages: 0.00, 0.00, 0.00 [root@proxy-radius2:~] # uname -sr FreeBSD 4.8-RELEASE ---- [root@proxy-radius1:~] # radiusd -v radiusd: FreeRADIUS Version 0.8.1, for host i386-unknown-freebsd4.8, built on May 13 2003 at 13:06:20 [root@proxy-radius1:~] # uname -sr FreeBSD 4.8-RELEASE [root@proxy-radius1:~] # w 1:08AM up 903 days, 17:49, 1 user, load averages: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE WHAT root p0 172.20.1.209 1:08AM - w
Dusty Doris wrote:
Hi, im running freeradius 1.0.5 + postgres 8.0.3 on a dual xeon, gentoo 2005.1, all is working ok, but i have another server with the same hardware specs that i recently "upgraded" from gentoo to freebsd 5.3, the server was running apache + postgres and, wow , great diference, better performance, so postgres definitely liked freebsd, what about freeradius?, i have read on the website that it is developed on debian but it compiles on freebsd, what is your experience with freebsd , good?, bad? , any gotchas?. Should i migrate to freebsd or stay with gentoo?, my personal preference is bsd, but im worried of any obscure future that only works on linux api's ,etc
Been using freeradius on freebsd exclusively for several years now. Started with freeradius .8 on freebsd 4.6 I think.
Ok , there is nothing to worry about then, thanks
Hi Dusty,
Now, I'm running freeradius 1.0.5 on freebsd 5.4. We handle about 75,000 logins per day between 3 servers and are using openldap as a backend, which stores about 400,000 users. We use radrelay to push all the accounting into a mysql db.
Can you comment on the accounting record rate that you're achieving? We're currently testing FreeRadius and I'm seeing a performance ceiling of about 200 accounting records per second. Matthew.
Hi Dusty,
Now, I'm running freeradius 1.0.5 on freebsd 5.4. We handle about 75,000 logins per day between 3 servers and are using openldap as a backend, which stores about 400,000 users. We use radrelay to push all the accounting into a mysql db.
Can you comment on the accounting record rate that you're achieving? We're currently testing FreeRadius and I'm seeing a performance ceiling of about 200 accounting records per second.
Matthew.
I will have to take a look tomorrow to see what kind of data is coming in. But, I will let you know the architecture I am using, in case it interests you. Our billing system pulls from our accounting database periodically, so we don't need real-time information on all our accounting records. We have three main radius servers. We setup each of the radius servers to log all accounting to a detail file and we then use radrelay to push the data to our sql servers. This makes the accounting part of our AAA much quicker between the NAS and the radius server. The radius server just has to log it to a file and move on, so the accounting response comes very quickly. This is especially apparent during high loads as we don't need to wait for an sql resource to come available. The sql servers are two mysql 4.1 servers on freebsd 5.4. They are running in a multi-master setup. The two servers share an IP with CARP, which is built into freebsd. CARP will setup one server as the master and that server will answer all ARP requests for that IP. If the interface goes down (or if carp is shutdown by script/manual invervention), then the other machine will automatically take over that IP and then become the master sql server. The whole point of this setup is for reliability of our data rather than availability of the sql server. If one of the sql servers goes down, the other will take over the master role. When the dead server comes back up, it will assume the slave role and will update itself to be current with the master or we can manually update it if we wish. If both sql servers go down, or a small transition time between switching masters, or perhaps the radius load is just too high to accept all the requests we are getting, then the detail file on the radius servers will begin to grow. When the radius accounting server comes back up or the packets coming in slow down to an rate lower than the sql server can accept it, radrelay will then catch up the accounting server. We do occassionally see times where there was too much data coming in at once and the accounting server will post warnings to the log file and the detail files will begin to grow. However, its never been more than a few minutes and radrelay quickly catches the servers back up to date when the rates return to a lower level. Our authentication structure is quite different as we are looking more for availability. But in the accounting world, we can afford to delay the records if needed. I'll take a look at the data coming in tomorrow and let you know what kind of numbers we are seeing. If you'd like I can also send you any information you'd like about CARP or our mysql setup. I've also tested using another method which we chose not to implement. With this method I setup the accounting in a configurable-failover scenario. First we would send the accounting data directly to the sql server. If that failed, then the data would be populated into the detail file to quickly return an accounting response and radrelay would pick it up and deliver to the accounting server when it can. This worked quite well, but we chose to go with just radrelay instead. By doing just radrelay we could make the radius accounting server open up a large number of connections to itself vs spreading out the connection pool among our main radius servers. Hope that is helpful. -Dusty
Dusty Doris <freeradius@mail.doris.cc> wrote:
Our authentication structure is quite different as we are looking more for availability. But in the accounting world, we can afford to delay the records if needed.
That's a great description. It should be a "howto", or whitepaper. In the CVS head, "rlm_sql_log" does something similar, with explanations that may not be as detailed. Alan DeKok.
Can you point me to the explanation, i cant find it? --On Wednesday, November 09, 2005 01:23:22 AM -0500 Alan DeKok <aland@ox.org> wrote:
Dusty Doris <freeradius@mail.doris.cc> wrote:
Our authentication structure is quite different as we are looking more for availability. But in the accounting world, we can afford to delay the records if needed.
That's a great description. It should be a "howto", or whitepaper.
In the CVS head, "rlm_sql_log" does something similar, with explanations that may not be as detailed.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
christian meutes <christian.meutes@de.clara.net> wrote:
Can you point me to the explanation, i cant find it?
http://www.freeradius.org/cgi-bin/cvsweb.cgi/radiusd/man/man5/rlm_sql_log.5?... Alan DeKok.
Hi Dusty,
We have three main radius servers. We setup each of the radius servers to log all accounting to a detail file and we then use radrelay to push the data to our sql servers. This makes the accounting part of our AAA much quicker between the NAS and the radius server. The radius server just has to log it to a file and move on, so the accounting response comes very quickly. This is especially apparent during high loads as we don't need to wait for an sql resource to come available.
Thanks for the advice. I've found that the performance problem goes away when I test with interim accounting records instead of start records. I haven't figured out why start records generate such a performance hit. Any ideas? We're currently looking at radrelay. That sounds like a good idea. Matthew.
Thanks for the advice.
Didn't get a change to get good numbers for you today, but here is at least something. I took a look at our records for today and we have about 70,000 entries, with only 1500 of them without a stop yet. I can't get a good estimate at packets right now because I'm not sure how many updates we receive. But if I were to take a guess and say there is 1 update per user session (very rough guess), then that puts us at about 210,000 packets in 24 hours with 1 start, 1 update, and 1 stop. That makes our average about 2.5/second. Now, there are probably at least a few more than 1 update, so that number could be a bit higher. Also, our usage definately has big peaks during certain times of the day. But, I'd guess that we don't hit much more than 20-30/second during those peaks.
I've found that the performance problem goes away when I test with interim accounting records instead of start records.
I haven't figured out why start records generate such a performance hit. Any ideas?
That seems odd to me. I don't have any ideas on that, looking at the queries in sql.conf it seems to me that the accounting start should be faster since it begins with just a plain insert vs the update starting with an update that contains a where clause. Do you have a my.cnf file tuning that db? I can't explain update vs insert, but it could help with performance. Did you tweak sql.conf or radiusd.conf either? Perhaps you could try adjusting the num_sql_socks and connection_failure_retry_delay numbers in sql.conf and the thread pool section of radiusd.conf. Also, you can do many other things to help especially turning off radutmp. I'd also comment out any other modules that aren't used. Actually read tuning_guide in the doc dir, there are some good comments there. Also, remember that the sql performance is going to be primarily dependant on your configuration vs freeradius in general. For example, the CPU, disk speed, ram, etc.. will have more of an influence than anything else.
We're currently looking at radrelay. That sounds like a good idea.
Its been working great for us. However, in the CVS head they now have sqlrelay which I'd definately considering taking a look at. It does the same thing as radrelay, but sends over sql queries to your db instead of radius packets. Might be nice to not have to worry about an additional process (radiusd) on your sql servers. I'll test it out one of these days if I ever get some spare time. -Dusty
Matthew Horoschun <matthew@telstra.net> wrote:
Can you comment on the accounting record rate that you're achieving? We're currently testing FreeRadius and I'm seeing a performance ceiling of about 200 accounting records per second.
That's really a function of the back-end database. If you have a slow database, accounting will be slow. In my tests, logging to "detail", FreeRADIUS easily handles 1000's of accounting packets per second. So the difference between 1000s/s, and 200/s is the difference between local files & external DB. Alan DeKok.
participants (6)
-
Alan DeKok -
christian meutes -
Dusty Doris -
Matthew Horoschun -
Miguel -
Roy Hooper