Version: 2.2.1 (using KDE 3.5.7, Gentoo) Compiler: Target: x86_64-pc-linux-gnu OS: Linux (x86_64) release 2.6.20-gentoo-r8 Example line from top: 822259 bss 15 0 3621m 2.6g 21m S 6 69.2 37:00.31 ktorrent That 3.6Gigs of virtual memory. 1Gig swap + 2.6Gig RAM. 97 torrents listed, 58 running, 57 seeding, 11 actively seeding, 1 downloading. This seems a bit large. It's also seems to be a memory leak, as usage increases over time. Yesterday was over 7Gig virtual memory.
Plugins Loaded: Bandwidth Scheduler IP Filter Import Info Widget RSS Feeds Search
Unloading all plugins does not reduce memory consumption, but I'm not sure if it will prevent the consumption initially.
Does the memory usage drop back if you stop all torrents ?
On Wednesday 15 August 2007, Joris Guisson <joris.guisson@gmail.com> wrote about '[Bug 148385] massive memory usage in ktorrent': > Does the memory usage drop back if you stop all torrents ? IIRC, No. Otherwise, I'd do that rather than quitting and restarting KTorrent. I'll reconfirm that though next time the memory spikes (should be later today).
> Does the memory usage drop back if you stop all torrents ? Correcting my earlier statements, yes. The memory usage does drop back to acceptable levels if you Stop All and Start All.
On Friday 17 August 2007, Boyd Stephen Smith Jr. <bss03@volumehost.net> wrote about '[Bug 148385] massive memory usage in ktorrent': > > Does the memory usage drop back if you stop all torrents ? > > Correcting my earlier statements, yes. The memory usage does drop back > to acceptable levels if you Stop All and Start All. Grr, just tried this again this morning and it did *not* reduce the memory usage, while stopping the application freed over 1.5G of memory. I'm still running a number of plug-ins, so I'm not entirely sure where the memory leak is. I'm willing to test disabling virtually any plug-in exception the RSS feeds -- any likely candidates?
On Wednesday 15 August 2007, Joris Guisson <joris.guisson@gmail.com> wrote about '[Bug 148385] massive memory usage in ktorrent': > Does the memory usage drop back if you stop all torrents ? Today, from htop, after stopping all torrents: PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command 204951 bss 15 0 2669M 2083M 17652 S 31.1 53.5 35:41.63 ktorrent -icon kt
I had a possibly related thing. I left ktorrent running with one torrent stopped (not enough space for it) and the scheduler on. When I came back the next day it had used up all 512MB of RAM, and 100% CPU, just doing nothing! I killed it, and when I ran it again the torrent was still stopped. Weird. Definitely some memleaks in there (ktorrent 2.2.1).
SVN commit 840601 by guisson: Merged fix from trunk which fixes some weird behavior in the chunkmanager potentially causing a lot memory usage BUG: 148385 M +1 -0 ChangeLog M +7 -5 libbtcore/diskio/chunkmanager.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=840601
*** Bug 172437 has been marked as a duplicate of this bug. ***
commit 2d2498280f3c2541815376ea9695e3f82f534c29 branch refs/tags/v3.1.2 Author: Joris Guisson <joris.guisson@gmail.com> Date: Fri Aug 1 10:51:15 2008 +0000 Merged fix from trunk which fixes some weird behavior in the chunkmanager potentially causing a lot memory usage BUG: 148385 svn path=/branches/ktorrent/3.1/; revision=840601 diff --git a/ChangeLog b/ChangeLog index 6a440cf..e6f4434 100644 --- a/ChangeLog +++ b/ChangeLog @@ -5,6 +5,7 @@ Changes in 3.1.2 : - Backported some improvements to download thread - Make sure cookies are not sent in http announces - Fix crash at startup which started happening since KDE 4.1 +- Fix problem causing massive memory usage (148385) Changes in 3.1.1 : - Fix wrong icon name in PeerView for encrypted peers diff --git a/libbtcore/diskio/chunkmanager.cpp b/libbtcore/diskio/chunkmanager.cpp index e9fb84f..f8e3eae 100644 --- a/libbtcore/diskio/chunkmanager.cpp +++ b/libbtcore/diskio/chunkmanager.cpp @@ -310,7 +310,7 @@ namespace bt { // load the chunk if it is on disk cache->load(c); - loaded.insert(i,bt::GetCurrentTime()); + loaded[i] = bt::GetCurrentTime(); bool check_allowed = do_data_check && (max_chunk_size_for_data_check == 0 || tor.getChunkSize() <= max_chunk_size_for_data_check); // when no corruptions have been found, only check once every 5 chunks @@ -339,8 +339,12 @@ namespace bt recheck_counter++; } } + else + { + // update timestamp + loaded[i] = bt::GetCurrentTime(); + } - loaded.insert(i,bt::GetCurrentTime()); return c; } @@ -390,9 +394,7 @@ namespace bt cache->save(c); c->clear(); c->setStatus(Chunk::ON_DISK); - QMap<Uint32,TimeStamp>::iterator j = i; - i++; - loaded.erase(j); + i = loaded.erase(i); num_removed++; } else