The resident/virtual of the process. Not the stat from within rtorrent. DHT/PEX disabled.
yes I also closed the torrents. I posted logs earlier with valgrind and there were huge memory losses. On Jan 25, 2008 8:03 PM, Josef Drexler <[EMAIL PROTECTED]> wrote: > On Jan 26, 2008, at 1:34 AM, In Incognito wrote: > > I tried something else. I basically stopped all the torrents. There > > was no peers connected, nothing in the transfer list. Basically > > rtorrent was inactive, but memory kept climbing. > > What memory? The one displayed in rtorrent in the download info? Or > resident/virtual/shared memory of the rtorrent process? Or what? > > (And it's probably not relevant, but did you stop (Ctrl-D) or close > (Ctrl-K) the torrents?) > > Oh, and do you have DHT enabled? If so, what are the statistics on > buckets, nodes, torrents and peers from the log? > > > The preload number 0/0/53450 stopped climbing though, but i guess > > that has to do with chunks. > > It's the number of chunks that were mapped without preloading. > > > If i do a cat /proc/<pid>/maps |grep /home/<user> | wc > > it comes out: 0 0 0 > > That means that all chunks got unmapped correctly. So if rtorrent > still uses more than a few megs, it's a mystery where the memory > went. And still, the most likely culprit is a bug in the compiler or > a library libtorrent/rtorrent uses. Since valgrind reports no > particular memory leaks (as I remember from the log you posted), it > can't be in rtorrent itself either, it would definitely catch that, > and libtorrent too, probably. > > -- > Josef Drexler > [EMAIL PROTECTED] > _______________________________________________ > Libtorrent-devel mailing list > [email protected] > http://rakshasa.no/mailman/listinfo/libtorrent-devel >
_______________________________________________ Libtorrent-devel mailing list [email protected] http://rakshasa.no/mailman/listinfo/libtorrent-devel
