<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>ElasticSearch on A Place for Poor Examples</title>
    <link>https://blog.mattblair.co/tags/elasticsearch/</link>
    <description>Recent content in ElasticSearch on A Place for Poor Examples</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Wed, 21 Nov 2018 00:00:00 -0800</lastBuildDate>
    
	<atom:link href="https://blog.mattblair.co/tags/elasticsearch/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>ElasticSearch Perf - Highlighter Edition</title>
      <link>https://blog.mattblair.co/blog/20181121-elasticsearch-perf-work/</link>
      <pubDate>Wed, 21 Nov 2018 00:00:00 -0800</pubDate>
      
      <guid>https://blog.mattblair.co/blog/20181121-elasticsearch-perf-work/</guid>
      <description>Wanted to share the results of the work we&amp;rsquo;ve been doing to improve performance and stabilize our ES cluster.
Short Version: Changing sharding and &amp;ldquo;highlighting&amp;rdquo; strategies when doing FreeText searches dramatically impacts performance.
Long Version: We&amp;rsquo;ve been load testing various aspects of search to pinpoint features we use that create large amounts of load on the system. Our initial research pointed at normal searches and freetext searches as being problematic.</description>
    </item>
    
    <item>
      <title>ElasticSearch sharding work</title>
      <link>https://blog.mattblair.co/blog/20180305-elasticsearch-sharding-work/</link>
      <pubDate>Mon, 05 Mar 2018 00:00:00 -0800</pubDate>
      
      <guid>https://blog.mattblair.co/blog/20180305-elasticsearch-sharding-work/</guid>
      <description>Wanted to share some insights my team has found with changing sharding strategies for ElasticSearch (ES).
Today we moved 100% of my work&amp;rsquo;s search and autocomplete queries from a mutli-sharded index to a single-sharded index.
Short version: Reducing shard count reduces system load, CPU usage, mostly positive results on performance.
Medium version: In moving 100% of our searches and autocomplete queries from a mutli-sharded index to a single-sharded index, we saw drops in cluster load, queries generated by ES, and overall ES CPU usage.</description>
    </item>
    
    <item>
      <title>ElasticSearch Garbage Collection issues?</title>
      <link>https://blog.mattblair.co/blog/20170813-elasticsearch-garbage-collection/</link>
      <pubDate>Sun, 13 Aug 2017 00:00:00 -0700</pubDate>
      
      <guid>https://blog.mattblair.co/blog/20170813-elasticsearch-garbage-collection/</guid>
      <description>Seeing high garbage collection with ElasticSearch? My team was seeing periodic 300ms+ garbage collection pauses. We found out that we had misconfigured our ES instances.
If you&amp;rsquo;re encountering this, make sure you&amp;rsquo;ve disabled memory swapping:
https://www.elastic.co/guide/en/elasticsearch/reference/5.0/setup-configuration-memory.html</description>
    </item>
    
  </channel>
</rss>