Re: Problem with Solr 7.7.2 after OOM
Glad you found the problem. The “core.properties” file, when found, assumes a core and tries to load it. Problem is that it must correspond to certain information in ZooKeeper and they can get out of sync. But there should be a message somewhere in the logs. I’ll give it a spin sometime and see if we can make figuring this out easier. Best, Erick > On Mar 9, 2020, at 01:07, Bunde Torsten wrote: > > 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 > 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 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 >> 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 >> totalusedfree shared buff/cache >> available >> Mem: 16426388 62793615034128 796 764324 >> 15488956 >>Swap:969960 0 969960 >>~# >> >> Torsten >> >> -Ursprüngliche Nachricht- >> Von: Jörn Franke >> 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 >>>> mailto:wun...@wunderwood.org>>: >>> >>> >>>> >>>>> On Mar 5, 2020, at 4:29 AM, Bunde Torsten >>>>> 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) >>> >>
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 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 > 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 > totalusedfree shared buff/cache > available > Mem: 16426388 62793615034128 796 764324 > 15488956 > Swap:969960 0 969960 > ~# > > Torsten > > -----Ursprüngliche Nachricht- > Von: Jörn Franke > 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 >> mailto:wun...@wunderwood.org>>: >> >> >>> >>>> On Mar 5, 2020, at 4:29 AM, Bunde Torsten >>>> 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) >> >
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 : > > >> >> On Mar 5, 2020, at 4:29 AM, Bunde Torsten 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 > http://observer.wunderwood.org/ (my blog) >
Re: Problem with Solr 7.7.2 after OOM
> On Mar 5, 2020, at 4:29 AM, Bunde Torsten 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 http://observer.wunderwood.org/ (my blog)
