Incident Library
Applied filters ComponentModel hubSymptomDatabase overloadFactorNo headroomClear allEvery case under the filters, with no sentence; newest first.
Suggested filters Search, and the values found in your words appear here.

Graph

  • Root cause
  • Component
  • Symptom
  • Contributing factor
  • Case

Cases1 case

1 to 1 of 1

  1. IL-0024 Expensive cache-backed API calls and uncancelled database requests overloaded MongoDB and took the Hugging Face Hub down three times
    Hugging Face2024
    Symptoms

    At 08:45 CET on 22 April 2024 the Hugging Face Hub became unstable, and by 09:30 it was unresponsive. For most users the website was slow or could not be reached at all.

    Service outageHigh latencyDatabase overload
    Trigger

    Bursts of requests to revision endpoints that read heavily from the *_info_cache collections: a call to https://huggingface.co/api/datasets/lighteval/mmlu/revision/main rose sharply right before the first crash, and a call to https://huggingface.co/api/models/sentence-transformers/all-mpnet-base-v2/revision/main, a model with 300+ associated spaces, lined up with the crash at 21:30 on 23 April.

    Root cause
    Software defect
    Component
    Application databaseModel hubCluster autoscaler
    Contributing factor
    No headroomRetry stormOverlapping failures
    Detection

    Instability started at 08:45 on 22 April and the Hub was unresponsive by 09:30; the team followed MongoDB Atlas metrics and a MongoDB support case. The root cause was found days later from a new graph of requests per URL.

    Remediation
    • Added a firewall rule blocking all requests with a Java/* user agent
    • Disabled the quicksearch feature on the Hub
    • Scaled the MongoDB Atlas cluster by hand from tier 2 to tier 3
    • Switched the Hub to maintenance mode with a 503 page through AWS WAF and blocked incoming traffic
    • Scaled all Hub pods down to 0 and brought them back
    • Set an aggressive rate limit
    • Added timeouts to requests and reworked database queries that were slow or returned large bodies
    Action items
    • Add timeouts to requests based on their usual completion time
    • Optimise requests that took too long or returned a large body, and rework poorly designed database queries
    • Remove old unused indexes from the database
    • Build new dashboards and monitoring metrics
    • Move the *_info_cache collections to Redis
    • Make it possible to abort any database request when the client aborts theirs
    Lessons

    Finding the root cause took two to three days: the existing charts did not show it, and a per-URL request breakdown did. Not cancelling database work when a client goes away turns a strained database into a thundering herd. A close inspection of the database exposed architectural flaws and bottlenecks, such as a collection with large unused indexes, and taught the team which metrics need closer watching to anticipate crashes. Unrelated failures happening at the same time added to the stress and made restoring service harder.

    View case
Check your cluster for this

This case involves Cluster autoscaler and Application database. kubegap audits a Kubernetes cluster for gaps like these, read-only, from Claude Code or Codex; its checks cite public reports like the ones in this library.

Open kubegap

By root cause1

Software defect1 case

Component
Cluster autoscalerApplication databaseModel hub
Contributing factor
No headroomOverlapping failuresRetry storm
Organisation
Hugging Face
  1. IL-0024 Expensive cache-backed API calls and uncancelled database requests overloaded MongoDB and took the Hugging Face Hub down three times
    Hugging Face2024