Cases2 cases

1 to 2 of 2

1. IL-0312 Gadget's main Postgres did not start again after a restart to raise max_connections, and the platform went down

   Gadget2024

   Symptoms

   At 11:25 AM EST on 13 December 2024, Gadget restarted its main PostgreSQL server in place to raise max_connections. Postgres shut down but did not start again, and every request to Gadget applications failed, including frontend requests, GraphQL API requests, webhook processing and syncs.

   Service outageHigh latency

   Trigger

   An emergency in-place restart of the main Postgres server at 11:25 AM EST, decided at 11:00 AM, to raise max_connections, which Postgres cannot change without a full restart.

   Root cause

   Capacity exhaustion

   Component

   DatabaseLinux kernelDatabase proxy and connection pooler

   Contributing factor

   Unverified assumptionUnrepresentative stagingAutomation amplificationExcessive blast radius

   Detection

   The team carrying out the planned restart saw at 11:26 AM EST that Postgres had shut down and did not start again.

   Remediation

   • Restarted the database server with a hardware reset, which cleared the fragmented memory so Postgres could start
   • Provisioned almost 4x the compute after the autoscalers had scaled it down during the outage

   Action items

   • Use only the replica-failover approach for disruptive database operations such as restarts
   • Run a more aggressive capacity planning process before Black Friday / Cyber Monday, preparing for a 6x increase in load and proving it with load tests well in advance
   • Announce planned downtime ahead of time on the status page and community Discord, and make the operating procedures tell planned maintenance apart from service disruptions
   • Finish the database sharding project so apps can use different databases and configuration changes can go through canary and blue/green setups
   • Finish building a zero-downtime database failover system
   • Set much higher scaling floors on the compute autoscalers

   Lessons

   Gadget names three deeper factors. Choosing the in-place restart put the database into a state the team had not seen before and was not confident in. Capacity planning for Black Friday / Cyber Monday assumed a doubling of traffic instead of the almost 5x that came, so settings such as max_connections stopped fitting and had to be changed in an emergency instead of in a maintenance window practised in staging. And there was no way to test database configuration changes in a production-like environment: integration tests run against a synthetic Postgres database that never goes through the months of production load behind the memory fragmentation or the memory usage issues.

   View case
2. IL-0578 Static content behind an HAProxy load balancer in an OpenStack Octavia amphora was delayed by tens of seconds

   GMO Pepabo2020

   Symptoms

   In a GMO Pepabo production setup, delivery of static content was delayed by tens of seconds. The static content was served by nginx on upstream hosts behind HAProxy, which ran as the HTTP load balancer.

   High latency

   Root cause

   Capacity exhaustion

   Component

   HAProxyLinux kernelCloud load balancer

   Contributing factor

   Unreviewed defaults

   Remediation

   • Tuned net.ipv4.tcp_mem with sysctl on the HAProxy host, which ended the delays immediately

   Lessons

   On a VM with little RAM, the boot-time default of net.ipv4.tcp_mem can be low enough to push TCP into memory pressure. TCP out of memory is not the OOM killer, and net.ipv4.tcp_mem is a system-wide limit counted in pages, unlike the per-socket net.ipv4.tcp_rmem and net.ipv4.tcp_wmem counted in bytes. The values to watch are TCP mem in /proc/net/sockstat, press in /proc/net/protocols, and TCPMemoryPressures, TCPMemoryPressuresChrono and TCPAbortOnMemory in /proc/net/netstat.

   View case

By root cause1