From a5f4a3d19a8343bb090469b6263fb86e7fc77050 Mon Sep 17 00:00:00 2001 From: Nicholas Kumia Date: Wed, 27 Apr 2022 09:53:56 -0400 Subject: [PATCH 1/3] new: delay solr restarts for a long time There isn't a good CRON string to 'disable' restarts entirely. What this is says is restart on Jan 1 at 12:00AM whenever Jan 1 is a Friday. The next occurence of that is Jan 1, 2027 --- solr/service-config.json | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/solr/service-config.json b/solr/service-config.json index a02a4705..22f5cab6 100644 --- a/solr/service-config.json +++ b/solr/service-config.json @@ -4,5 +4,6 @@ "replicas": 6, "solrJavaMem": "-Xms7g -Xmx10g", "solrMem": "14G", - "solrCpu": "3250m" + "solrCpu": "3250m", + "restartCron": "0 0 1 1 5" } From 96d7a755ff47bec2f07411839b351d2912ce9247 Mon Sep 17 00:00:00 2001 From: Nicholas Kumia Date: Wed, 27 Apr 2022 10:11:28 -0400 Subject: [PATCH 2/3] new: decrease autoCommit time to reduce Java Memory This isn't an exact science and there are a lot of variables. The general idea is to commit documents to disk so that Java Memory can be more appropriately managed by Solr and not run out of it. If an solr index is going at 10 docs/sec, it will index 50 docs in 5 secs, if it's only going at 5 docs/sec, it will index 25 docs in 5 secs. Therefore, there isn't a good method for identifying how many documents will be indexed within a timeframe nor is it guaranteed to know the size of those documents. For our CKAN application, I'm more okay with this number, but it can be debated and retheorized. --- ckan/setup/solr/solrconfig.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ckan/setup/solr/solrconfig.xml b/ckan/setup/solr/solrconfig.xml index f76fca4a..f2ed415b 100644 --- a/ckan/setup/solr/solrconfig.xml +++ b/ckan/setup/solr/solrconfig.xml @@ -309,7 +309,7 @@ have some sort of hard autoCommit to limit the log size. --> - ${solr.autoCommit.maxTime:15000} + 5000 false @@ -320,7 +320,7 @@ --> - ${solr.autoSoftCommit.maxTime:-1} + 4000