Posts: 1,355
Joined: Dec 2008
Reputation:
18
bobrap
Posting Freak
Posts: 1,355
Was wondering if it's normal for TMM to have a high cpu usage. I've seen it as high as 90% and 25-30% when sitting idle. Using Windows 10. Thanks.
YOYIZDERZOMENEMOHOZEZAZEZDENDERIZHOZEZ
Posts: 3,027
Joined: Oct 2012
Reputation:
189
completely depends on the circumstances. If your free memory is running low, Java tries to free more memory which results in endless garbage collector runs. I've also seen the DB to compacting many times to shrink its size (where I think there is an issue in the MVStore, but I could not reproduce it to open an issue over there).
So in general: it is not normal that tmm eats up this amount of CPU in idle, BUT it can happen (most of the time the next restart of tmm it did not happen any more)
tinyMediaManager - THE media manager of your choice - available for Windows, macOS and Linux
Help us translate tinyMediaManager at
Weblate | Translations at 66%
Found a bug or want to submit a feature request? Contact us at
GitLab
Posts: 524
Joined: Aug 2015
Reputation:
26
In my case tmm rarely uses up more than 10% of CPU when idle, but I can see the db size constantly changing while tmm is running.
Speaking of the db size, I noticed the movie db size has recently grown significantly - more than 50% larger compared to 4.0.7. I tried re-creating the library but the db size was almost the same.
Can you tell me what has changed?
Posts: 3,027
Joined: Oct 2012
Reputation:
189
nothing changed in this regard.. In my observations today the db size of my default testbed was between 1.4 MB and 3.2 MB with exact the same data.. This has to be something MVStore internal
In the next build I turned of the MVStore internal compacting, but trigger a manual compact every time the DB has been changed (10 sec interval). This resulted in the same db size almost all the time (2.8 MB)
tinyMediaManager - THE media manager of your choice - available for Windows, macOS and Linux
Help us translate tinyMediaManager at
Weblate | Translations at 66%
Found a bug or want to submit a feature request? Contact us at
GitLab
Posts: 524
Joined: Aug 2015
Reputation:
26
What about movie set module?
The new feature "display missing movies for movie sets" comes to mind since it added lots of new (missing) movies and they must reside in the movie db.
But there still has to be more. Do the newly added columns affect the db size for the module?
Posts: 3,027
Joined: Oct 2012
Reputation:
189
ah ok - missing movies for movie sets could be the difference, but also this should not be a huge difference
tinyMediaManager - THE media manager of your choice - available for Windows, macOS and Linux
Help us translate tinyMediaManager at
Weblate | Translations at 66%
Found a bug or want to submit a feature request? Contact us at
GitLab
Posts: 1,355
Joined: Dec 2008
Reputation:
18
bobrap
Posting Freak
Posts: 1,355
So, in regards to resource usage, it's a java problem and not TMM? Basically something one has to live with.
YOYIZDERZOMENEMOHOZEZAZEZDENDERIZHOZEZ
Posts: 3,027
Joined: Oct 2012
Reputation:
189
not Java directly - the database engine we use internally. I've included a mitigation of this problem in v4.1, but I needed to find a compromise between database size and CPU usage (which can be high when constantly shrinking the database)
tinyMediaManager - THE media manager of your choice - available for Windows, macOS and Linux
Help us translate tinyMediaManager at
Weblate | Translations at 66%
Found a bug or want to submit a feature request? Contact us at
GitLab
Posts: 524
Joined: Aug 2015
Reputation:
26
I just tested the new build. Now it uses almost zero resources when idle and the db size remains the same if there's no change.
But it looks like a different level of compacting is going on when you make a change and when you exit.
My initial db size was 38 MB and if I make changes it fluctuates between 50 MB and 55 MB. Then when I exit, it becomes 34 MB.
It keeps showing this sort of pattern with the final db size fluctuating, which has been always the case even before this build.
Then should the manual compacting while running be really necessary as it auto-compacts on exit anyway?
Posts: 1,355
Joined: Dec 2008
Reputation:
18
bobrap
Posting Freak
Posts: 1,355
2021-02-15, 18:29
(This post was last modified: 2021-02-15, 19:43 by bobrap.)
If it matters, from my point of view, I could care less about the db size. Disc thrashing and memory usage is more important to me. Just my $.02.
Just loaded the 2-15 nightly. TMM sitting idle. CPU usage ~70%. That normal?
Disregard. I loaded the program again and it seemed ok. sorry.
YOYIZDERZOMENEMOHOZEZAZEZDENDERIZHOZEZ
Posts: 524
Joined: Aug 2015
Reputation:
26
Thanks for the detailed explanation! Now I can see why it has to work that way.
So it's an improvement in that it's no longer constantly compacting without any changes and even when it's compacting it uses a "lighter" way using less resources.