Error with Thread

[Jean Carlos Oliveira Guandalini]

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.guandalini at 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.
>