Issue when one or more apps are running in parallel to SoulseekQt

Submitted by sysmaster01 on Mon, 01/28/2013 - 14:02
Forums: 
Soulseek General Discussion

Well, once more I might be the only one to experience this, but maybe anyone else can confirm?

When SoulseekQt is running for 1 day or more, AND many user shares are open at the same time for browsing, I can definitely confirm that browsing the web gets VERY slow especially with sites that make heavy use of JavaScript and/or Flash.

Probably because SoulseekQt takes INSANE amounts of RAM then?
I have to add that one of my RAMs got broken and I'm currently left with only 1 GB of RAM.
However, provided that SoulseekQT is programmed to use paged memory from a swap file, this should not matter much.

Once Soulseek is fully closed and quit, things are back to normal again and also Flash applications or games will come up ionstantly (instead of taking up to 2 minutes to load!)

I'm going to monitor this a little more thoroughly by letting GKrellM run simultaneously.

Submitted by sysmaster01 on Sun, 02/03/2013 - 05:35.

Replying to my own post...this has been reported previously.
http://www.soulseekqt.net/news/node/543

We should really be able to limit Slsk's max physical RAM usage, so that the rest is taken from the swap file. Just for the reason that other apps running in parallel and wanting to use physical RAM too (just a bit) will have a chance to still "breathe." I can confirm that 800-900 MB (!) of RAM used is not too unusual with SoulseekQt, especially when many browsed user shares are open and there's something in the queue(s).

Submitted by Nir on Sun, 02/03/2013 - 10:40.

Maybe looking at where most of this memory goes can help me devise some strategy to help memory use. When your client is taking a very high amount of RAM (the closer to the 800-900MB cited the better), make sure the diagnostics tab is available by checking Options->UI->Show Diagnostics (if the Diagnostics tab is already shown by default on your client, you might consider turning it off before restarting the client and see if that affects your memory use any), then go to the Diagnostics tab and click the 'Dump Data' button. Save to any filename you want. This might generate a very large file. If you compress it and send it to me via some file locker service (or I can privately message you my e-mail address) I'll be able to see what takes up that memory.

Thanks, Nir

Submitted by sysmaster01 on Mon, 02/04/2013 - 15:10.

Got your e-mail already written down, thanks. (You PM'd me once some short time ago anyway.)

One question: on Linux, are you actually touching the swap space with your current client versions (if need be)? Or do you allocate physical mem only?
The answer to that question may also take influence on further argumentation/reasoning...

Submitted by Nir on Tue, 02/05/2013 - 15:44.

I'm only allocating physical memory.

Submitted by sysmaster01 on Fri, 02/08/2013 - 15:08.

There you have it! Let's summarize...

Simple formula:
poor/insufficient physical RAM + lots of caboodle open inside SoulseekQt = tons of possible problems.

RAM gone = SoulseekQt nearly inoperable.
And a way out of this misery? - Sure there is. perform a full restart of SoulseekQt, and things ought to be back to normal. :)

That's because your software absolutely relies on sufficient physical RAM. If there isn't, it is not (yet) programmed to resort to an alternate method of snatching some mem (e. g. paging file/swap, /dev/zram0 etc.)

I think this has answered the whole thread by itself, thank you.

Solution (for me): find a matching (!) RAM stick and jam it in.
Workarounds: currently none.
Complaining? Not really. Merely observing things going on.