mldonkey-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mldonkey-users] NetBSD-Mystery and how i solved it


From: Goswin Brederlow
Subject: Re: [Mldonkey-users] NetBSD-Mystery and how i solved it
Date: 07 Feb 2003 20:26:57 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Portable Code)

Karsten Kruse <address@hidden> writes:

> Hoi,
> 
> Mldonkey (latest and greatest from CVS) uses 100% CPU. This is not for
> some minutes but for days. Here is what ktruss -p <pid-of-mldonkey>
> says (ktruss is something like strace):
> 
> 
>     467 mldonkey gettimeofday(0xbfbffa00, 0)        = 0
>     467 mldonkey poll(0x82f8200, 0x2f, 0x23)        = 1
>     467 mldonkey gettimeofday(0xbfbffa00, 0)        = 0
>     467 mldonkey accept(0x11, 0xbfbff978, 0xbfbff954) Err#24 EMFILE
>     467 mldonkey gettimeofday(0xbfbffa00, 0)        = 0
>     467 mldonkey poll(0x82f8200, 0x2f, 0x20)        = 1
>     467 mldonkey gettimeofday(0xbfbffa00, 0)        = 0
>     467 mldonkey accept(0x11, 0xbfbff978, 0xbfbff954) Err#24 EMFILE
>     467 mldonkey gettimeofday(0xbfbffa00, 0)        = 0
>     467 mldonkey poll(0x82f8200, 0x2f, 0x1d)        = 1
>     467 mldonkey gettimeofday(0xbfbffa00, 0)        = 0
>     467 mldonkey accept(0x11, 0xbfbff978, 0xbfbff954) Err#24 EMFILE
>     467 mldonkey gettimeofday(0xbfbffa00, 0)        = 0
>     467 mldonkey poll(0x82f8200, 0x2f, 0x1a)        = 1
>     467 mldonkey gettimeofday(0xbfbffa00, 0)        = 0
>     467 mldonkey accept(0x11, 0xbfbff978, 0xbfbff954) Err#24 EMFILE
> 
> I opened man accept(2) and this is what it says:
> 
>      [EMFILE]      The per-process descriptor table is full.
> 
> I guess this is the problem, but how can i solve this?
> Is this a system- or Mldonkey-related problem?
> Why is there so often gettimeofday?

Mldonkey needs to find out how long it did sleep and when the next
event is due.

The EMFILE probably means you have too many open filedescriptors, try
to lower the limit in mldonkey or raise the system limit.

The accept call suggests you are getting flooded with incoming
connects or due to the error it tries to connect to the same incomming
connect over and over again. It might be that its stuck in a loop
trying to connect and never comes around to timeout and close other
connects. Should be easy to find the relevamnt code, grep for accept.

MfG
        Goswin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]