Re: Error with Thread
On Wed, Jun 29, 2011 at 6:32 PM, Jean Carlos Oliveira Guandalini jean.guandal...@corp.visaonet.com.br wrote: Hello, i'm using version 1.1.8, my OS is Linux (Gentoo). The usual response would be upgrade. 1.x is not supported anymore. My server stop and log this: Error: FATAL: Thread create failed: Resource temporarily unavailable Before this log, have: Wed Jun 29 00:16:13 2011 : Error: Dropping conflicting packet from client client1:41250 - ID: 195 due to unfinished request 155365 Wed Jun 29 00:16:13 2011 : Error: Dropping conflicting packet from client client2:59253 - ID: 235 due to unfinished request 155374 my guess is freeradius is busy handling requests that took a long time. Usually this happens when your backend (e.g. db) takes a long time to process the request, which is quite common if (for example) you record accouting packets in database, and never clean it up so it has millions of rows. Or your db is not properly designed (e.g. not indexed in the right columns). Or you're using custom queries which cause high load to the db. In any case, I'd start by fixing whatever backend you use first, make sure it can respond in a timely manner. -- Fajar - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Error with Thread
Unfortunately I not update a version because one module what we use was not run correctly in newer versions If I use Mysql(InnoDB) instead MyISAM, maybe help with table lock and consequently better performance? Thanks Jean Em 29-06-2011 10:10, Fajar A. Nugraha escreveu: On Wed, Jun 29, 2011 at 6:32 PM, Jean Carlos Oliveira Guandalini jean.guandal...@corp.visaonet.com.br wrote: Hello, i'm using version 1.1.8, my OS is Linux (Gentoo). The usual response would be upgrade. 1.x is not supported anymore. My server stop and log this: Error: FATAL: Thread create failed: Resource temporarily unavailable Before this log, have: Wed Jun 29 00:16:13 2011 : Error: Dropping conflicting packet from client client1:41250 - ID: 195 due to unfinished request 155365 Wed Jun 29 00:16:13 2011 : Error: Dropping conflicting packet from client client2:59253 - ID: 235 due to unfinished request 155374 my guess is freeradius is busy handling requests that took a long time. Usually this happens when your backend (e.g. db) takes a long time to process the request, which is quite common if (for example) you record accouting packets in database, and never clean it up so it has millions of rows. Or your db is not properly designed (e.g. not indexed in the right columns). Or you're using custom queries which cause high load to the db. In any case, I'd start by fixing whatever backend you use first, make sure it can respond in a timely manner. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Error with Thread
On Wed, Jun 29, 2011 at 8:29 PM, Jean Carlos Oliveira Guandalini jean.guandal...@corp.visaonet.com.br wrote: Unfortunately I not update a version because one module what we use was not run correctly in newer versions That sucks :P If I were you I'd start investing in reeimplementing that module so it's compatible with newer 2.x. Possibly even rewriting it in perl so it can be run with rlm_perl. If I use Mysql(InnoDB) instead MyISAM, maybe help with table lock and consequently better performance? When someone ask me that question, usually it's a sign that they know very litlle about database. And my best advice would be get a dba. The reason is that: - Note that I said GUESS previously. You need to determine whethere it IS in fact the database that's slow. That would require some knowledge about the database being used, including how to find out what is causing the most load. This is a skill that a dba will have. - Innodb and MyISAM have their own strength/weakness, but I've never had a case where JUST changing the storage engine would automagically solve all problem. Storage engine selection and tuning is usually part of the solution, but it's not the ONLY one. In fact, I'd say when it comes to performance, index matters more than storage engine type. Again, this is a skill that a dba will have. - The default queries used by freeradius is fairly simple and straightforward. Thus, the effort/skill required to make it faster is pretty much the normal things that a dba would do for a common database. These might include (but not limited to) optimizing index, table definitions, queries, partitioning, clustering, and so on. Again, this is a skill that a dba will have. So my best advice right now is find out if the db is the cause of the slow response (running top on the db server would be a good start). If it is, get help from a dba or ask in the db's respective forum/list. If it's not, well, I'd start with running radiusd -X, simulate with a test auth/acct packet, and see where it's taking the most time. -- Fajar Em 29-06-2011 10:10, Fajar A. Nugraha escreveu: On Wed, Jun 29, 2011 at 6:32 PM, Jean Carlos Oliveira Guandalini jean.guandal...@corp.visaonet.com.br wrote: Hello, i'm using version 1.1.8, my OS is Linux (Gentoo). The usual response would be upgrade. 1.x is not supported anymore. My server stop and log this: Error: FATAL: Thread create failed: Resource temporarily unavailable Before this log, have: Wed Jun 29 00:16:13 2011 : Error: Dropping conflicting packet from client client1:41250 - ID: 195 due to unfinished request 155365 Wed Jun 29 00:16:13 2011 : Error: Dropping conflicting packet from client client2:59253 - ID: 235 due to unfinished request 155374 my guess is freeradius is busy handling requests that took a long time. Usually this happens when your backend (e.g. db) takes a long time to process the request, which is quite common if (for example) you record accouting packets in database, and never clean it up so it has millions of rows. Or your db is not properly designed (e.g. not indexed in the right columns). Or you're using custom queries which cause high load to the db. In any case, I'd start by fixing whatever backend you use first, make sure it can respond in a timely manner. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Error with Thread
Thank for your advices, I really think what have a problem with DB. Because the problem only happens when have many authentication requests simultaneously. Thanks again. Jean Em 29-06-2011 10:46, Fajar A. Nugraha escreveu: On Wed, Jun 29, 2011 at 8:29 PM, Jean Carlos Oliveira Guandalini jean.guandal...@corp.visaonet.com.br wrote: Unfortunately I not update a version because one module what we use was not run correctly in newer versions That sucks :P If I were you I'd start investing in reeimplementing that module so it's compatible with newer 2.x. Possibly even rewriting it in perl so it can be run with rlm_perl. If I use Mysql(InnoDB) instead MyISAM, maybe help with table lock and consequently better performance? When someone ask me that question, usually it's a sign that they know very litlle about database. And my best advice would be get a dba. The reason is that: - Note that I said GUESS previously. You need to determine whethere it IS in fact the database that's slow. That would require some knowledge about the database being used, including how to find out what is causing the most load. This is a skill that a dba will have. - Innodb and MyISAM have their own strength/weakness, but I've never had a case where JUST changing the storage engine would automagically solve all problem. Storage engine selection and tuning is usually part of the solution, but it's not the ONLY one. In fact, I'd say when it comes to performance, index matters more than storage engine type. Again, this is a skill that a dba will have. - The default queries used by freeradius is fairly simple and straightforward. Thus, the effort/skill required to make it faster is pretty much the normal things that a dba would do for a common database. These might include (but not limited to) optimizing index, table definitions, queries, partitioning, clustering, and so on. Again, this is a skill that a dba will have. So my best advice right now is find out if the db is the cause of the slow response (running top on the db server would be a good start). If it is, get help from a dba or ask in the db's respective forum/list. If it's not, well, I'd start with running radiusd -X, simulate with a test auth/acct packet, and see where it's taking the most time. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
