On 29/10/2024 13:43, [email protected] wrote:
The gap between 3.14.0 and 5.1.0 is huge. There is also a Jetty change -
Jetty 12 is a fundamentally different architecture in its HTTP handling.
Does it mean that 5.1.0 requires much more meomory ?
In your case, it would seem so. From Jena, from Jetty, generally. Maybe
some internal caches are bigger - there could be lots of reasons from
the lifecycle of the memory releasing to man, many small things.
If you care, then bisect on versions to find out.
Are you using TDB1? TDB2?
Andy
Jaana
29.10.2024 14.13 EET Andy Seaborne <[email protected]> kirjoitti:
On 29/10/2024 11:12, [email protected] wrote:
Hi,
1. Check that the client is properly reading the whole of the response
9even if zero bytes) and is actually closing the connection, or
returning it to the connection pool. Check by running "netstat" to see
TCp connections ("-t" on *nix)
With netstat I saw several connections in TIME_WAIT state when running my test.
I think it means that the tcp-connections have been properly closed.
(the test being the large run?)
That's good - the important point is that there are not hundred's of
connections.
I understand that unproperly terminated tcp-connections could lead to error case
"Maximum lock count exceeded", but what could cause jena-fuseki 5.1.0 use much
more memory than 3.14 did with exactly same program code and input in the client side and
same data in the database ?
The gap between 3.14.0 and 5.1.0 is huge. There is also a Jetty change -
Jetty 12 is a fundamentally different architecture in its HTTP handling.
Andy
