[ 
https://issues.apache.org/jira/browse/SLING-11251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yuri Simione updated SLING-11251:
---------------------------------
    Description: I am testing performances of Apache Sling 12, configured with 
Oak Segment Store, started with the -Xmx4g parameter. I'm using a 
multi-threaded Python script (I tried with 30 threads down to 5 concurrent 
threads). The tool loads thousands of contents on new oak:Unstructured nodes 
using the standard {*}Sling POST servlet{*}. Before to start the import I 
stopped the Lucene bundle. Initially performances are good (about 200 new 
documents/sec). Soon, after the tool has ingested about 20k new nodes, the 
speed drops to a few nodes per second. I analyzed the JVM and noticed that the 
memory allocated for some threads grows by several GBs without ever going down 
(see attached images). If I stop the import tool, the situation does not 
change. The only way to solve this problem is to turn off the Sling instance 
and restart it. Is it normal for threads and in particular for the threads that 
implement the POST servlet, to acquire resources that are never released? I am 
available to reproduce this issue during a Teams / Google Meet.  (was: I am 
testing performances of Apache Sling 12, configured with Oak Segment Store, 
started with the -Xmx4g parameter. I'm using a multi-threaded Python script (I 
tried with 30 threads down to 5 concurrent threads). The tool loads thousands 
of contents on new oak:Unstructured nodes using the standard {*}Sling POST 
servlet{*}. Before to start the import I stopped the Lucene bundle. Initially 
performances are good (about 200 new documents/sec). Soon, after the tool has 
ingested about 20k new nodes, the speed drops to a few nodes per second. I 
analyzed the JVM and noticed that the memory allocated for some threads grows 
by several GBs without ever going down (see attached images). If I stop the 
import tool, the situation does not change. The only way to solve this problem 
is to turn off the Sling instance and restart it. Is it normal for threads and 
in particular for the threads that implement the POST servlet, to acquire 
resources that are never released? I am available to reproduce this issue 
during a Teams / Google Meet session. I am  )

> Apache Sling Post Servlet consumes too much resources during content ingestion
> ------------------------------------------------------------------------------
>
>                 Key: SLING-11251
>                 URL: https://issues.apache.org/jira/browse/SLING-11251
>             Project: Sling
>          Issue Type: Bug
>          Components: Servlets
>    Affects Versions: Starter 12
>         Environment: Mac OS, OpenJDK 1.8, Intel I9, 16gb RAM.
>            Reporter: Yuri Simione
>            Priority: Major
>         Attachments: image-2022-04-05-09-09-08-725.png, 
> image-2022-04-05-09-19-55-925.png
>
>
> I am testing performances of Apache Sling 12, configured with Oak Segment 
> Store, started with the -Xmx4g parameter. I'm using a multi-threaded Python 
> script (I tried with 30 threads down to 5 concurrent threads). The tool loads 
> thousands of contents on new oak:Unstructured nodes using the standard 
> {*}Sling POST servlet{*}. Before to start the import I stopped the Lucene 
> bundle. Initially performances are good (about 200 new documents/sec). Soon, 
> after the tool has ingested about 20k new nodes, the speed drops to a few 
> nodes per second. I analyzed the JVM and noticed that the memory allocated 
> for some threads grows by several GBs without ever going down (see attached 
> images). If I stop the import tool, the situation does not change. The only 
> way to solve this problem is to turn off the Sling instance and restart it. 
> Is it normal for threads and in particular for the threads that implement the 
> POST servlet, to acquire resources that are never released? I am available to 
> reproduce this issue during a Teams / Google Meet.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Reply via email to