[
https://issues.apache.org/jira/browse/LUCENE-5862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Heisey updated LUCENE-5862:
---------------------------------
Attachment: LUCENE-5862-infostreams.zip
By listing one of the files for all segments (*.fdt), restarting Solr, and
doing the list again, I discovered which segments were extra for one of those
shards. They were the _cyu and _cys segments in the "s2build" core.
Attaching the INFOSTREAM from the core named s2build (which had the problem)
and s1build (which did not show the problem). I couldn't attach the solr log,
because the compressed file was larger than the 10MB attachment limit. I've
put it in my dropbox:
https://www.dropbox.com/s/sg65prhdgh0i5d1/LUCENE-5862-solr-log.zip
If these logs are not sufficient, let me know exactly what's needed (and how to
turn it on if that's not obvious), and I'll do more rebuilds until the problem
reproduces again.
> Old segments not deleted on merge
> ---------------------------------
>
> Key: LUCENE-5862
> URL: https://issues.apache.org/jira/browse/LUCENE-5862
> Project: Lucene - Core
> Issue Type: Bug
> Affects Versions: 4.9
> Environment: Linux bigindy5 3.14.1-1.el6.elrepo.x86_64 #1 SMP Mon Apr
> 14 19:29:19 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.7.0_55"
> Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)
> [root@bigindy5 s5_0]# cat /etc/redhat-release
> CentOS release 6.5 (Final)
> Reporter: Shawn Heisey
> Fix For: 5.0, 4.10
>
> Attachments: LUCENE-5862-infostreams.zip
>
>
> After a full rebuild with the dataimport handler on a Solr install upgraded
> to Solr 4.9.0, I ended up with an index that was considerably larger than the
> one it replaced (built by 4.7.2), 28GB instead of 20GB. I also upgraded a
> third-party component at the same time, to a version which has been tested
> with Solr 4.9.0. The config didn't change at all. Optimizing the index did
> not shrink it.
> At first I thought there must have been something different about the way the
> new version worked, or possibly a change/bug in the third-party component.
> After looking deeper, I discovered that the optimization process had created
> one segment that was 20GB in size, but there were also a number of other
> segments on the disk, all of which were several hours older than the large
> segment. Another optimize created a new segment of 20GB, and the previous
> segment of 20GB was deleted, but the older segments remained.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
