hi, in another day I posted this same error ' Error: Discarding duplicate request from client ' and the answer was 'your database is slow' so I upgrade my server with more memory, and changed servers variables... but, i'm still having this problem and I dont know what can be -- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD
Hi, This question has been answered many times on this ML. I myself have (at least tried) answered it two times. Here're some of my previous messages: Msg1: Hi, I've already tried to answer a similar question some time ago (and I'm probably not the only one) but anyways... The cause of the problems probably is some delay or packet loss or something like that. Notice the Acct-Delay-Time value increasing as the NAS retries to send the "lost" accounting packet (although - at least in my case - it wasn't lost but just its processing was delayed). I've experienced such issues with Cisco VoIP routers - the router's log is flooded with RADIUS Server DEAD - and then ... ALIVE messages and in the FR log you can see the retries with the values of Acct-Delay-Time increasing. The main cause of the problem may be different, so you'll have to check it in your case. In my case it was caused by the thread pool settings not being appropriate for the load. In this case the CPU usage stays low but it's not used because you cannot achieve good concurrency and request have to await each other to finish. So find the main cause for your problems and eliminate it. The other thing is that most NASs have options to configure the RADIUS timeout, dead, retransmit etc times. E.g.for Cisco you could try "radius-server retransmit 0". Msg2: Hi, As far as I can see, the people on the list have provided you with a lot of very useful suggestions on what could cause the problem. As I said earlier (let me clarify) and to help you narrow things a little bit - it's probably due to the RADIUS response timing out hence the NAS complains the server is dead and later when it responds finally it marks it as alive again. The reasons can be different depending on your setup - slow network, database, custom module (like rlm_perl/ python etc) or as I suggested (from my personal experiences) improperly configured concurrence settings of FR itself. See which component of your setup is causing the slow responds (it can be the backend, or messed up FR configuration) and fix it. Just for completeness check your NASs manuals - most have these settings configurable - response timeouts, retransmits, marking the server as dead etc but playing with the NAS while possibly useful is probably not the main issue in your setup - check what is slowing things down. Msg3: Hi there, I may be mistaken but... these are log message on the NAS aren't they? If this is the case, I've experienced similar behavior with Cisco VoIP routers (RADIUS Server DEAD and then... ALIVE). This happens if you haven't properly enabled concurrency in FreeRADIUS - the CPU usage stays low 0%-1%-2% but if the requests are many they are obviously waiting each other... This happens when you have stared FreeRADIUS with the -X key (I think it starts with a single thread then) or have too low values for the thread pool parameters (and/or the *_clones options of rlm_perl which are to be deprecated soon). If you configure proper values according to the expected usage (concurrent requests), then the request won't wait each other to finish while the CPU stays unused and you'll avoid this annoying message in your logs. A sure sing that something like that is going on is the Acct-Delay-Time parameter with values greater than 0 - that is for accounting not sure for auth etc. Anyways if the values of that parameter are high (they are in seconds I think) then the requests are waiting too long and hence the error messages. Bottom line: 1) Check the ML for more info 2) The NAS can be configured when to timeout and resend the RADIUS packages 3) Something is slowing down your setup. It may be the DB or something else. If your CPU usage stays low (< 5%), check your thread pool settings and increase them to achieve better concurrency. Sincerely, Borislav Dimitrov e-mail: b.dimitrov@ngsystems.net GSM: 0888 51 55 45; 0889 28 54 57 NG Systems Lavele 32 str, fl: 4, Sofia, Bulgaria On 23.12.2009, at 15:10, Alisson wrote:
hi, in another day I posted this same error ' Error: Discarding duplicate request from client '
and the answer was 'your database is slow'
so I upgrade my server with more memory, and changed servers variables...
but, i'm still having this problem
and I dont know what can be
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
hi, my DB is ok I tested with another programms e etc, and is running well how I set the thread pool to better concurrency? 2009/12/23 Borislav Dimitrov <b.dimitrov@ngsystems.net>
Hi,
This question has been answered many times on this ML. I myself have (at least tried) answered it two times. Here're some of my previous messages:
Msg1: Hi,
I've already tried to answer a similar question some time ago (and I'm probably not the only one) but anyways... The cause of the problems probably is some delay or packet loss or something like that. Notice the Acct-Delay-Time value increasing as the NAS retries to send the "lost" accounting packet (although - at least in my case - it wasn't lost but just its processing was delayed). I've experienced such issues with Cisco VoIP routers - the router's log is flooded with RADIUS Server DEAD - and then ... ALIVE messages and in the FR log you can see the retries with the values of Acct-Delay-Time increasing. The main cause of the problem may be different, so you'll have to check it in your case. In my case it was caused by the thread pool settings not being appropriate for the load. In this case the CPU usage stays low but it's not used because you cannot achieve good concurrency and request have to await each other to finish. So find the main cause for your problems and eliminate it. The other thing is that most NASs have options to configure the RADIUS timeout, dead, retransmit etc times. E.g.for Cisco you could try "radius-server retransmit 0".
Msg2: Hi,
As far as I can see, the people on the list have provided you with a lot of very useful suggestions on what could cause the problem. As I said earlier (let me clarify) and to help you narrow things a little bit - it's probably due to the RADIUS response timing out hence the NAS complains the server is dead and later when it responds finally it marks it as alive again. The reasons can be different depending on your setup - slow network, database, custom module (like rlm_perl/python etc) or as I suggested (from my personal experiences) improperly configured concurrence settings of FR itself. See which component of your setup is causing the slow responds (it can be the backend, or messed up FR configuration) and fix it. Just for completeness check your NASs manuals - most have these settings configurable - response timeouts, retransmits, marking the server as dead etc but playing with the NAS while possibly useful is probably not the main issue in your setup - check what is slowing things down.
Msg3: Hi there,
I may be mistaken but... these are log message on the NAS aren't they? If this is the case, I've experienced similar behavior with Cisco VoIP routers (RADIUS Server DEAD and then... ALIVE). This happens if you haven't properly enabled concurrency in FreeRADIUS - the CPU usage stays low 0%-1%-2% but if the requests are many they are obviously waiting each other... This happens when you have stared FreeRADIUS with the -X key (I think it starts with a single thread then) or have too low values for the thread pool parameters (and/or the *_clones options of rlm_perl which are to be deprecated soon). If you configure proper values according to the expected usage (concurrent requests), then the request won't wait each other to finish while the CPU stays unused and you'll avoid this annoying message in your logs. A sure sing that something like that is going on is the Acct-Delay-Time parameter with values greater than 0 - that is for accounting not sure for auth etc. Anyways if the values of that parameter are high (they are in seconds I think) then the requests are waiting too long and hence the error messages.
Bottom line: 1) Check the ML for more info 2) The NAS can be configured when to timeout and resend the RADIUS packages 3) Something is slowing down your setup. It may be the DB or something else. If your CPU usage stays low (< 5%), check your thread pool settings and increase them to achieve better concurrency.
Sincerely,
Borislav Dimitrov e-mail: b.dimitrov@ngsystems.net GSM: 0888 51 55 45; 0889 28 54 57 NG Systems Lavele 32 str, fl: 4, Sofia, Bulgaria
On 23.12.2009, at 15:10, Alisson wrote:
hi, in another day I posted this same error ' Error: Discarding duplicate
request from client '
and the answer was 'your database is slow'
so I upgrade my server with more memory, and changed servers variables...
but, i'm still having this problem
and I dont know what can be
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD
In radiusd.conf: # THREAD POOL CONFIGURATION thread pool { start_servers = 1 max_servers = 1 min_spare_servers = 1 max_spare_servers = 1 max_requests_per_server = 0 } ...but instead of ones (1s) put something more appropriate for your network usage (like 5s or 7s). It's similar to Apache's thread pool settings... Stay monitoring and tuning until the error discarding duplicate packet disappears or becomes very rare. Also look at the Acct-Delay-Time parameter returned from the NAS to FR. It should be 0. If it's more than 0, then there's some delay. When you increase you thread pool settings the CPU usage will start increasing as FR starts processing more requests simultaneously/concurrently. Also check your NAS documentation for configuration options of these timeout etc parameters. For Cisco they are like that:
"radius-server retransmit 0" etc
С поздрави Борислав Димитров e-mail: b.dimitrov@ngsystems.net GSM: 0888 51 55 45; 0889 28 54 57 NG Systems Лавеле 32, ет: 4, София, България On 23.12.2009, at 15:36, Alisson wrote:
hi, my DB is ok I tested with another programms e etc, and is running well
how I set the thread pool to better concurrency?
2009/12/23 Borislav Dimitrov <b.dimitrov@ngsystems.net> Hi,
This question has been answered many times on this ML. I myself have (at least tried) answered it two times. Here're some of my previous messages:
Msg1: Hi,
I've already tried to answer a similar question some time ago (and I'm probably not the only one) but anyways... The cause of the problems probably is some delay or packet loss or something like that. Notice the Acct-Delay-Time value increasing as the NAS retries to send the "lost" accounting packet (although - at least in my case - it wasn't lost but just its processing was delayed). I've experienced such issues with Cisco VoIP routers - the router's log is flooded with RADIUS Server DEAD - and then ... ALIVE messages and in the FR log you can see the retries with the values of Acct-Delay-Time increasing. The main cause of the problem may be different, so you'll have to check it in your case. In my case it was caused by the thread pool settings not being appropriate for the load. In this case the CPU usage stays low but it's not used because you cannot achieve good concurrency and request have to await each other to finish. So find the main cause for your problems and eliminate it. The other thing is that most NASs have options to configure the RADIUS timeout, dead, retransmit etc times. E.g.for Cisco you could try "radius-server retransmit 0".
Msg2: Hi,
As far as I can see, the people on the list have provided you with a lot of very useful suggestions on what could cause the problem. As I said earlier (let me clarify) and to help you narrow things a little bit - it's probably due to the RADIUS response timing out hence the NAS complains the server is dead and later when it responds finally it marks it as alive again. The reasons can be different depending on your setup - slow network, database, custom module (like rlm_perl/ python etc) or as I suggested (from my personal experiences) improperly configured concurrence settings of FR itself. See which component of your setup is causing the slow responds (it can be the backend, or messed up FR configuration) and fix it. Just for completeness check your NASs manuals - most have these settings configurable - response timeouts, retransmits, marking the server as dead etc but playing with the NAS while possibly useful is probably not the main issue in your setup - check what is slowing things down.
Msg3: Hi there,
I may be mistaken but... these are log message on the NAS aren't they? If this is the case, I've experienced similar behavior with Cisco VoIP routers (RADIUS Server DEAD and then... ALIVE). This happens if you haven't properly enabled concurrency in FreeRADIUS - the CPU usage stays low 0%-1%-2% but if the requests are many they are obviously waiting each other... This happens when you have stared FreeRADIUS with the -X key (I think it starts with a single thread then) or have too low values for the thread pool parameters (and/or the *_clones options of rlm_perl which are to be deprecated soon). If you configure proper values according to the expected usage (concurrent requests), then the request won't wait each other to finish while the CPU stays unused and you'll avoid this annoying message in your logs. A sure sing that something like that is going on is the Acct-Delay-Time parameter with values greater than 0 - that is for accounting not sure for auth etc. Anyways if the values of that parameter are high (they are in seconds I think) then the requests are waiting too long and hence the error messages.
Bottom line: 1) Check the ML for more info 2) The NAS can be configured when to timeout and resend the RADIUS packages 3) Something is slowing down your setup. It may be the DB or something else. If your CPU usage stays low (< 5%), check your thread pool settings and increase them to achieve better concurrency.
Sincerely,
Borislav Dimitrov e-mail: b.dimitrov@ngsystems.net GSM: 0888 51 55 45; 0889 28 54 57 NG Systems Lavele 32 str, fl: 4, Sofia, Bulgaria
On 23.12.2009, at 15:10, Alisson wrote:
hi, in another day I posted this same error ' Error: Discarding duplicate request from client '
and the answer was 'your database is slow'
so I upgrade my server with more memory, and changed servers variables...
but, i'm still having this problem
and I dont know what can be
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Just to add that I hope that you are starting FR without the debug flag/option (i.e. without -X). When started like that (radiusd -X &) it starts in a single thread and obviously the requests will await each other to finish... С поздрави Борислав Димитров e-mail: b.dimitrov@ngsystems.net GSM: 0888 51 55 45; 0889 28 54 57 NG Systems Лавеле 32, ет: 4, София, България On 23.12.2009, at 15:43, Borislav Dimitrov wrote:
In radiusd.conf:
# THREAD POOL CONFIGURATION thread pool { start_servers = 1 max_servers = 1 min_spare_servers = 1 max_spare_servers = 1 max_requests_per_server = 0 }
...but instead of ones (1s) put something more appropriate for your network usage (like 5s or 7s). It's similar to Apache's thread pool settings... Stay monitoring and tuning until the error discarding duplicate packet disappears or becomes very rare. Also look at the Acct-Delay-Time parameter returned from the NAS to FR. It should be 0. If it's more than 0, then there's some delay. When you increase you thread pool settings the CPU usage will start increasing as FR starts processing more requests simultaneously/concurrently. Also check your NAS documentation for configuration options of these timeout etc parameters. For Cisco they are like that:
"radius-server retransmit 0" etc
С поздÑави
ÐоÑиÑлав ÐимиÑÑов e-mail: b.dimitrov@ngsystems.net GSM: 0888 51 55 45; 0889 28 54 57 NG Systems Ðавеле 32, еÑ: 4, СоÑиÑ, ÐÑлгаÑиÑ
On 23.12.2009, at 15:36, Alisson wrote:
hi, my DB is ok I tested with another programms e etc, and is running well
how I set the thread pool to better concurrency?
2009/12/23 Borislav Dimitrov <b.dimitrov@ngsystems.net> Hi,
This question has been answered many times on this ML. I myself have (at least tried) answered it two times. Here're some of my previous messages:
Msg1: Hi,
I've already tried to answer a similar question some time ago (and I'm probably not the only one) but anyways... The cause of the problems probably is some delay or packet loss or something like that. Notice the Acct-Delay-Time value increasing as the NAS retries to send the "lost" accounting packet (although - at least in my case - it wasn't lost but just its processing was delayed). I've experienced such issues with Cisco VoIP routers - the router's log is flooded with RADIUS Server DEAD - and then ... ALIVE messages and in the FR log you can see the retries with the values of Acct-Delay-Time increasing. The main cause of the problem may be different, so you'll have to check it in your case. In my case it was caused by the thread pool settings not being appropriate for the load. In this case the CPU usage stays low but it's not used because you cannot achieve good concurrency and request have to await each other to finish. So find the main cause for your problems and eliminate it. The other thing is that most NASs have options to configure the RADIUS timeout, dead, retransmit etc times. E.g.for Cisco you could try "radius-server retransmit 0".
Msg2: Hi,
As far as I can see, the people on the list have provided you with a lot of very useful suggestions on what could cause the problem. As I said earlier (let me clarify) and to help you narrow things a little bit - it's probably due to the RADIUS response timing out hence the NAS complains the server is dead and later when it responds finally it marks it as alive again. The reasons can be different depending on your setup - slow network, database, custom module (like rlm_perl/python etc) or as I suggested (from my personal experiences) improperly configured concurrence settings of FR itself. See which component of your setup is causing the slow responds (it can be the backend, or messed up FR configuration) and fix it. Just for completeness check your NASs manuals - most have these settings configurable - response timeouts, retransmits, marking the server as dead etc but playing with the NAS while possibly useful is probably not the main issue in your setup - check what is slowing things down.
Msg3: Hi there,
I may be mistaken but... these are log message on the NAS aren't they? If this is the case, I've experienced similar behavior with Cisco VoIP routers (RADIUS Server DEAD and then... ALIVE). This happens if you haven't properly enabled concurrency in FreeRADIUS - the CPU usage stays low 0%-1%-2% but if the requests are many they are obviously waiting each other... This happens when you have stared FreeRADIUS with the -X key (I think it starts with a single thread then) or have too low values for the thread pool parameters (and/or the *_clones options of rlm_perl which are to be deprecated soon). If you configure proper values according to the expected usage (concurrent requests), then the request won't wait each other to finish while the CPU stays unused and you'll avoid this annoying message in your logs. A sure sing that something like that is going on is the Acct-Delay-Time parameter with values greater than 0 - that is for accounting not sure for auth etc. Anyways if the values of that parameter are high (they are in seconds I think) then the requests are waiting too long and hence the error messages.
Bottom line: 1) Check the ML for more info 2) The NAS can be configured when to timeout and resend the RADIUS packages 3) Something is slowing down your setup. It may be the DB or something else. If your CPU usage stays low (< 5%), check your thread pool settings and increase them to achieve better concurrency.
Sincerely,
Borislav Dimitrov e-mail: b.dimitrov@ngsystems.net GSM: 0888 51 55 45; 0889 28 54 57 NG Systems Lavele 32 str, fl: 4, Sofia, Bulgaria
On 23.12.2009, at 15:10, Alisson wrote:
hi, in another day I posted this same error ' Error: Discarding duplicate request from client '
and the answer was 'your database is slow'
so I upgrade my server with more memory, and changed servers variables...
but, i'm still having this problem
and I dont know what can be
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
ok.. look I have 3500 customers authenticating on this server with mysql how many threads I need to set? thread pool { start_servers = 1 max_servers = 1 min_spare_servers = 1 max_spare_servers = 1 max_requests_per_server = 0 } 2009/12/23 Borislav Dimitrov <b.dimitrov@ngsystems.net>
Just to add that I hope that you are starting FR without the debug flag/option (i.e. without -X). When started like that (radiusd -X &) it starts in a single thread and obviously the requests will await each other to finish...
С поздрави
Борислав Димитров e-mail: b.dimitrov@ngsystems.net GSM: 0888 51 55 45; 0889 28 54 57 NG Systems Лавеле 32, ет: 4, София, България
On 23.12.2009, at 15:43, Borislav Dimitrov wrote:
In radiusd.conf:
# THREAD POOL CONFIGURATION thread pool { start_servers = 1 max_servers = 1 min_spare_servers = 1 max_spare_servers = 1 max_requests_per_server = 0 }
...but instead of ones (1s) put something more appropriate for your network usage (like 5s or 7s). It's similar to Apache's thread pool settings... Stay monitoring and tuning until the error discarding duplicate packet disappears or becomes very rare. Also look at the Acct-Delay-Time parameter returned from the NAS to FR. It should be 0. If it's more than 0, then there's some delay. When you increase you thread pool settings the CPU usage will start increasing as FR starts processing more requests simultaneously/concurrently. Also check your NAS documentation for configuration options of these timeout etc parameters. For Cisco they are like that:
"radius-server retransmit 0" etc
С поздрави
Ð‘Ð¾Ñ€Ð¸Ñ Ð»Ð°Ð² Димитров e-mail: b.dimitrov@ngsystems.net GSM: 0888 51 55 45; 0889 28 54 57 NG Systems Лавеле 32, ет: 4, Ð¡Ð¾Ñ„Ð¸Ñ , БългариÑ
On 23.12.2009, at 15:36, Alisson wrote:
hi, my DB is ok I tested with another programms e etc, and is running well
how I set the thread pool to better concurrency?
2009/12/23 Borislav Dimitrov <b.dimitrov@ngsystems.net>
Hi,
This question has been answered many times on this ML. I myself have (at least tried) answered it two times. Here're some of my previous messages:
Msg1: Hi,
I've already tried to answer a similar question some time ago (and I'm probably not the only one) but anyways... The cause of the problems probably is some delay or packet loss or something like that. Notice the Acct-Delay-Time value increasing as the NAS retries to send the "lost" accounting packet (although - at least in my case - it wasn't lost but just its processing was delayed). I've experienced such issues with Cisco VoIP routers - the router's log is flooded with RADIUS Server DEAD - and then ... ALIVE messages and in the FR log you can see the retries with the values of Acct-Delay-Time increasing. The main cause of the problem may be different, so you'll have to check it in your case. In my case it was caused by the thread pool settings not being appropriate for the load. In this case the CPU usage stays low but it's not used because you cannot achieve good concurrency and request have to await each other to finish. So find the main cause for your problems and eliminate it. The other thing is that most NASs have options to configure the RADIUS timeout, dead, retransmit etc times. E.g.for Cisco you could try "radius-server retransmit 0".
Msg2: Hi,
As far as I can see, the people on the list have provided you with a lot of very useful suggestions on what could cause the problem. As I said earlier (let me clarify) and to help you narrow things a little bit - it's probably due to the RADIUS response timing out hence the NAS complains the server is dead and later when it responds finally it marks it as alive again. The reasons can be different depending on your setup - slow network, database, custom module (like rlm_perl/python etc) or as I suggested (from my personal experiences) improperly configured concurrence settings of FR itself. See which component of your setup is causing the slow responds (it can be the backend, or messed up FR configuration) and fix it. Just for completeness check your NASs manuals - most have these settings configurable - response timeouts, retransmits, marking the server as dead etc but playing with the NAS while possibly useful is probably not the main issue in your setup - check what is slowing things down.
Msg3: Hi there,
I may be mistaken but... these are log message on the NAS aren't they? If this is the case, I've experienced similar behavior with Cisco VoIP routers (RADIUS Server DEAD and then... ALIVE). This happens if you haven't properly enabled concurrency in FreeRADIUS - the CPU usage stays low 0%-1%-2% but if the requests are many they are obviously waiting each other... This happens when you have stared FreeRADIUS with the -X key (I think it starts with a single thread then) or have too low values for the thread pool parameters (and/or the *_clones options of rlm_perl which are to be deprecated soon). If you configure proper values according to the expected usage (concurrent requests), then the request won't wait each other to finish while the CPU stays unused and you'll avoid this annoying message in your logs. A sure sing that something like that is going on is the Acct-Delay-Time parameter with values greater than 0 - that is for accounting not sure for auth etc. Anyways if the values of that parameter are high (they are in seconds I think) then the requests are waiting too long and hence the error messages.
Bottom line: 1) Check the ML for more info 2) The NAS can be configured when to timeout and resend the RADIUS packages 3) Something is slowing down your setup. It may be the DB or something else. If your CPU usage stays low (< 5%), check your thread pool settings and increase them to achieve better concurrency.
Sincerely,
Borislav Dimitrov e-mail: b.dimitrov@ngsystems.net GSM: 0888 51 55 45; 0889 28 54 57 NG Systems Lavele 32 str, fl: 4, Sofia, Bulgaria
On 23.12.2009, at 15:10, Alisson wrote:
hi, in another day I posted this same error ' Error: Discarding duplicate
request from client '
and the answer was 'your database is slow'
so I upgrade my server with more memory, and changed servers variables...
but, i'm still having this problem
and I dont know what can be
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD
my configuration is thread pool { start_servers = 10 max_servers = 32 min_spare_servers = 3 max_spare_servers = 10 max_requests_per_server = 0 } 2009/12/23 Alisson <alissonfer@gmail.com>
ok..
look I have 3500 customers authenticating on this server with mysql
how many threads I need to set?
thread pool { start_servers = 1 max_servers = 1 min_spare_servers = 1 max_spare_servers = 1 max_requests_per_server = 0 }
2009/12/23 Borislav Dimitrov <b.dimitrov@ngsystems.net>
Just to add that I hope that you are starting FR without the debug flag/option (i.e. without -X). When started like that (radiusd -X &) it starts in a single thread and obviously the requests will await each other to finish...
С поздрави
Борислав Димитров e-mail: b.dimitrov@ngsystems.net GSM: 0888 51 55 45; 0889 28 54 57 NG Systems Лавеле 32, ет: 4, София, България
On 23.12.2009, at 15:43, Borislav Dimitrov wrote:
In radiusd.conf:
# THREAD POOL CONFIGURATION thread pool { start_servers = 1 max_servers = 1 min_spare_servers = 1 max_spare_servers = 1 max_requests_per_server = 0 }
...but instead of ones (1s) put something more appropriate for your network usage (like 5s or 7s). It's similar to Apache's thread pool settings... Stay monitoring and tuning until the error discarding duplicate packet disappears or becomes very rare. Also look at the Acct-Delay-Time parameter returned from the NAS to FR. It should be 0. If it's more than 0, then there's some delay. When you increase you thread pool settings the CPU usage will start increasing as FR starts processing more requests simultaneously/concurrently. Also check your NAS documentation for configuration options of these timeout etc parameters. For Cisco they are like that:
"radius-server retransmit 0" etc
С поздрави
Ð‘Ð¾Ñ€Ð¸Ñ Ð»Ð°Ð² Димитров e-mail: b.dimitrov@ngsystems.net GSM: 0888 51 55 45; 0889 28 54 57 NG Systems Лавеле 32, ет: 4, Ð¡Ð¾Ñ„Ð¸Ñ , БългариÑ
On 23.12.2009, at 15:36, Alisson wrote:
hi, my DB is ok I tested with another programms e etc, and is running well
how I set the thread pool to better concurrency?
2009/12/23 Borislav Dimitrov <b.dimitrov@ngsystems.net>
Hi,
This question has been answered many times on this ML. I myself have (at least tried) answered it two times. Here're some of my previous messages:
Msg1: Hi,
I've already tried to answer a similar question some time ago (and I'm probably not the only one) but anyways... The cause of the problems probably is some delay or packet loss or something like that. Notice the Acct-Delay-Time value increasing as the NAS retries to send the "lost" accounting packet (although - at least in my case - it wasn't lost but just its processing was delayed). I've experienced such issues with Cisco VoIP routers - the router's log is flooded with RADIUS Server DEAD - and then ... ALIVE messages and in the FR log you can see the retries with the values of Acct-Delay-Time increasing. The main cause of the problem may be different, so you'll have to check it in your case. In my case it was caused by the thread pool settings not being appropriate for the load. In this case the CPU usage stays low but it's not used because you cannot achieve good concurrency and request have to await each other to finish. So find the main cause for your problems and eliminate it. The other thing is that most NASs have options to configure the RADIUS timeout, dead, retransmit etc times. E.g.for Cisco you could try "radius-server retransmit 0".
Msg2: Hi,
As far as I can see, the people on the list have provided you with a lot of very useful suggestions on what could cause the problem. As I said earlier (let me clarify) and to help you narrow things a little bit - it's probably due to the RADIUS response timing out hence the NAS complains the server is dead and later when it responds finally it marks it as alive again. The reasons can be different depending on your setup - slow network, database, custom module (like rlm_perl/python etc) or as I suggested (from my personal experiences) improperly configured concurrence settings of FR itself. See which component of your setup is causing the slow responds (it can be the backend, or messed up FR configuration) and fix it. Just for completeness check your NASs manuals - most have these settings configurable - response timeouts, retransmits, marking the server as dead etc but playing with the NAS while possibly useful is probably not the main issue in your setup - check what is slowing things down.
Msg3: Hi there,
I may be mistaken but... these are log message on the NAS aren't they? If this is the case, I've experienced similar behavior with Cisco VoIP routers (RADIUS Server DEAD and then... ALIVE). This happens if you haven't properly enabled concurrency in FreeRADIUS - the CPU usage stays low 0%-1%-2% but if the requests are many they are obviously waiting each other... This happens when you have stared FreeRADIUS with the -X key (I think it starts with a single thread then) or have too low values for the thread pool parameters (and/or the *_clones options of rlm_perl which are to be deprecated soon). If you configure proper values according to the expected usage (concurrent requests), then the request won't wait each other to finish while the CPU stays unused and you'll avoid this annoying message in your logs. A sure sing that something like that is going on is the Acct-Delay-Time parameter with values greater than 0 - that is for accounting not sure for auth etc. Anyways if the values of that parameter are high (they are in seconds I think) then the requests are waiting too long and hence the error messages.
Bottom line: 1) Check the ML for more info 2) The NAS can be configured when to timeout and resend the RADIUS packages 3) Something is slowing down your setup. It may be the DB or something else. If your CPU usage stays low (< 5%), check your thread pool settings and increase them to achieve better concurrency.
Sincerely,
Borislav Dimitrov e-mail: b.dimitrov@ngsystems.net GSM: 0888 51 55 45; 0889 28 54 57 NG Systems Lavele 32 str, fl: 4, Sofia, Bulgaria
On 23.12.2009, at 15:10, Alisson wrote:
hi, in another day I posted this same error ' Error: Discarding
duplicate request from client '
and the answer was 'your database is slow'
so I upgrade my server with more memory, and changed servers variables...
but, i'm still having this problem
and I dont know what can be
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD
It's difficult to say, but I'd say about 7 - 10... Try with something like that: thread pool { start_servers = 10 max_servers = 32 min_spare_servers = 3 max_spare_servers = 10 max_requests_per_server = 0 } I don't know what your setup is exactly but in some situations its advisable that you configure FR not to start and stop processes/ threads dynamically (e.g.if you have some heavy setup procedures that need to be executed on thread startup; e.g. if you have a custom rlm_perl module which loads lots of configuration from a DB on thread startup). I now saw you second message. The default settings should be good for about 3500 users and more. For VoIP accounting even less is OK. I'm starting to think that your problem is elsewhere... Does your CPU usage stay low? Have you created indexes in your DB? Is hostname_lookups = no? I find it difficult to guess what the problem is without knowing your setup but something is deffinitely slowing things down... FR is capable of managing many more than 3500 users on a commodity server when configured properly. Also check for general network delay packet loss etc... It's not normal the CPU usage to stay low while requests are queueing one after another to be processed... Sincerely, Borislav Dimitrov e-mail: b.dimitrov@ngsystems.net GSM: 0888 51 55 45; 0889 28 54 57 NG Systems Lavele 32 str, fl: 4, Sofia, Bulgaria On 23.12.2009, at 15:49, Alisson wrote:
ok..
look I have 3500 customers authenticating on this server with mysql
how many threads I need to set?
thread pool { start_servers = 1 max_servers = 1 min_spare_servers = 1 max_spare_servers = 1 max_requests_per_server = 0 }
2009/12/23 Borislav Dimitrov <b.dimitrov@ngsystems.net> Just to add that I hope that you are starting FR without the debug flag/option (i.e. without -X). When started like that (radiusd -X &) it starts in a single thread and obviously the requests will await each other to finish...
С поздрави
Борислав Димитров e-mail: b.dimitrov@ngsystems.net GSM: 0888 51 55 45; 0889 28 54 57 NG Systems Лавеле 32, ет: 4, София, България
On 23.12.2009, at 15:43, Borislav Dimitrov wrote:
In radiusd.conf:
# THREAD POOL CONFIGURATION thread pool { start_servers = 1 max_servers = 1 min_spare_servers = 1 max_spare_servers = 1 max_requests_per_server = 0 }
...but instead of ones (1s) put something more appropriate for your network usage (like 5s or 7s). It's similar to Apache's thread pool settings... Stay monitoring and tuning until the error discarding duplicate packet disappears or becomes very rare. Also look at the Acct-Delay-Time parameter returned from the NAS to FR. It should be 0. If it's more than 0, then there's some delay. When you increase you thread pool settings the CPU usage will start increasing as FR starts processing more requests simultaneously/concurrently. Also check your NAS documentation for configuration options of these timeout etc parameters. For Cisco they are like that:
"radius-server retransmit 0" etc
С поздрави
Ð‘Ð¾Ñ€Ð¸Ñ Ð»Ð°Ð² Димитров e-mail: b.dimitrov@ngsystems.net GSM: 0888 51 55 45; 0889 28 54 57 NG Systems Лавеле 32, ет: 4, Ð¡Ð¾Ñ„Ð¸Ñ , БългариÑ
On 23.12.2009, at 15:36, Alisson wrote:
hi, my DB is ok I tested with another programms e etc, and is running well
how I set the thread pool to better concurrency?
2009/12/23 Borislav Dimitrov <b.dimitrov@ngsystems.net> Hi,
This question has been answered many times on this ML. I myself have (at least tried) answered it two times. Here're some of my previous messages:
Msg1: Hi,
I've already tried to answer a similar question some time ago (and I'm probably not the only one) but anyways... The cause of the problems probably is some delay or packet loss or something like that. Notice the Acct-Delay-Time value increasing as the NAS retries to send the "lost" accounting packet (although - at least in my case - it wasn't lost but just its processing was delayed). I've experienced such issues with Cisco VoIP routers - the router's log is flooded with RADIUS Server DEAD - and then ... ALIVE messages and in the FR log you can see the retries with the values of Acct-Delay-Time increasing. The main cause of the problem may be different, so you'll have to check it in your case. In my case it was caused by the thread pool settings not being appropriate for the load. In this case the CPU usage stays low but it's not used because you cannot achieve good concurrency and request have to await each other to finish. So find the main cause for your problems and eliminate it. The other thing is that most NASs have options to configure the RADIUS timeout, dead, retransmit etc times. E.g.for Cisco you could try "radius-server retransmit 0".
Msg2: Hi,
As far as I can see, the people on the list have provided you with a lot of very useful suggestions on what could cause the problem. As I said earlier (let me clarify) and to help you narrow things a little bit - it's probably due to the RADIUS response timing out hence the NAS complains the server is dead and later when it responds finally it marks it as alive again. The reasons can be different depending on your setup - slow network, database, custom module (like rlm_perl/python etc) or as I suggested (from my personal experiences) improperly configured concurrence settings of FR itself. See which component of your setup is causing the slow responds (it can be the backend, or messed up FR configuration) and fix it. Just for completeness check your NASs manuals - most have these settings configurable - response timeouts, retransmits, marking the server as dead etc but playing with the NAS while possibly useful is probably not the main issue in your setup - check what is slowing things down.
Msg3: Hi there,
I may be mistaken but... these are log message on the NAS aren't they? If this is the case, I've experienced similar behavior with Cisco VoIP routers (RADIUS Server DEAD and then... ALIVE). This happens if you haven't properly enabled concurrency in FreeRADIUS - the CPU usage stays low 0%-1%-2% but if the requests are many they are obviously waiting each other... This happens when you have stared FreeRADIUS with the -X key (I think it starts with a single thread then) or have too low values for the thread pool parameters (and/ or the *_clones options of rlm_perl which are to be deprecated soon). If you configure proper values according to the expected usage (concurrent requests), then the request won't wait each other to finish while the CPU stays unused and you'll avoid this annoying message in your logs. A sure sing that something like that is going on is the Acct-Delay-Time parameter with values greater than 0 - that is for accounting not sure for auth etc. Anyways if the values of that parameter are high (they are in seconds I think) then the requests are waiting too long and hence the error messages.
Bottom line: 1) Check the ML for more info 2) The NAS can be configured when to timeout and resend the RADIUS packages 3) Something is slowing down your setup. It may be the DB or something else. If your CPU usage stays low (< 5%), check your thread pool settings and increase them to achieve better concurrency.
Sincerely,
Borislav Dimitrov e-mail: b.dimitrov@ngsystems.net GSM: 0888 51 55 45; 0889 28 54 57 NG Systems Lavele 32 str, fl: 4, Sofia, Bulgaria
On 23.12.2009, at 15:10, Alisson wrote:
hi, in another day I posted this same error ' Error: Discarding duplicate request from client '
and the answer was 'your database is slow'
so I upgrade my server with more memory, and changed servers variables...
but, i'm still having this problem
and I dont know what can be
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
i'm trying to solve this problem in six months this is my configuration thread pool { start_servers = 10 max_servers = 32 min_spare_servers = 3 max_spare_servers = 10 max_requests_per_server = 0 } what i can change ? upgrade start_servers? 2009/12/23 Borislav Dimitrov <b.dimitrov@ngsystems.net>
It's difficult to say, but I'd say about 7 - 10... Try with something like that: thread pool { start_servers = 10 max_servers = 32 min_spare_servers = 3 max_spare_servers = 10 max_requests_per_server = 0 }
I don't know what your setup is exactly but in some situations its advisable that you configure FR not to start and stop processes/threads dynamically (e.g.if you have some heavy setup procedures that need to be executed on thread startup; e.g. if you have a custom rlm_perl module which loads lots of configuration from a DB on thread startup). I now saw you second message. The default settings should be good for about 3500 users and more. For VoIP accounting even less is OK. I'm starting to think that your problem is elsewhere... Does your CPU usage stay low? Have you created indexes in your DB? Is hostname_lookups = no? I find it difficult to guess what the problem is without knowing your setup but something is deffinitely slowing things down... FR is capable of managing many more than 3500 users on a commodity server when configured properly. Also check for general network delay packet loss etc... It's not normal the CPU usage to stay low while requests are queueing one after another to be processed...
Sincerely,
Borislav Dimitrov e-mail: b.dimitrov@ngsystems.net GSM: 0888 51 55 45; 0889 28 54 57 NG Systems Lavele 32 str, fl: 4, Sofia, Bulgaria
On 23.12.2009, at 15:49, Alisson wrote:
ok..
look I have 3500 customers authenticating on this server with mysql
how many threads I need to set?
thread pool { start_servers = 1 max_servers = 1 min_spare_servers = 1 max_spare_servers = 1 max_requests_per_server = 0 }
2009/12/23 Borislav Dimitrov <b.dimitrov@ngsystems.net>
Just to add that I hope that you are starting FR without the debug flag/option (i.e. without -X). When started like that (radiusd -X &) it starts in a single thread and obviously the requests will await each other to finish...
С поздрави
Борислав Димитров e-mail: b.dimitrov@ngsystems.net GSM: 0888 51 55 45; 0889 28 54 57 NG Systems Лавеле 32, ет: 4, София, България
On 23.12.2009, at 15:43, Borislav Dimitrov wrote:
In radiusd.conf:
# THREAD POOL CONFIGURATION thread pool { start_servers = 1 max_servers = 1 min_spare_servers = 1 max_spare_servers = 1 max_requests_per_server = 0 }
...but instead of ones (1s) put something more appropriate for your network usage (like 5s or 7s). It's similar to Apache's thread pool settings... Stay monitoring and tuning until the error discarding duplicate packet disappears or becomes very rare. Also look at the Acct-Delay-Time parameter returned from the NAS to FR. It should be 0. If it's more than 0, then there's some delay. When you increase you thread pool settings the CPU usage will start increasing as FR starts processing more requests simultaneously/concurrently. Also check your NAS documentation for configuration options of these timeout etc parameters. For Cisco they are like that:
"radius-server retransmit 0" etc
С поздрави
Ð‘Ð¾Ñ€Ð¸Ñ Ð»Ð°Ð² Димитров e-mail: b.dimitrov@ngsystems.net GSM: 0888 51 55 45; 0889 28 54 57 NG Systems Лавеле 32, ет: 4, Ð¡Ð¾Ñ„Ð¸Ñ , БългариÑ
On 23.12.2009, at 15:36, Alisson wrote:
hi, my DB is ok I tested with another programms e etc, and is running well
how I set the thread pool to better concurrency?
2009/12/23 Borislav Dimitrov <b.dimitrov@ngsystems.net>
Hi,
This question has been answered many times on this ML. I myself have (at least tried) answered it two times. Here're some of my previous messages:
Msg1: Hi,
I've already tried to answer a similar question some time ago (and I'm probably not the only one) but anyways... The cause of the problems probably is some delay or packet loss or something like that. Notice the Acct-Delay-Time value increasing as the NAS retries to send the "lost" accounting packet (although - at least in my case - it wasn't lost but just its processing was delayed). I've experienced such issues with Cisco VoIP routers - the router's log is flooded with RADIUS Server DEAD - and then ... ALIVE messages and in the FR log you can see the retries with the values of Acct-Delay-Time increasing. The main cause of the problem may be different, so you'll have to check it in your case. In my case it was caused by the thread pool settings not being appropriate for the load. In this case the CPU usage stays low but it's not used because you cannot achieve good concurrency and request have to await each other to finish. So find the main cause for your problems and eliminate it. The other thing is that most NASs have options to configure the RADIUS timeout, dead, retransmit etc times. E.g.for Cisco you could try "radius-server retransmit 0".
Msg2: Hi,
As far as I can see, the people on the list have provided you with a lot of very useful suggestions on what could cause the problem. As I said earlier (let me clarify) and to help you narrow things a little bit - it's probably due to the RADIUS response timing out hence the NAS complains the server is dead and later when it responds finally it marks it as alive again. The reasons can be different depending on your setup - slow network, database, custom module (like rlm_perl/python etc) or as I suggested (from my personal experiences) improperly configured concurrence settings of FR itself. See which component of your setup is causing the slow responds (it can be the backend, or messed up FR configuration) and fix it. Just for completeness check your NASs manuals - most have these settings configurable - response timeouts, retransmits, marking the server as dead etc but playing with the NAS while possibly useful is probably not the main issue in your setup - check what is slowing things down.
Msg3: Hi there,
I may be mistaken but... these are log message on the NAS aren't they? If this is the case, I've experienced similar behavior with Cisco VoIP routers (RADIUS Server DEAD and then... ALIVE). This happens if you haven't properly enabled concurrency in FreeRADIUS - the CPU usage stays low 0%-1%-2% but if the requests are many they are obviously waiting each other... This happens when you have stared FreeRADIUS with the -X key (I think it starts with a single thread then) or have too low values for the thread pool parameters (and/or the *_clones options of rlm_perl which are to be deprecated soon). If you configure proper values according to the expected usage (concurrent requests), then the request won't wait each other to finish while the CPU stays unused and you'll avoid this annoying message in your logs. A sure sing that something like that is going on is the Acct-Delay-Time parameter with values greater than 0 - that is for accounting not sure for auth etc. Anyways if the values of that parameter are high (they are in seconds I think) then the requests are waiting too long and hence the error messages.
Bottom line: 1) Check the ML for more info 2) The NAS can be configured when to timeout and resend the RADIUS packages 3) Something is slowing down your setup. It may be the DB or something else. If your CPU usage stays low (< 5%), check your thread pool settings and increase them to achieve better concurrency.
Sincerely,
Borislav Dimitrov e-mail: b.dimitrov@ngsystems.net GSM: 0888 51 55 45; 0889 28 54 57 NG Systems Lavele 32 str, fl: 4, Sofia, Bulgaria
On 23.12.2009, at 15:10, Alisson wrote:
hi, in another day I posted this same error ' Error: Discarding
duplicate request from client '
and the answer was 'your database is slow'
so I upgrade my server with more memory, and changed servers variables...
but, i'm still having this problem
and I dont know what can be
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD
Hi,
i'm trying to solve this problem in six months
surely you've played with the right number of variables?
this is my configuration
hordses for courses - i could tell you my variables but then....well, they might not be appropriate for you. FWIW, if you get problems with MySQL then it wont be your thread issue - it'll be how slow and wrong your DB is!
thread pool { start_servers = 10 max_servers = 32 min_spare_servers = 3 max_spare_servers = 10 max_requests_per_server = 0 }
I have 64 start_servers, 64 max_servers, 64 spare servers - and the appropriate values in the perl modukle - but, i will say this again - it doesnt matter how many servers you clone and have available - your error message is coming from the SQL being too slow to respond - and if you chuck more servers at it, then it'll get even worse!!!! i cannot say this enough it seems . fix why your SQL is slow - or adjust the way you use the SQL. have you got the correct indexes? have you got too many indexes? are you usign mysql? if so, are you using naff default MyISAM or have you moved to a better method - eg InnoDB? alan
i'm using mysql 5.0, the tables used by freeradius are innodb, I have good indexes, my applications manipulate milions of register from radius.radaccts in a little time I don't have problem with slow db, but with radius a lot of time I have this problem 'discarding packet' I using a server core 2 duo, 2gb memory is dedicated to freeradius my mysql variables are working good 2009/12/23 Alan Buxey <A.L.M.Buxey@lboro.ac.uk>
Hi,
i'm trying to solve this problem in six months
surely you've played with the right number of variables?
this is my configuration
hordses for courses - i could tell you my variables but then....well, they might not be appropriate for you.
FWIW, if you get problems with MySQL then it wont be your thread issue - it'll be how slow and wrong your DB is!
thread pool { start_servers = 10 max_servers = 32 min_spare_servers = 3 max_spare_servers = 10 max_requests_per_server = 0 }
I have 64 start_servers, 64 max_servers, 64 spare servers - and the appropriate values in the perl modukle - but, i will say this again - it doesnt matter how many servers you clone and have available - your error message is coming from the SQL being too slow to respond - and if you chuck more servers at it, then it'll get even worse!!!!
i cannot say this enough it seems . fix why your SQL is slow - or adjust the way you use the SQL. have you got the correct indexes? have you got too many indexes? are you usign mysql? if so, are you using naff default MyISAM or have you moved to a better method - eg InnoDB?
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD
hi, i would say i disagree with your statements - but you wouldnt listen to me if the FR thread is stuck in MySQL land then it cannot answer other requests. hence its slow. disable any modules and calls to functions that you arent using. use other threads for dealing with SQL - and move themn to suitable places - eg post-auth for allocation of VLANs etc alan
ok, one last doubt... for 3500 customers what is a good configuration in radiusd.conf for this function thread pool { start_servers = 1 max_servers = 1 min_spare_servers = 1 max_spare_servers = 1 max_requests_per_server = 0 } 2009/12/23 Alan Buxey <A.L.M.Buxey@lboro.ac.uk>
hi,
i would say i disagree with your statements - but you wouldnt listen to me if the FR thread is stuck in MySQL land then it cannot answer other requests. hence its slow.
disable any modules and calls to functions that you arent using. use other threads for dealing with SQL - and move themn to suitable places - eg post-auth for allocation of VLANs etc
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD
Alisson wrote:
one last doubt...
for 3500 customers what is a good configuration in radiusd.conf
The default configuration.
for this function
thread pool { start_servers = 1 max_servers = 1 min_spare_servers = 1 max_spare_servers = 1 max_requests_per_server = 0 }
That is not the default configuration. You have changed the server to *slow it down*. Why? If this issue is so important for you, why are you so insistent on ignoring *all* help that you get on this list? A basic install of FreeRADIUS + MySQL on a normal system will get 100's of auth/s with 10's of 1000's of users in the DB. If you can't get that, it is because *you* have broken the configuration. Don't break the default configuration. Follow instructions on this list. It's really *not* that difficult to make the server work. *Stop* editing things you don't understand. All you need to do is to *stop* breaking the server. Alan DeKok.
you dont understood... i dont make this configuration i'm ask for help to do a good configuration based on between 3000 and 35000 conecctions to this function thread pool
thread pool { start_servers = 1 max_servers = 1 min_spare_servers = 1 max_spare_servers = 1 max_requests_per_server = 0 }
i need a help to configure this 2009/12/23 Alan DeKok <aland@deployingradius.com>
Alisson wrote:
one last doubt...
for 3500 customers what is a good configuration in radiusd.conf
The default configuration.
for this function
thread pool { start_servers = 1 max_servers = 1 min_spare_servers = 1 max_spare_servers = 1 max_requests_per_server = 0 }
That is not the default configuration.
You have changed the server to *slow it down*.
Why?
If this issue is so important for you, why are you so insistent on ignoring *all* help that you get on this list?
A basic install of FreeRADIUS + MySQL on a normal system will get 100's of auth/s with 10's of 1000's of users in the DB. If you can't get that, it is because *you* have broken the configuration.
Don't break the default configuration.
Follow instructions on this list.
It's really *not* that difficult to make the server work.
*Stop* editing things you don't understand.
All you need to do is to *stop* breaking the server.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD
Alisson wrote:
you dont understood... i dont make this configuration
i'm ask for help to do a good configuration based on between 3000 and 35000 conecctions to this function thread pool
You have been given a lot of help. This help has told you how to find out the cause of the problem, and how to resolve the underlying problem. You have failed to follow the help. Follow the help. Nothing else will solve the problem. Stop posting questions like "my system is slow, how do I fix it?" unless you plan on READING the answers, and FOLLOWING the instructions. Alan DeKok.
i'm reading and answering the questions i'm following everything that everybody is writing here... my questions is how to configure the pool thread with a good configuration for 3000 connections, only this. my hardware intel core 2 duo 2.56, 2 gb memory db mysql 5.0 i'm using this configuration thread pool { start_servers = 10 max_servers = 32 max_servers = 32 min_spare_servers = 3 max_spare_servers = 10 } 2009/12/23 Alan DeKok <aland@deployingradius.com>
Alisson wrote:
you dont understood... i dont make this configuration
i'm ask for help to do a good configuration based on between 3000 and 35000 conecctions to this function thread pool
You have been given a lot of help. This help has told you how to find out the cause of the problem, and how to resolve the underlying problem.
You have failed to follow the help.
Follow the help. Nothing else will solve the problem.
Stop posting questions like "my system is slow, how do I fix it?" unless you plan on READING the answers, and FOLLOWING the instructions.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD
Alisson wrote:
i'm reading and answering the questions
i'm following everything that everybody is writing here...
No.
my questions is how to configure the pool thread with a good configuration for 3000 connections, only this.
my hardware intel core 2 duo 2.56, 2 gb memory
db mysql 5.0
i'm using this configuration
You have now posted that information 10-15 times. The problem still isn't solved. This should be a hint to you that the information *isn't useful* for solving the problem. You have described *nothing* else about your system. Until you get past the mental block of "but it doesn't work", it will be impossible for anyone to help you. You have been told that the default configuration doesn't have this problem You have *not* said what you changed from the default configuration. You should try looking at that, rather than posting the same CPU / thread information over and over again. Alan DeKok.
Isn't there some guidelines in the conf files for these? Generally you want as few threads as possible to service the load. How volatile your connections are, are more important than the max number of possible connections, and only you know this. Perhaps start with 10 threads and monitor with top now and then. ________________________________ From: freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org [mailto:freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org] On Behalf Of Alisson Sent: Wednesday, December 23, 2009 1:11 PM To: FreeRadius users mailing list Subject: Re: error discarding packet you dont understood... i dont make this configuration i'm ask for help to do a good configuration based on between 3000 and 35000 conecctions to this function thread pool
thread pool { start_servers = 1 max_servers = 1 min_spare_servers = 1 max_spare_servers = 1 max_requests_per_server = 0 }
i need a help to configure this 2009/12/23 Alan DeKok <aland@deployingradius.com> Alisson wrote:
one last doubt...
for 3500 customers what is a good configuration in radiusd.conf
The default configuration.
for this function
thread pool { start_servers = 1 max_servers = 1 min_spare_servers = 1 max_spare_servers = 1 max_requests_per_server = 0 }
That is not the default configuration. You have changed the server to *slow it down*. Why? If this issue is so important for you, why are you so insistent on ignoring *all* help that you get on this list? A basic install of FreeRADIUS + MySQL on a normal system will get 100's of auth/s with 10's of 1000's of users in the DB. If you can't get that, it is because *you* have broken the configuration. Don't break the default configuration. Follow instructions on this list. It's really *not* that difficult to make the server work. *Stop* editing things you don't understand. All you need to do is to *stop* breaking the server. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD <font size="1"> <div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'> </div> "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." </font>
i'm using 15 threads and monitoring on top, the max server load is 2.0/3.0 2009/12/23 Gary Gatten <Ggatten@waddell.com>
Isn’t there some guidelines in the conf files for these? Generally you want as few threads as possible to service the load. How volatile your connections are, are more important than the max number of possible connections, and only you know this. Perhaps start with 10 threads and monitor with top now and then.
------------------------------
*From:* freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org[mailto: freeradius-users-bounces+ggatten <freeradius-users-bounces%2Bggatten>= waddell.com@lists.freeradius.org] *On Behalf Of *Alisson *Sent:* Wednesday, December 23, 2009 1:11 PM *To:* FreeRadius users mailing list *Subject:* Re: error discarding packet
you dont understood... i dont make this configuration
i'm ask for help to do a good configuration based on between 3000 and 35000 conecctions to this function thread pool
thread pool { start_servers = 1 max_servers = 1 min_spare_servers = 1 max_spare_servers = 1 max_requests_per_server = 0 }
i need a help to configure this
2009/12/23 Alan DeKok <aland@deployingradius.com>
Alisson wrote:
one last doubt...
for 3500 customers what is a good configuration in radiusd.conf
The default configuration.
for this function
thread pool { start_servers = 1 max_servers = 1 min_spare_servers = 1 max_spare_servers = 1 max_requests_per_server = 0 }
That is not the default configuration.
You have changed the server to *slow it down*.
Why?
If this issue is so important for you, why are you so insistent on ignoring *all* help that you get on this list?
A basic install of FreeRADIUS + MySQL on a normal system will get 100's of auth/s with 10's of 1000's of users in the DB. If you can't get that, it is because *you* have broken the configuration.
Don't break the default configuration.
Follow instructions on this list.
It's really *not* that difficult to make the server work.
*Stop* editing things you don't understand.
All you need to do is to *stop* breaking the server.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system."
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD
There are some switches in top (differ by platform) that will show you individual threads and their accumulated CPU time, current CPU util, etc. Such as: Top -p "YOUR-PID" -H. You MAY have to start the app (FR) in gdb to figure out what thread is doing what (sometimes the app will log when threads start and what they're doing - but sometimes not). A more seasoned SysAdmin may have an easier / better solution, but this method has proven invaluable to me when trying to troubleshoot multithreaded apps and determine which thread is using most memory, cpu, etc. and what functions that thread is doing. G ________________________________ From: freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org [mailto:freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org] On Behalf Of Alisson Sent: Wednesday, December 23, 2009 1:32 PM To: FreeRadius users mailing list Subject: Re: error discarding packet i'm using 15 threads and monitoring on top, the max server load is 2.0/3.0 2009/12/23 Gary Gatten <Ggatten@waddell.com> Isn't there some guidelines in the conf files for these? Generally you want as few threads as possible to service the load. How volatile your connections are, are more important than the max number of possible connections, and only you know this. Perhaps start with 10 threads and monitor with top now and then. ________________________________ From: freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org [mailto:freeradius-users-bounces+ggatten <mailto:freeradius-users-bounces%2Bggatten> =waddell.com@lists.freeradius.org] On Behalf Of Alisson Sent: Wednesday, December 23, 2009 1:11 PM To: FreeRadius users mailing list Subject: Re: error discarding packet you dont understood... i dont make this configuration i'm ask for help to do a good configuration based on between 3000 and 35000 conecctions to this function thread pool
thread pool { start_servers = 1 max_servers = 1 min_spare_servers = 1 max_spare_servers = 1 max_requests_per_server = 0 }
i need a help to configure this 2009/12/23 Alan DeKok <aland@deployingradius.com> Alisson wrote:
one last doubt...
for 3500 customers what is a good configuration in radiusd.conf
The default configuration.
for this function
thread pool { start_servers = 1 max_servers = 1 min_spare_servers = 1 max_spare_servers = 1 max_requests_per_server = 0 }
That is not the default configuration. You have changed the server to *slow it down*. Why? If this issue is so important for you, why are you so insistent on ignoring *all* help that you get on this list? A basic install of FreeRADIUS + MySQL on a normal system will get 100's of auth/s with 10's of 1000's of users in the DB. If you can't get that, it is because *you* have broken the configuration. Don't break the default configuration. Follow instructions on this list. It's really *not* that difficult to make the server work. *Stop* editing things you don't understand. All you need to do is to *stop* breaking the server. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD <font size="1"> <div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'> </div> "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." </font>
I run Top -P -H and it showed the threads, only 2 are working 2009/12/23 Gary Gatten <Ggatten@waddell.com>
There are some switches in top (differ by platform) that will show you individual threads and their accumulated CPU time, current CPU util, etc. Such as:
Top –p “YOUR-PID” –H. You MAY have to start the app (FR) in gdb to figure out what thread is doing what (sometimes the app will log when threads start and what they’re doing – but sometimes not). A more seasoned SysAdmin may have an easier / better solution, but this method has proven invaluable to me when trying to troubleshoot multithreaded apps and determine which thread is using most memory, cpu, etc. and what functions that thread is doing.
G
------------------------------
*From:* freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org[mailto: freeradius-users-bounces+ggatten <freeradius-users-bounces%2Bggatten>= waddell.com@lists.freeradius.org] *On Behalf Of *Alisson *Sent:* Wednesday, December 23, 2009 1:32 PM
*To:* FreeRadius users mailing list *Subject:* Re: error discarding packet
i'm using 15 threads and monitoring on top, the max server load is 2.0/3.0
2009/12/23 Gary Gatten <Ggatten@waddell.com>
Isn’t there some guidelines in the conf files for these? Generally you want as few threads as possible to service the load. How volatile your connections are, are more important than the max number of possible connections, and only you know this. Perhaps start with 10 threads and monitor with top now and then.
------------------------------
*From:* freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org[mailto: freeradius-users-bounces+ggatten <freeradius-users-bounces%2Bggatten>= waddell.com@lists.freeradius.org] *On Behalf Of *Alisson *Sent:* Wednesday, December 23, 2009 1:11 PM *To:* FreeRadius users mailing list *Subject:* Re: error discarding packet
you dont understood... i dont make this configuration
i'm ask for help to do a good configuration based on between 3000 and 35000 conecctions to this function thread pool
thread pool { start_servers = 1 max_servers = 1 min_spare_servers = 1 max_spare_servers = 1 max_requests_per_server = 0 }
i need a help to configure this
2009/12/23 Alan DeKok <aland@deployingradius.com>
Alisson wrote:
one last doubt...
for 3500 customers what is a good configuration in radiusd.conf
The default configuration.
for this function
thread pool { start_servers = 1 max_servers = 1 min_spare_servers = 1 max_spare_servers = 1 max_requests_per_server = 0 }
That is not the default configuration.
You have changed the server to *slow it down*.
Why?
If this issue is so important for you, why are you so insistent on ignoring *all* help that you get on this list?
A basic install of FreeRADIUS + MySQL on a normal system will get 100's of auth/s with 10's of 1000's of users in the DB. If you can't get that, it is because *you* have broken the configuration.
Don't break the default configuration.
Follow instructions on this list.
It's really *not* that difficult to make the server work.
*Stop* editing things you don't understand.
All you need to do is to *stop* breaking the server.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD
"This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system."
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system."
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD
I'm sure other threads are doing something - but take so little cpu time the low resolution counters don't catch it? What are these two threads? Probably SQL related? I missed the start of this thread, but seems some frustration is building. Without SQL FR is very fast. With SQL, who knows - way too many variables, especially if you're using prebuit packages and not compiling yourself? Compiling is a HASSLE, so I usually try to start with packages and if they work for me that's great. However, I typically find some feature I want to make use of that wasn't included in the package that "Bob" built, so I end up building/compiling with the appropriate configure args and such. If your system is "slow", you need to start at the beginning. Maybe something is wrong with the SQL config, disks, RAM, etc. Maybe SQL is not optimized? Many "maybe's"... If you haven't done much customizing, perhaps install apps with default configs to a different directory (use new SQL files too) and see if the slowness is present in the default configs. Try to keep things as simple as possible! Complicated CAN be fun, until it breaks! G ________________________________ From: freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org [mailto:freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org] On Behalf Of Alisson Sent: Wednesday, December 23, 2009 2:05 PM To: FreeRadius users mailing list Subject: Re: error discarding packet I run Top -P -H and it showed the threads, only 2 are working 2009/12/23 Gary Gatten <Ggatten@waddell.com> There are some switches in top (differ by platform) that will show you individual threads and their accumulated CPU time, current CPU util, etc. Such as: Top -p "YOUR-PID" -H. You MAY have to start the app (FR) in gdb to figure out what thread is doing what (sometimes the app will log when threads start and what they're doing - but sometimes not). A more seasoned SysAdmin may have an easier / better solution, but this method has proven invaluable to me when trying to troubleshoot multithreaded apps and determine which thread is using most memory, cpu, etc. and what functions that thread is doing. G ________________________________ From: freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org [mailto:freeradius-users-bounces+ggatten <mailto:freeradius-users-bounces%2Bggatten> =waddell.com@lists.freeradius.org] On Behalf Of Alisson Sent: Wednesday, December 23, 2009 1:32 PM To: FreeRadius users mailing list Subject: Re: error discarding packet i'm using 15 threads and monitoring on top, the max server load is 2.0/3.0 2009/12/23 Gary Gatten <Ggatten@waddell.com> Isn't there some guidelines in the conf files for these? Generally you want as few threads as possible to service the load. How volatile your connections are, are more important than the max number of possible connections, and only you know this. Perhaps start with 10 threads and monitor with top now and then. ________________________________ From: freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org [mailto:freeradius-users-bounces+ggatten <mailto:freeradius-users-bounces%2Bggatten> =waddell.com@lists.freeradius.org] On Behalf Of Alisson Sent: Wednesday, December 23, 2009 1:11 PM To: FreeRadius users mailing list Subject: Re: error discarding packet you dont understood... i dont make this configuration i'm ask for help to do a good configuration based on between 3000 and 35000 conecctions to this function thread pool
thread pool { start_servers = 1 max_servers = 1 min_spare_servers = 1 max_spare_servers = 1 max_requests_per_server = 0 }
i need a help to configure this 2009/12/23 Alan DeKok <aland@deployingradius.com> Alisson wrote:
one last doubt...
for 3500 customers what is a good configuration in radiusd.conf
The default configuration.
for this function
thread pool { start_servers = 1 max_servers = 1 min_spare_servers = 1 max_spare_servers = 1 max_requests_per_server = 0 }
That is not the default configuration. You have changed the server to *slow it down*. Why? If this issue is so important for you, why are you so insistent on ignoring *all* help that you get on this list? A basic install of FreeRADIUS + MySQL on a normal system will get 100's of auth/s with 10's of 1000's of users in the DB. If you can't get that, it is because *you* have broken the configuration. Don't break the default configuration. Follow instructions on this list. It's really *not* that difficult to make the server work. *Stop* editing things you don't understand. All you need to do is to *stop* breaking the server. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD <font size="1"> <div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'> </div> "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." </font>
Gary Gatten wrote:
I missed the start of this thread, but seems some frustration is building.
Q: How do I fix this problem? A: Here's how Q: How do I fix this problem? A: Here's how Q: But it's still not fixed, how do I fix it? A: <sigh> I understand the frustration of "but it doesn't work". The *source* of the frustration is usually: a) focusing on the problem, and not on how to solve it b) ignoring answers that try to help (If you think you're *not* ignoring the answers, believe us when we say that you are) c) not knowing how to give *additional* information that may allow others to narrow down the problem d) not knowing how to narrow down the problem yourself. By and large, the main difference between "experts" and "noobies" is *not* the memorization of large bodies of trivia. Yes, experience helps What helps *more* is a methodical approach to solving problems. A step-by-step approach beats a random approach every time. It also beats the approach of trying the same thing over and over again. Alan DeKok.
I had the same problem several times. Once the problem was in external script which was to slow and radius had problems with it. Second time I had a problem with SATA disk because it wasn't recognized correctly and IO performance was terrible... Third time the problem was in slow mysql and few tuning actions was the solution... Also, once I had a problem with RAID controller and it was the reason for bad performance... So, according to my experience, the worst thing you can do is to say: "It doesn't work!!!" and to sit down and wait for a solution... Adding RAM won't help if you're not sure what you're doing... The system is in your hands... System with 3500 users will do fine with 1GB RAM, Xeon, bla bla... Default radius config. Interim updates are set to 5 min. Active connections goes up to 2000 online users during peek time... Also the same server is used for mail server and provisioning system for CPE equipment... It all works fine with average load below 1 ... Gary Gatten wrote:
I’m sure other threads are doing something – but take so little cpu time the low resolution counters don’t catch it?
What are these two threads?� Probably SQL related?�
I missed the start of this thread, but seems some frustration is building.� Without SQL FR is very fast.� With SQL, who knows – way too many variables, especially if you’re using prebuit packages and not compiling yourself?� Compiling is a HASSLE, so I usually try to start with packages and if they work for me that’s great.� However, I typically find some feature I want to make use of that wasn’t included in the package that “Bob” built, so I end up building/compiling with the appropriate configure args and such.
If your system is “slow”, you need to start at the beginning.� Maybe something is wrong with the SQL config, disks, RAM, etc.� Maybe SQL is not optimized?� Many “maybe’s”… If you haven’t done much customizing, perhaps install apps with default configs to a different directory (use new SQL files too) and see if the slowness is present in the default configs.� Try to keep things as simple as possible!� Complicated CAN be fun, until it breaks!
G
------------------------------------------------------------------------
*From:* freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org [mailto:freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org] *On Behalf Of *Alisson *Sent:* Wednesday, December 23, 2009 2:05 PM *To:* FreeRadius users mailing list *Subject:* Re: error discarding packet
I run Top -P -H
and it showed the threads, only 2 are working
2009/12/23 Gary Gatten <Ggatten@waddell.com <mailto:Ggatten@waddell.com>>
There are some switches in top (differ by platform) that will show you individual threads and their accumulated CPU time, current CPU util, etc. Such as:
Top –p “YOUR-PID” –H. You MAY have to start the app (FR) in gdb to figure out what thread is doing what (sometimes the app will log when threads start and what they’re doing – but sometimes not). A more seasoned SysAdmin may have an easier / better solution, but this method has proven invaluable to me when trying to troubleshoot multithreaded apps and determine which thread is using most memory, cpu, etc. and what functions that thread is doing.
G
------------------------------------------------------------------------
*From:* freeradius-users-bounces+ggatten=waddell.com <http://waddell.com>@lists.freeradius.org <http://lists.freeradius.org> [mailto:freeradius-users-bounces+ggatten <mailto:freeradius-users-bounces%2Bggatten>=waddell.com <http://waddell.com>@lists.freeradius.org <http://lists.freeradius.org>] *On Behalf Of *Alisson *Sent:* Wednesday, December 23, 2009 1:32 PM
*To:* FreeRadius users mailing list *Subject:* Re: error discarding packet
i'm using 15 threads and monitoring on top, the max server load is 2.0/3.0
2009/12/23 Gary Gatten <Ggatten@waddell.com <mailto:Ggatten@waddell.com>>
Isn’t there some guidelines in the conf files for these? Generally you want as few threads as possible to service the load. How volatile your connections are, are more important than the max number of possible connections, and only you know this. Perhaps start with 10 threads and monitor with top now and then.
------------------------------------------------------------------------
*From:* freeradius-users-bounces+ggatten=waddell.com <http://waddell.com>@lists.freeradius.org <http://lists.freeradius.org> [mailto:freeradius-users-bounces+ggatten <mailto:freeradius-users-bounces%2Bggatten>=waddell.com <http://waddell.com>@lists.freeradius.org <http://lists.freeradius.org>] *On Behalf Of *Alisson *Sent:* Wednesday, December 23, 2009 1:11 PM *To:* FreeRadius users mailing list *Subject:* Re: error discarding packet
you dont understood... i dont make this configuration
i'm ask for help to do a good configuration based on between 3000 and 35000 conecctions to this function thread pool
thread pool { start_servers = 1 max_servers = 1 min_spare_servers = 1 max_spare_servers = 1 max_requests_per_server = 0 }
i need a help to configure this
2009/12/23 Alan DeKok <aland@deployingradius.com <mailto:aland@deployingradius.com>>
Alisson wrote:
one last doubt...
for 3500 customers what is a good configuration in radiusd.conf
The default configuration.
for this function
thread pool { start_servers = 1 max_servers = 1 min_spare_servers = 1 max_spare_servers = 1 max_requests_per_server = 0 }
That is not the default configuration.
You have changed the server to *slow it down*.
Why?
If this issue is so important for you, why are you so insistent on ignoring *all* help that you get on this list?
A basic install of FreeRADIUS + MySQL on a normal system will get 100's of auth/s with 10's of 1000's of users in the DB. If you can't get that, it is because *you* have broken the configuration.
Don't break the default configuration.
Follow instructions on this list.
It's really *not* that difficult to make the server work.
*Stop* editing things you don't understand.
All you need to do is to *stop* breaking the server.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Att. Alisson F. Gon�alves Sistemas de Informa��o - UFGD
"This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system."
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Att. Alisson F. Gon�alves Sistemas de Informa��o - UFGD
"This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system."
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Att. Alisson F. Gon�alves Sistemas de Informa��o - UFGD
"This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." ------------------------------------------------------------------------
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
i'm using 15 threads and monitoring on top, the max server load is 2.0/3.0
server load is HOW much? whys it that high - you should look at why this is so high - what else is the server doing? is it hitting some disk-bound process? our RADIUS servers never see more than 0.2 load - and they are lesser spec than yours. for top, capital H will show you all threads. alan
normally stay on 0.3 / 0.4 and with the top -H show 2 threads from mysql working and the another with 0.0 load 2009/12/23 Alan Buxey <A.L.M.Buxey@lboro.ac.uk>
Hi,
i'm using 15 threads and monitoring on top, the max server load is 2.0/3.0
server load is HOW much? whys it that high - you should look at why this is so high - what else is the server doing? is it hitting some disk-bound process? our RADIUS servers never see more than 0.2 load - and they are lesser spec than yours.
for top, capital H will show you all threads.
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Att. Alisson F. Gonçalves Sistemas de Informação - UFGD
participants (6)
-
Alan Buxey -
Alan DeKok -
Alisson -
Borislav Dimitrov -
Gary Gatten -
Marinko Tarlac