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) >> >
