Hello Erick, no there are no more OOMs and there were no errors in the logs. But the problem is solved now. The root cause seemed to be a duplicate core (two cores with the same name) because someone did a backup of an existing one ...
Thank you for your support! - Torsten -----Ursprüngliche Nachricht----- Von: Erick Erickson <erickerick...@gmail.com> Gesendet: Freitag, 6. März 2020 16:22 An: solr-user@lucene.apache.org Betreff: Re: Problem with Solr 7.7.2 after OOM Is it still giving you OOMs? That was the original problem statement. If not, then you need to look at your Solr logs to see what error is reported. NOTE: If you’re still getting OOMs, then there won’t be anything obvious in the logs. Best, Erick > On Mar 6, 2020, at 06:44, Bunde Torsten <t.bu...@htp.net> wrote: > > As an addendum: For me it looks as if the cores are simply not loaded, > although the configuration is correct and has not been changed (apart from > the enlargement of the heap). > > Torsten > > -----Ursprüngliche Nachricht----- > Von: Bunde Torsten <t.bu...@htp.net> > Gesendet: Freitag, 6. März 2020 09:33 > An: solr-user@lucene.apache.org > Betreff: AW: Problem with Solr 7.7.2 after OOM > > I set the heap to 8g but this doesn't have any effect and the problem is > still the same. > > ~# ps -eaf | grep solr > solr 3176 1 0 08:50 ? 00:00:00 /lib/systemd/systemd > --user > solr 3177 3176 0 08:50 ? 00:00:00 (sd-pam) > solr 3238 1 0 08:50 ? 00:00:06 java -server -Xms8g > -Xmx8g -XX:NewRatio=3 -XX:SurvivorRatio=4 -XX:TargetSurvivorRatio=90 > -XX:MaxTenuringThreshold=8 -XX:ConcGCThreads=4 -XX:ParallelGCThreads=4 > -XX:+CMSScavengeBeforeRemark -XX:PretenureSizeThreshold=64m > -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=50 > -XX:CMSMaxAbortablePrecleanTime=6000 -XX:+CMSParallelRemarkEnabled > -XX:+ParallelRefProcEnabled -verbose:gc > -Xlog:gc*:file=/var/solr/logs/solr_gc.log:time,uptime:filecount=9,filesize=20M > -Dsolr.log.dir=/var/solr/logs -Djetty.port=8983 -DSTOP.PORT=7983 > -DSTOP.KEY=solrrocks -Duser.timezone=UTC -Djetty.home=/opt/solr/server > -Dsolr.solr.home=/var/solr/data -Dsolr.data.home=/var/solr/data > -Dsolr.install.dir=/opt/solr > -Dsolr.default.confdir=/opt/solr/server/solr/configsets/_default/conf > -Dlog4j.configurationFile=file:/var/solr/log4j.properties -Xss256k > -Dsolr.disable.configEdit=true -Xss256k -Dsolr.jetty.https.port=8983 > -Dsolr.log.muteconsole -XX:OnOutOfMemoryError=/opt/solr/bin/oom_solr.sh 8983 > /var/solr/logs -jar start.jar --module=http > > ~# free > total used free shared buff/cache > available > Mem: 16426388 627936 15034128 796 764324 > 15488956 > Swap: 969960 0 969960 > ~# > > Torsten > > -----Ursprüngliche Nachricht----- > Von: Jörn Franke <jornfra...@gmail.com> > Gesendet: Donnerstag, 5. März 2020 17:31 > An: solr-user@lucene.apache.org > Betreff: Re: Problem with Solr 7.7.2 after OOM > > Just keep in mind that the total memory should be much more than the heap to > leverage Solr file caches. If you have 8 GB heap probably at least 16 gb > total memory make sense to be available on the machine . > >> Am 05.03.2020 um 16:58 schrieb Walter Underwood >> <wun...@wunderwood.org<mailto:wun...@wunderwood.org>>: >> >> >>> >>>> On Mar 5, 2020, at 4:29 AM, Bunde Torsten >>>> <t.bu...@htp.net<mailto:t.bu...@htp.net>> wrote: >>> >>> -Xms512m -Xmx512m >> >> Your heap is too small. Set this to -Xms8g -Xmx8g >> >> In solr.in.sh, that looks like this: >> >> SOLR_HEAP=8g >> >> wunder >> Walter Underwood >> wun...@wunderwood.org<mailto:wun...@wunderwood.org> >> http://observer.wunderwood.org/ (my blog) >> >
