On 2/11/23 08:17, Thad Humphries wrote:
Finally I profiled our Java utility with VisualVM, all on
my Mac Mini, and quickly found a leak from java.util.zip. This was a
surprise because we were not using java.util.zip anywhere, nor could I find
any reference to java.util.zip when I looked at the
A profiler has its place. VisualVM was vital in helping us solve a Java 8
memory leak last November (although it didn't involve Tomcat). We were
moving a large, long running system from old Solaris machines with
InformixDB to Intel hardware with SELinux and OracleDB. Part of the
system's workflow
I've tried profilers in the past, but I've never had much luck since
you need a super computer to run them. Human intelligence rules ..
read the code carefully, review it, step it with a debugger, and look
for memory leak patterns. Mine have mostly been static and non static
collections and
Naturally, I thought about this about 5 seconds after I clicked "Send":
It doesn't happen very often, and it usually happens *after* a
substantial portion of the heap has been idle for some time. Maybe
there's something in there that works somewhat like a disk defragmenter.
And when it gets a
It would be unusual for the OS to reclaim any of that memory from the
JVM process. Are you looking at OS heap usage, or "JVM heap" usage?
From your description above, it's tough to tell. The tool is called
WRKJVMJOB so presumably it knows what the heck a JVM is, so maybe you
were getting the
Shawn,
On 2/9/23 17:18, Shawn Heisey wrote:
On 2/9/23 12:54, Christopher Schultz wrote:
It would be unusual for the OS to reclaim any of that memory from the
JVM process. Are you looking at OS heap usage, or "JVM heap" usage?
From your description above, it's tough to tell. The tool is called
On 2/9/23 12:54, Christopher Schultz wrote:
It would be unusual for the OS to reclaim any of that memory from the
JVM process. Are you looking at OS heap usage, or "JVM heap" usage? From
your description above, it's tough to tell. The tool is called WRKJVMJOB
so presumably it knows what the
James,
On 2/7/23 20:35, James H. H. Lampert wrote:
Monitored the thing all day, taking the CPU usage (via a WRKACTJOB) and
the current heap size and heap-in-use (via option 5 of a WRKJVMJOB)
every 15 minutes.
Heap size was 4925.375M (out of a maximum of 5120M) at 08:45, and the OS
took heap
I've obtained some heap and CPU numbers, taking data at 15 minute
intervals, heap from WRKJVMJOB and CPU from WRKACTJOB. In two days of
this, I didn't witness any crashes; I did witness a near-miss, in which
heap-in-use hit 5011.938M (out of 5120).
In discussion with our webapp developer (to
Monitored the thing all day, taking the CPU usage (via a WRKACTJOB) and
the current heap size and heap-in-use (via option 5 of a WRKJVMJOB)
every 15 minutes.
Heap size was 4925.375M (out of a maximum of 5120M) at 08:45, and the OS
took heap away over the course of the day, until it was down
Thomas, James,
On 2/6/23 17:00, Thomas Hoffmann (Speed4Trade GmbH) wrote:
Hello James,
-Ursprüngliche Nachricht-
Von: James H. H. Lampert
Gesendet: Montag, 6. Februar 2023 18:18
An: Tomcat Users List
Betreff: Re: AW: Having trouble with Tomcat crashes. Interesting memory
numbers
Hi,
> Hello James,
>
>> -Ursprüngliche Nachricht-
>> Von: James H. H. Lampert
>> Gesendet: Montag, 6. Februar 2023 18:18
>> An: Tomcat Users List
>> Betreff: Re: AW: Having trouble with Tomcat crashes. Interesting memory
>> numbers in Manager
&
Hello James,
> -Ursprüngliche Nachricht-
> Von: James H. H. Lampert
> Gesendet: Montag, 6. Februar 2023 18:18
> An: Tomcat Users List
> Betreff: Re: AW: Having trouble with Tomcat crashes. Interesting memory
> numbers in Manager
>
> Thanks, Herr Hoffmann.
13 matches
Mail list logo
