proomt

Search

Search posts, papers, and topics

All posts

Hacker News front page13 min readintermediate

Saving another 100TB of RAM with math (and Rust)

Summary

Cloudflare reduced the memory footprint of its Pingora Backend Router by re‑examining the consistent‑hashing implementation in the pingora‑ketama library. By increasing the number of virtual hash points per server from the default 1 to the standard 160 (and applying weighted hashing based on disk capacity), they cut the per‑node overhead enough to reclaim >100 TB of RAM across the fleet. The post…

  • Consistent hashing with a single hash per node yields a coefficient of variation ≈ √((N‑1)/(N+1)), i.e. ~99 % imbalance for 100 nodes.
  • Using k virtual hash points per node reduces the CV to √((N‑1)/(N+1))/√k; with the default 160 points the CV drops to ~8 %.
  • Weighting hash points by a server’s storage capacity lets the algorithm respect heterogeneous resources while preserving the error‑margin benefit of multiple points.
  • In Rust, the change boiled down to adjusting the `PINGORA_KETAMA_DEFAULT_REPLICAS` constant and ensuring the weighted replica count is computed at startup, eliminating a per‑request allocation of large lookup tables.

At massive scale, even a few megabytes per process become gigabytes of hardware cost. The post demonstrates how a well‑understood statistical property (law of large numbers) can be applied to a production‑grade load balancer to achieve measurable cost savings without changing external behavior. The…

7/10

Related reading

  1. Lyft Moves Streaming Fleet to Apache Flink Kubernetes Operator

    Lyft migrated its hundreds of production Flink jobs from a home‑grown Kubernetes operator to the Apache Flink Kubernetes Operator, gaining last‑state upgrades, in‑place autoscaling, and resource autotuning while cutting typical deployment downtime to 3–6 minutes. The switch also enabled Flink 1.19 features, saved millions in over‑provisioned capacity, and required workload‑specific scaling strate…

    InfoQinfoq.com3 min
  2. Accelerating the borderless Lakehouse: Announcing preview of cross-cloud caching

    Google Cloud previewed cross‑cloud caching for its Borderless Lakehouse. The feature caches sub‑file Parquet blocks in Google Cloud, encrypts them with GMEK, isolates cache per tenant/region, and validates freshness via metadata checks. In tests it can reduce cross‑cloud data transfer to <5% of the original size, lowering query latency and cost for Iceberg tables stored in other clouds. BigQuery…

    Google Cloud Bloggoogle.com3 minrelease
  3. When scanners miss the attack: how Cloudflare Client-Side Security protects storefronts

    Cloudflare’s Page Shield uses a graph‑neural‑network (GNN) to model JavaScript as a syntax‑tree graph, followed by a lightweight LLM for second‑opinion triage and an ensemble of frontier models for deep analysis. This pipeline caught eight malicious payloads across four distinct affiliate‑theft and backdoor techniques that traditional scanners missed, demonstrating the need for runtime, behavior‑…

    Cloudflarecloudflare.com21 minHN2
  4. Faster Maps: Chasing Swiss Speed

    ParparVM’s HashMap suffered catastrophic miss latency due to linear probing on dense integer keys. By adopting CPython‑style perturbed probing (Swiss‑table style) and extending tagged immediate values to more primitives, miss latency dropped from 32 s to ~45 ms, allocation pressure fell dramatically, and overall performance stayed roughly flat despite a modest hit‑time slowdown.

    CodeName Onecodenameone.com8 min