[Libtorrent-devel] Unaddressed memory issue
in.incognito at gmail.com
Thu Jan 3 23:51:49 UTC 2008
Im using centos5.1. I have alot of programs that use mmap and this is the
first i've heard of an mmap bug in gcc 4.1.2-14 and its libraries.
On Jan 3, 2008 5:06 PM, Jonathan Dugan <dugan at matsonsystems.com> wrote:
> another data point:
> 48 torrents, seeding 65GB, between 15-40 peers total:
> total used free shared buffers cached
> Mem: 2076448 2024368 52080 0 22188 1813260
> -/+ buffers/cache: 188920 1887528
> Swap: 1614492 68 1614424
> 2G total, 190M used total for the machine
> top for this process:
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 4272 dugan 16 0 48612 38m 6.4m D 90 1.9 48:55.92 rtorrent
> Running on Debian Etch with older version: "Rakshasa's BitTorrent client
> version 0.6.4."
> Jonathan Dugan, PhD
> Matson Systems, Inc.
> (650) 799-5369
> On Wed, Jan 02, 2008 at 07:58:36PM -0500, In Incognito wrote:
> > The memory issue im talking about is
> > http://libtorrent.rakshasa.no/ticket/641.
> > Most of my torrents have 2mb - 4mb piece sizes. And from watching
> > it uses 3xPiece size for EVERY peer. This apparently does not change
> even if
> > you are just seeding. I have been playing around with max_memory_usage
> > each peer in seed mode uses 3x the piece size.
> > This is an absurd way of using memory. Most people connect to around 50
> > peers. Assuming there is absolutely nothing else loaded then ONE torrent
> > needs 300mb. ONE.
> > Now if piece sizes are 4mb, and alot of torrents are, then you even more
> > memory for ONE torrent.
> > Max_memory_usage is not a solution because the same structure is being
> > In fact without any sort of peer selection speeds suffer tremendously.
> > not sure why this hasn't been addressed. Since the last release there
> > been nothing but petty changes and the addition of someone else's DHT
> > _______________________________________________
> > Libtorrent-devel mailing list
> > Libtorrent-devel at rakshasa.no
> > http://rakshasa.no/mailman/listinfo/libtorrent-devel
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libtorrent-devel