Option to alter memory consumption
Currently, bliss as a service is chewing ~200Mb with consistently ~3% CPU cycles on a modern computer with a small library. Yes, it's mostly a Java issue (it loving memory and all), but when you also use your server for VM's, 4Gb starts to look a bit... weak... Also, reduction in CPU cycles = reduction in power bill.
I would like an option where I could specify the ceiling of how much memory bliss should consume. The levels would be something like 64, 128, 256 MB.
rapture
shared this idea
-
rapture
commented
That sounds great. Thanks!
-
Sure.
A measurable feature would be, similar to what you describe, a simple feature in the UI which limits memory use. The levels would be something like 64, 128, 256 MB (all approximates).
If you agree, I can change the feature title to "option to alter memory consumption" or similar.
-
rapture
commented
Yes, I did know Java has a large overhead. Nothing you can really do there. Reduce memory footprint at the cost of performance I feel is a valid and acceptable trade off. For a background service that runs constantly, the time it takes to update half a dozen new songs every week or so is irrelevant, as long as it's done in a timely manner. I'd prefer it to have a lower net memory use and take longer to do the task.
Maybe this becomes an option within bliss? A simple drop down "Limit memory use to:" and on next start it's a smaller footprint. I was happy changing the bliss.bat file myself, but not all are comfortable with this.
Turns out the CPU usage was as my brother had dropped some songs into the directory and I didn't know, so it was in the working processes.
Working with WHS 2011 here, on a Athlon II X4 630, so definitely not a slouch. System is actually an old gaming PC with the video card out and extra hard disks. I agree with the the optimization conundrum, a never ending battle. How do we define a goal for successful optimization? What would be the easiest way to approach this issue?
-
This is very valid: I myself run bliss on my home server, within a VortexBox VM, and I am always concious of reducing energy use.
First, let's separate the two aspects: memory and cpu.
Memory - the ~200MB is for bliss plus the JVM overhead. bliss is configured to use 128MB maximum - the rest is the overhead. You can lower this by altering the bliss startup files - either bliss.sh or bliss.bat. Change '-Xmx128M' to '-Xmx64MB' or similar. Note that this will slow down bliss, though. It means opportunities for cacheing are reduced and the JVM will more often have to reclaim memory ('garbage collection').
CPU - it's worth checking if this 3% is while bliss is idle. I think there are internal processes, particularly in the UI that poll, every so often, for HTTP session liveness and so forth. We might be able to tune this. However, there will be a baseline: if bliss really is idle then any CPU use would probably come from the file notification system - and there's not much that can be done about that.
What OS/platform are we discussing here?
It's probably worth, after discussion, working out something measurable that we can redefine this idea as - then we can mark it as 'completed'. Obviously 'optimization' is a never ending thing - more can always be done.
