FIX: use 1GB for FTS max JVM memory usage #3355
Conversation
Signed-off-by: Vincent Delbar <vincent.delbar@latelescop.fr>
szaimen
added
3. to review
It is java, it will always use more ram than you specify... |
|
I don't know may be I tried several things, this change is the only one that made it work |
Indeed I just checked with top the java process is using 2GB, what the hell ? |
| @@ -612,7 +612,7 @@ | |||
| "internal_port": "9200", | |||
| "environment": [ | |||
| "TZ=%TIMEZONE%", | |||
| "ES_JAVA_OPTS=-Xms512M -Xmx512M", | |||
| "ES_JAVA_OPTS=-Xms512M -Xmx1024M", | |||
There was a problem hiding this comment.
I would be fine with this. Wdyt @Zoey2936?
| "ES_JAVA_OPTS=-Xms512M -Xmx1024M", | |
| "ES_JAVA_OPTS=-Xms1024M -Xmx1024M", |
There was a problem hiding this comment.
we can do this, but it will use a lot of ram
There was a problem hiding this comment.
@szaimen I don't understand why you would rewrite this with the same value for initial and max heap size, I've always seen this options with Xms < Xmx.
I'm almost sure this is the source of the problem, when java cannot allocate more than initial (reserved) size, it seems elasticsearch cannot spawn new nodes for indexing.
I could try -Xms256M -Xmx512M but it's very long to re-index...
I have a lot of files and groupfolders, but I don't think I need 1GB or 2GB of RAM to do this.
I don't know what is exactly the memory usage printed by occ, but I've never seen it exceed 200 or 300MB.
There was a problem hiding this comment.
we can do this, but it will use a lot of ram
To avoid high memory usage even when not that much is needed, why not use something like -Xms64m -Xmx1024M instead ?
There was a problem hiding this comment.
I have another idea : may be I should close this, in favor of another issue for feature request :
a ES_JAVA_OPTS env that can be set in the compose file ?
In my case the problem may also be related to groupfolders, which fulltextsearch does not seems understand really well and I wouldn't be surprised if files are indexed as many times as they are users. It's not clears from the logs if there's just an entry per user (file path) or if file is actually parsed every time.
But I don't think this high memory usage is normal in regard to the number of files I have to index here.
There was a problem hiding this comment.
Hm... 512m and 512m are the values recommended in https://github.com/R0Wi/elasticsearch-nextcloud-docker#how-to-use-this so not sure increasing the value is the way to go. However I would really like to not introduce a variable here. So maybe the fulltextsearch app needs to be improved instead in order to improve the handling of groupfolders?
There was a problem hiding this comment.
As you want, but if I were you I wouldn't take anything for granted except if it comes from the official ElasticSearch docs.
But if this does not happen for users without groupfolders, I agree here isn't the place to make that change.
Yet I don't understand why want to avoid a variable, since this setting has to be set according to number of files to scan, you might see this exception pop in future issues !
At least I believe it should be added to the docs which file has to be modified (containers.json) in order to give it more RAM. This is not a problem if the container then re-run with Xmx512M, because it's only happening during a first run - or manual occ fulltextsearch:index.
The container is now using ~1.2GB, and the app is working as expected.
This java memory thing is a mess (I don't understand how it could go up to 3GB with a -Xmx of 1024M).
There was a problem hiding this comment.
Well I just gave a quick look at ES docs, they show the following example for memory settings in docker. So yeah I guess my first argument is broken ^^ they also use same Xmx and Xms here.
docker run -e ES_JAVA_OPTS="-Xms1g -Xmx1g" -e ENROLLMENT_TOKEN="<token>" --name es01 -p 9200:9200 --net elastic -it docker.elastic.co/elasticsearch/elasticsearch:8.9.2
But also :
The ES_JAVA_OPTS variable overrides all other JVM options. We do not recommend using ES_JAVA_OPTS in production.
There was a problem hiding this comment.
running java without xms/xmx will make java to eat basically all ram
There was a problem hiding this comment.
Yes, I'm confused by this statement, if we run in docker, isn't it for ES java process to be alone in its env ? So I don't see how ES_JAVA_OPTS could override other JVM options.. how many JVM processes are there in this container
Edit: I read it wrong. So this variable is erasing every other options for this JVM... it seems a bad idea, unless this variable is empty in the first place ?
Edit 2: I checked, it's exactly the same than what is in the current main.
Fix for #3354, this is the change I had to make in order for FTS to complete first indexing successfully (following this discussion to re-index).
Also, in the docs it is stated that FTS requires 1GB additional RAM, so I guess this -Xmx512M was not intended ?
Fix #3373