Cases2 cases

1 to 2 of 2

1. IL-0579 Portfolio search latency on Amazon OpenSearch 1.3 spiked to about 1 second after migrating from Elasticsearch 6.8

   Classi2026

   Symptoms

   After Classi moved the search engine behind its Portfolio feature from Elasticsearch 6.8 to Amazon OpenSearch Service 1.3, the team saw in post-migration metrics that search responses were sometimes much slower. Most searches returned normally, but latency jumped at a certain frequency.

   High latency

   Trigger

   The migration from Elasticsearch 6.8 to OpenSearch 1.3, with indices that had no explicit refresh_interval.

   Root cause

   Breaking change in an upgrade

   Component

   Elasticsearch or OpenSearch

   Contributing factor

   Unreviewed defaultsUnverified assumption

   Detection

   The team noticed latency spikes in metrics checked after the migration and compared the maximum search latency before and after the migration in Datadog APM.

   Remediation

   • Set refresh_interval explicitly to 3s, which sharply reduced the latency spikes
   • Set refresh_interval explicitly to 1s in production

   Lessons

   The took value in OpenSearch's responses was already large, which could have narrowed the investigation to OpenSearch sooner. The slow log and the Profile API alone did not find the cause; asking when searches became slow, instead of where, led to the fix. The same setting can behave differently between versions, so defaults have to be checked as well.

   View case
2. IL-0274 GitHub's code search Elasticsearch cluster hit near-100% CPU and rapid master elections; a restart found lost shards

   GitHub2013

   Symptoms

   On Thursday 24 January 2013 GitHub's exception tracking and monitoring systems detected a large spike in exceptions. Most of them were timeouts in code search queries and in the background jobs that update the code search indexes with data from new pushes, and the outage of the newly launched Code Search lasted into Friday 25 January.

   Intermittent timeoutsSustained high node CPUSplit brainData loss

   Trigger

   On 17 January GitHub upgraded the code search cluster from Elasticsearch 0.19.9 to 0.20.2 before launching Code Search publicly; the outage began on 24 January, after the public launch.

   Root cause

   Software defect

   Component

   Elasticsearch or OpenSearchLanguage runtime settings

   Contributing factor

   Unreviewed defaultsDeferred upgradesUntested changeIgnored early signalHarmful manual action

   Detection

   GitHub's exception tracking and monitoring systems detected a large spike in exceptions, mostly timeouts from code search queries and from the indexing background jobs.

   Remediation

   • Stopped the whole cluster and brought it back in maintenance mode, with shard allocation and rebalancing disabled
   • Brought in engineers from elasticsearch, the company, to review the cluster and its unallocatable shards
   • Upgraded Java and Elasticsearch and applied the recommended configuration through a Puppet topic branch and environment

   Action items

   • Provision a staging environment for the code search cluster to test infrastructure changes
   • Have the elasticsearch team audit the code search cluster configuration again in future

   Lessons

   The Elasticsearch upgrade was not tested enough on GitHub's infrastructure before it reached the code search cluster, partly because the cluster had no proper staging environment. For large clusters the elasticsearch team recommended equal minimum and maximum JVM heap through ES_HEAP_SIZE, at 50% of system RAM, starting recovery immediately instead of after recover_after_time, and configuring minimum_master_nodes so that paused nodes do not form their own clusters.

   View case

By root cause2