[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Mldonkey-users] Why does mldonkey open so much files (1024)?
From: |
Martin Schmidt |
Subject: |
Re: [Mldonkey-users] Why does mldonkey open so much files (1024)? |
Date: |
Wed, 11 Sep 2002 12:49:34 +0200 |
User-agent: |
KMail/1.4.3 |
On Wednesday 11 September 2002 10:11, Goswin Brederlow wrote:
> Martin Schmidt <address@hidden> writes:
Hi,
> > On Tuesday 10 September 2002 22:21, MLdonkey wrote:
> > The last time this bug happened I checked with lsof and the number of
> > shared and config files was ok (not so much, shared about 5, 40
> > downloading - like it was). But the real big rest was sockets. And
> > Netstat showed only about 130.
> >
> > When it happens next time, I check it again.
>
> How many connect do you allow? I have somewhere at 900 I think.
I have 924 (the default).
> mldonkey sets a timeout of 1/2 day (why so high?). When my dsl redials
> that means I still have all previous connects dangling for half a day
> before they give a timeout. I think that could keep quite a feq
> filedescriptors open far too long.
I have a 24 h auto-disconnect, but in my case this was not the problem this
all happened in the 24 h connected time (I looked at the pppd logs).
> > > > http and I can't add links of course, too.
> > > >
> > > > Now my question is, if it really neccessary, that mldonkey opens so
> > > > much files/connections, and why - or it is just a bug?
> > > >
> > > > And if it no bug, should I increase the limit in
> > > > /usr/src/linux/include/linux/limits.h ? What are the disadcantages?
>
> Maybe mldonkey should kill a random/old/stale connect when it fails to
> make a gui connect.
Hm, maybe, but I don't use the gui.
> Further a close everything command should be helpfull. One could run
> that and then look whats still open, those would be the leaks. I heard
> something about doing that with a signal (to be used when the connection
> redials) should work but doesn't. Any comments there?
This is a good idea I think (for pppd reconnects) - but then you again don't
know, where it is the leak. Perhaps a verbose debug feature would be not bad.
Perhaps I will learn some ocaml and look into the code (but at the moment I
have no much time).
To say it again, nestat shows only about 130 and in proc (lsof) there are much
more (the big rest).
Regards
Martin Schmidt