Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Abandoned
-
4.9
-
None
-
None
-
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)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)
-
New
Description
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.