Error with Thread

[Fajar A. Nugraha]

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.

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