Help and Support
Ask a question, report a problem, request a feature...
<<  Back To Forum

Memory usage very high

by Guest on 2016/04/28 09:19:24 PM    
Dear sir.

Tixati is truly the best client at first sight.

but on 2nd look and 3rd look and as your transfers / completed list grows so Tixati problems grows.

Will its only one problem nothing else, I mean every thing in tixati is perfect, it just this problem of memory totally renders Tixati unusable including the system it is running on.

let me list the facts of Tixati compare to others I tested and will reference here as Client2 and Client3.


Tixati, with 0 activity
Total transferes (completed) = 22,000
Memory Usage = 3.8 GB
CPU Usage = 24.7%

Client 2, with 2 active transfers
Total transfers (completed / stopped) = 34,000
Memory usage = 170 MB

Client 3, with 0 active transfers
total transfers (stopped) = 32,000
memory usage = 700MB

------------------------------- Update -------------------------

Before I started this topic, I installed the latest v2.37 and when I started Tixati I noticed it to open faster than usual. The system didn't go as crazy as usual.
So I opened task manager to monitor memory usage which was 3.9GB while I was typing this post.
by the time I finished typing the first part of this post I notices the memory usage dropped to 600mb for the first time since a long time.

That was exciting so I wrote this update to let you know that Tixati is alive again and I can go back to using it instead of others.

------------------------------Update ----------------------------

By the time I finished writing the first update I noticed Tixati Memory usage went very high again 3.8GB and again affecting the system.

this really disappointing and as many others would like to go back to Tixati, but how?

I have tested tixati on other systems with same load as above and with different optimization and suggestions I found on the internet, but nothing works.

Please let us know if there is hope in the future of tixati to handle users like us or not.

the issue of tixati memory usage and slowing the system started a year ago with total transfers (completed) = 4500, and it kept getting worse until unusable.

please let me know if you want the names of the other clients I listed above.

Thank you.
by Bugmagnet on 2016/04/28 11:43:47 PM    
I'd say name the names of the other clients you are comparing to.

Aside from that, I don't experiment much with other torrent clients anymore. My focus is on busting tixati, identifying problem areas, reporting as well as I can and making suggestions along the way.

As you noted v2.37 is a MARKED advancement from earlier versions. Much of that comes from users pushing the limits are reporting feedback so your report and as much detail as possible may very well lead to more optimal client behavior.

I have no way of knowing the actual size of the library (in ## TB I assume!) you have loaded in the clients, but 22-34,000 is definitely a lot of torrents. I noted though that while you have them loaded you are not sharing them, other than 2 active during this test.

I presently have a little over 2200 torrents loaded, likely totaling in the 4-6TB range. Of those, I have 1900+ active. As my testing over time indicated Tixati would struggle with such a load, a new feature was added for managing the queue, to put most seeds on standby and handle those for which there was significant demand up front. With that, and my current setting of 30 upload slots, Tixati is  seeding 425 torrents easily maxing out my UL bandwidth (I could probably reduce my UL to the 5 most in demand torrents and still reach my 8mb/s UL limit setting). Nearly 1400 other seeded torrents are on standby, rotated in from time to time to assess peer demand. I am not aware of any other client that has this advanced queue control system (but again, I haven't looked at them lately).

While I have 20-30,000 less torrents loaded than you, I am wondering what the point of loading that many is when there is no way any client could service that many at a time. Maybe Tixati's auto-queue management could tame it. Do you have it enabled?

As I said, my UL BW is saturated and Tixati could be servicing lots more peers if I had more BW. But as is, with about 17 hours uptime on v2.37, I am recording a 10.22% CPUsage over term and about 1.7GB of memory, mostly in RAM, flatlining my UL BW at 8mb/s.

I am interested in the differences that you reported. Why is it that client 2 can have 34,000 torrents loaded and be using only 170MB of memory? But again, I note they are all stopped, with only 2 active. That also confuses me. What's the point of loading 34,000 into the client but only starting 2?

Still, you report Tixati with 1/3 less torrents uses 20 times more memory. How and why? Does Tixati have some additional functionality that needs the extra data, some function that client 2 is not performing? If not, then a code review might be in order. A program can always be improved, as v2.37 proves.

But knowing the other clients, studying what they are doing and not doing might give a clue. But all that is out of my league, not being a programmer.
by Guest on 2016/04/30 02:41:41 AM    
Thank you for your prompt reply.

The following are the list of clients mentioned.


Client 2 - BitComet v1.4 64-bit

Total transfers List (stopped / completed) = 33566

Time takes to load BitComit = 32 seconds

Active download = 1

CPU used = 12%

Memory = 140 mb



Client 3 - transmission QT v2.84.8 Windows 64-bit

Total transfers List (stopped / completed) = 31241

Time takes to load Client = 13 minutes

Active download = 0

CPU used = 0.2.8%

Memory = 568 mb


Also have tested several others including Vuze, Qbittorrent and utorrent but then I uninstalled because I settled with the above 2 clients. nevertheless the highest memory usage of those was 1700 MB by QbitTorrent. Nothing went as close to Tixati 4GB.

I have found that the only secret to high memory usage which is the cause of all the problems of Torrent Clients and the system they run on is simply the Torrent / Downloaded / completed list as it becomes larger. so for that as follows:

In regards to BitComit and its legendary unmatched speed loading, memory usage and responsiveness is because the way it handles the Large Download History list. Please look at and check the way it builds its Transfers history. it makes an xml file for each torrent / next to each torrent file in the folder where its saved, and reference it in the as text list pointing to very small xml file instead of torrent file.

Issue simply solved and Tixati becomes best client in history of torrenting. vuala!

Pleas let me know if this input is helpful and you will analyse BitComet. if you need more details or screen shots I would be more then happy to do.

Regards.




This web site is powered by Super Simple Server