Performance of OperatingSystem.getProcesses() over a large period of time

[unknown-spirit]

Hi guys,
I am using oshi for my BusyTasks app on Windows and just did some profiling to find out how to improve cpu performance.
I am calling getProcesses() every second once to gather all necessary information. Unfortunately, this method takes about 96,5% of all the cpu of my program, so it is wise to concentrate any performance tweak on that part. More precisely, I found that each call takes 75-100 ms at startup, which is quite acceptable. However, this value increases over time. After about 5 hours, it is already up to 200-250 ms. Likewise, the CPU that it takes on my system starts at around 2% and finishes at 6-7%. When I concurrently launch my program again and compare the results to the process running 5 hours, I see that they are surprisingly equal. It is only when I close both instances and restart the app that the values are back at initially low level. As a concrete interpretation I blame the JVM for the performance loss and wonder if there's actually anything that can be done to get a stable performance.
I appreciate any ideas and thoughts about it.

[dbwiddis]

Just a hunch, this may be related to finalizer usage, see #2009.

You can try to inspect the heap when it gets slow to see if you've got GC issues.

If this is the case, I'll be making some changes when JNA 5.12.0 is released (hopefully this week) and releasing OSHI 6.2.0 which should significantly improve performance.

If you want to pre-test a fraction of the possible improvements, check out this branch that I put in a portion of the expected 5.12.0 changes. https://github.com/dbwiddis/oshi/tree/cleanermemory

[unknown-spirit]

Interested in whether this solves your CPU load issues now.

We will see. Having run it for ten minutes, I think it's equal or even slightly higher. On the other hand, the issue with the system process may be solved. This will take more time to investigate. Tomorrow is another day.

Also, I'm beyond thankful for your patience in helping me to run this to ground. You have been EXCEEDINGLY helpful.

No problem. I just tested, your knowledge was the key. I know that localization of performance counters is a pain in the ass as I have used them too.

[unknown-spirit]

@dbwiddis
After much testing I can confirm two major observations:

1. The CPU usage of BusyTasks stays low for many hours.
2. The CPU usage of "NTOSKRNL.exe%Ordinal25" steadily increases and only restores on BusyTasks' exit, which strongly suggests a connection between the two processes.

I suspect you're still seeing an impact from Garbage Collection, but not necessarily from OSHI. Where are all the byte[] allocations coming from?

I always thought that java manages memory on its own and you could safely rely on it, but that's obviously not the case.
It's clear that there is something wrong, be it in my program or even in MS Windows. Looking at my program, I can't extract anything reasonable from the huge number of profiler values, and regarding ntoskrnl, there's obviously no profiling option (access violation).
Do you have any tips on how to solve this issue? Is it wise to set unused Java-Pointers to null, even if a concrete assignment already suggests freeing of the old stuff?

[dbwiddis]

Do you have any tips on how to solve this issue? Is it wise to set unused Java-Pointers to null, even if a concrete assignment already suggests freeing of the old stuff?

Unfortunately none specific. I do think, generally speaking, that the additional NTOSKRNL load is associated with native memory management in some way. However, I'm not really sure it's a problem that needs to be solved if the usage is down in the 5%-10% range.

I always thought that java manages memory on its own and you could safely rely on it

Generally speaking, yes (via the Garbage Collector) but when you are dealing with JNA you are dealing with native memory which is a completely different thing outside of the GC world. It's essentially low level malloc() and free() calls. The latest changes in JNA and OSHI moved the scheduling of those earlier (so more memory is kept free at any given time) but the total number of calls is still somewhat the same.

At this point I think the best thing you can do is experiment with various java command line switches to try out different configurations and see if they have any impact. Try increasing heap size, changing GC thresholds, different GCs, etc.

You can try tracking native memory as well.

It's possible there's a device driver on your system that OSHI has to query that is outdated and is the cause of the issue.

[unknown-spirit]

Thanks for your input.
After a few days' search, I was able to detect the problem. With the help of "Windows Assessment and Deployment Center" I found suspicious calls of "StartSystemThread" and "MiWalkPageTablesRecursively". At that time I already had in mind some poor thread creation, which was finally confirmed by copying the workflow of this site. My program was spamming short-living threads, which all were collected by Windows as zombies. They made up 10k after a few hours, slowing everything down. This issue will be solved in the next release, coming in about a week.
As far as I see now, the CPU usage of the program itself stays very low. Lower than I thought it could be. Thanks for updating oshi, release 6.2.0 did the trick!

[dbwiddis]

Excellent! Thanks for the update and glad to hear it's all resolved!