<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Do you have evidence that on-heap usage has gotten worse in the
rewrite? Let's leave aside the cryptic GC failures, as I don't
think they have directly anything to do with memory segment (given
you said you are not using JNI nor FFM - maybe some library you
depend on is... hard to say).</p>
<p>I suspect it's probably hard to say if on-heap is better or
worse, given that before the DB storage was on-heap, and now it's
off-heap. But if the storage is off-heap, why is there 4GB on-heap
data?</p>
<p>Anyway, my suggestion is to keep chipping away at the problem
(not now, when you have the time and energy of course!) until you
can e.g. reproduce what you are seeing with something a bit
simpler than the full application. When we get there, we'd
probably be in a better position to help. At this point in times
there seem to be too many variables that are influencing the
discussion, and it's not clear to me that going down the "memory
segment is the culprit" route will be helpful. The rewrite clearly
did something (bad) to the overall performance of the application
- but I don't think you have 4GB of small segment wrappers around
heap arrays (or, if that's the case, you have bigger problems
going on :-) ).</p>
<p>I'm also not 100% sure that the assumption: there's more GC
activity, so that is the explanation of the 3x slowdown is valid
(again, we need a smoking gun). Sometimes you get more GC, but
that doesn't affect things too much - because a lot of the objects
are short-lived and allocation/deallocation in the TLAB is so
cheap. Also, by moving data off-heap you should have (at least in
principle) have reduced the load on the GC somewhat.<br>
</p>
<p>Maurizio<br>
</p>
<div class="moz-cite-prefix">On 16/09/2024 21:40, Johannes
Lichtenberger wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAGXNUvaqDAO26WB6=e1mAXV6NOLJ2e0a=nppguDV0AfCmE2nKQ@mail.gmail.com">
<div dir="auto">
<div dir="ltr">It stays at 4Gb max (I've configured 8Gb max, so
this should be OK, but always Evacuation Failure GCs).
Currently I don't have the energy to look further into it due
to a cold, but I could upload the 3,8Gb JSON file somewhere if
needed for the test to run, if that helps...</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Am Mo., 16. Sept. 2024 um
19:03 Uhr schrieb Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" target="_blank" rel="noreferrer" moz-do-not-send="true" class="moz-txt-link-freetext">maurizio.cimadamore@oracle.com</a>>:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 16/09/2024 17:49, Johannes Lichtenberger wrote:<br>
> but I thought it shouldn't be that runtime for shredding
a resource <br>
> (impirting JSON data) suddenly is 3x worse even now in
the middle of a <br>
> bigger refactoring in my spare time<br>
<br>
Ok, so there's a new bullet:<br>
<br>
* the _execution time_ (e.g. throughput) with the memory
segment version <br>
is now 3x slower than w/o memory segment<br>
<br>
What does the memory usage look like? I understand that you
see issues <br>
with GC failures due to "pinning" - but does the overall heap
usage seem <br>
ok? Or has heap usage also increased?<br>
<br>
Maurizio<br>
<br>
</blockquote>
</div>
</blockquote>
</body>
</html>