← Közös mobilalkalmazás-alapok csapata adatlapja

Skill · 1.0.0 verzió

Infrastruktúra-kapacitás és költségek

Valós kapcsolat-, memória- és processzorkorlátból magyarázza a kapacitást és skálázási költséget puszta szerverdarabszám helyett.

capacity-infrastructure-costs

Ezt a skillt használó csapattagok

Nézd meg, miben segít

Mikor hasznos?

Akkor használd, ha több szerver mellett nő a költség, de a lassulás megmarad.

Miben segít neked?

  • Feltárja az adatbázis-kapcsolatkorlátot, memóriahiányt és processzorfojtást.
  • A példányszámot és kapcsolatkészletet az alatta lévő szolgáltatás kapacitásához igazítja.
  • A mért szűk keresztmetszethez skálázási és költségkorlátot javasol.

Például ezt kérheted

Magyarázd el, miért meríti ki a konténerszám duplázása az adatbázis-kapcsolatokat, és javasolj korlátokat. Számítsd össze minden példány és feldolgozó kapcsolatkeretét. Adj tesztelt poolkorlátot, és mutasd meg a megmaradó adatbázis-kapacitást.

Részletes dokumentáció

Itt a skill eredeti útmutatóját, példáit és ellenőrzési szempontjait olvashatod az eredeti nyelven.

Részletek…Összecsukás

Capacity & Infrastructure Costs

Right-size infrastructure from measured workload characteristics rather than guesswork, and guard every auto-scaling or pay-per-use resource with hard upper ceilings so a traffic spike, retry loop, or runaway job cannot cause an outage or a billing shock.

Bottleneck Diagnosis (The USE Method)

Before scaling up hardware or adding replicas, check Utilization, Saturation, and Errors for every resource along the request path:

  1. Database & Connection Pools (Most Common Real Bottleneck):
    • Adding 20 application containers that each open a 20-connection pool (400 connections) will overwhelm a database configured for max_connections = 100.
    • Size per-instance pool limits so $\text{max_instances} \times \text{pool_size} + \text{admin_reserve} < \text{DB max_connections}$, or place a connection pooler (PgBouncer / RDS Proxy / Supavisor) in front of the database.
  2. Memory Working Set vs. Limits (OOMKills):
    • Monitor container memory working set (container_memory_working_set_bytes) and language runtime heap limits (e.g., Node --max-old-space-size set to ~75–80% of container memory limit so GC runs before the Linux kernel OOM-killer terminates the process with exit code 137).
  3. CPU Throttling vs. Average CPU:
    • Check container CFS throttling (container_cpu_cfs_throttled_periods_total) and event-loop lag alongside average CPU utilization; bursty workloads can experience severe tail-latency spikes even at 40% average CPU if limits are overly tight.

Safe Autoscaling & Cost Guardrails

Cost / Capacity Risk Mitigation to Enforce
Unbounded Horizontal Autoscaling Always set a hard maxReplicas / max_instances cap paired with edge rate-limiting and queue backpressure so a DDoS or retry storm cannot spin up hundreds of instances.
Network Egress & NAT Gateway Multipliers Serve static assets, media, and large downloads through a CDN with proper Cache-Control headers (immutable for fingerprinted assets); use VPC endpoints / private networking for high-volume internal storage/DB traffic.
Log, Trace & Metric Cardinality Explosion Never put unbounded user IDs, URLs with query strings, or UUIDs into metric labels (Prometheus/Datadog tag cardinality explosion). Sample high-volume debug/info traces and set retention TTLs on log buckets.
Orphaned Storage & Preview Environments Automate teardown of ephemeral PR preview environments, unattached block volumes, old container registry tags, and expired build artifacts via lifecycle rules.

When proposing an infrastructure or scaling change, state the expected capacity headroom, failure mode at ceiling, and estimated monthly cost delta explicitly.

Csomagban lévő fájlok 1

  • SKILL.md