# Lucene Segments and Performance **URL:** \ **Category:** Elasticsearch\ **Created:** [December 24, 2011, 5:08pm UTC](https://discuss.elastic.co/t/lucene-segments-and-performance/6234 "2011-12-24T17:08:11Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![phobos182](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/phobos182/32/3011_2.png) [@phobos182](https://discuss.elastic.co/u/phobos182)\ **Post date:** [December 24, 2011, 5:08pm UTC](https://discuss.elastic.co/t/lucene-segments-and-performance/6234/1 "2011-12-24T17:08:11Z")
I have some old indexes that are not being updated anymore. They are read-only, and I'm looking to optimize the segments for the best performance. I have heard conflicting arguments. Some argue that you should have as many Segments as CPU's, as searching segments is a multi-threaded operation. It will be more expensive in terms of CPU / Memory cost, but it will be faster. Others argue that if it's read-only, it should only have one segment. As it reduces unique terms / memory cost, and it only takes one search instead of say 8 on an 8-CPU system to get a result back. For Lucene 3.5.0 (Which ES is on), and considering that ES is already sharded (EX: 16 shards) does it make sense to just have 1 segment? For example. If my index has 16 shards. And in each shard there are 8 segments. To search that one index would be 128 search operations. If each shard had one segment, it would be 16 search operations. Which one provides the best performance? ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [December 24, 2011, 7:13pm UTC](https://discuss.elastic.co/t/lucene-segments-and-performance/6234/2 "2011-12-24T19:13:23Z")
Search on a single Lucene index across segments is not parallelized (you can do it in Lucene, I find little use for it in a system like elasticsearch). So, yes, going down to less segments will reduce the index size, memory size, and improve performance. Note, going down to a single segment means rewriting the whole shard (and all shards in that index) which can be expensive. On Sat, Dec 24, 2011 at 7:08 PM, phobos182 [phobos182@gmail.com](mailto:phobos182@gmail.com) wrote: > I have some old indexes that are not being updated anymore. They are > read-only, and I'm looking to optimize the segments for the best > performance. > > I have heard conflicting arguments. Some argue that you should have as many > Segments as CPU's, as searching segments is a multi-threaded operation. It > will be more expensive in terms of CPU / Memory cost, but it will be > faster. > > Others argue that if it's read-only, it should only have one segment. As it > reduces unique terms / memory cost, and it only takes one search instead of > say 8 on an 8-CPU system to get a result back. > > For Lucene 3.5.0 (Which ES is on), and considering that ES is already > sharded (EX: 16 shards) does it make sense to just have 1 segment? > > For example. If my index has 16 shards. And in each shard there are 8 > segments. To search that one index would be 128 search operations. If each > shard had one segment, it would be 16 search operations. Which one provides > the best performance? > > -- > View this message in context: > [http://elasticsearch-users.115913.n3.nabble.com/Lucene-Segments-and-Performance-tp3610793p3610793.html](http://elasticsearch-users.115913.n3.nabble.com/Lucene-Segments-and-Performance-tp3610793p3610793.html) > Sent from the Elasticsearch Users mailing list archive at [Nabble.com](http://Nabble.com). ---
**Author:** ![Michael\_Sander](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/michael_sander/32/838_2.png) [@Michael\_Sander](https://discuss.elastic.co/u/Michael_Sander)\ **Post date:** [February 13, 2017, 11:40am UTC](https://discuss.elastic.co/t/lucene-segments-and-performance/6234/3 "2017-02-13T11:40:10Z")
Is the answer in this old thread still true? Specifically, is it true that "a single Lucene index across segments is **not** parallelized"? Also, related question: Is it always better to merge all segments down to a single segment if you are willing to wait for the merge? Are there some cases where multiple segments are desirable? The [documentation suggests using five segments](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-update-settings.html#bulk), but does not say why. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 5, 2017, 10:03pm UTC](https://discuss.elastic.co/t/lucene-segments-and-performance/6234/4 "2017-07-05T22:03:18Z")