According to MSDN documentation, Page Reads/sec is a good way to try to address whether or not the system’s issue is lack of memory or if it’s a coding issue/memory leak.
I’m looking for some advice from others and ways to go down the path to find out more.
I’m running the following on my machine (Windows 7. 64 Bit. 4GB Ram)
1. InteliJ 10 (Tomcat for my Web Services & JSP for the front end)
2. Oracle 11g
I’m trying to identify what/where the problem can be – so I created a script in JMeter to run to throttle the system a bit to create data & search the system for data.
Running Performance Monitor for a 10 minute period my data is as follows:
Page Reads/Sec (Average): 26.841
Pages Input/Pages Fault = Hard Fault % = 5%
Pages Fault/sec (Avg) = 2300
MSDN says a sustained value over 5 Page Reads/sec is often a strong indicator of a memory shortage but that’s a sustained value and not average. It spikes a few times but over the long haul seems to go between 0-3 with a few spikes that hit really large.
I thought a memory leak might be the issue; however, after inspecting the code and checked that streams were closed (Files/Inputs/DB Connections/etc), I’m not so sure.
Does this data point more towards lack of memory, a memory leak in the Services or a configuration issue?
Edit 1: Looking at heap
I currently can only access my development system and not production. Would need to coordinate with someone else to get me access to logs & use jvisualVM on the system.
However, I did take a few heapdumps on the development system last week and today. Nothing crazy in class usage minus String & char[]. Looking at the Monitor my heapsize in development is 463,863 and the max is around 480. Used fluxuates between 415 and 450.
Using Eclipse Memory Analyzer and the “suspected leak report” on the heapdump shows 3 problem suspects.
1. One instanceo f "org.apache.jasper.servlet.JspServlet" loaded by "org.apache.catalina.loader.StandardClassLoader" Occupies 18.70% The memory is accumulated in one instance of "java.util.concurrent.ConcurrentHashMap$Segment[]
2. The thread org.apache.tomcat.util.threads.TaskThread @ http-apr-8080-exec-19 keeps local variables with total size 12.30%. The memory is accumulated in one instance of "org.apache.tomcat.util.threads.TaskThread" loaded by "org.apache.catalina.loader.StandardClassLoader"
3. The thread org.apache.tomcat.util.threads.TaskThread @http-apr-8080-exec-24 keeps local variables with total size 10.72%. The m emory is accumulated in one instance of "org.apache.tomcat.util.threads.TaskThread' loaded by "org.apache.catalina.loader.StandardClassLoader"
I was under the impression (could be wrong) that some of this is normal as TomCat is goign to load a lot of stuff initially and store it.
One thing you can do is look in Task Manager and observe how much memory your Java-related processes are taking up.
Sum up all the Private Working Set memory of, say, the top 10 memory-intensive processes (whether they are Java-related or not). If this value is close to or greater than 75% of your physical memory capacity, OR if you’re running a 32-bit operating system with PAE disabled (you didn’t state your operating system), it may be a physical memory limitation.
If your private working set sum is using much less than your total physical memory, it’s likely not a problem related to that. It could also be heavy disk I/O related to the Oracle database; more memory will allow your system to cache disk pages in RAM, which dramatically speeds up reads because it treats your RAM as a sort of disk (but RAM is 20 to 50 times faster than a hard disk).