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ó ügynökök
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.
Ö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:
- Database & Connection Pools (Most Common Real Bottleneck):
- Adding 20 application containers that each open a 20-connection pool (
400connections) will overwhelm a database configured formax_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.
- Adding 20 application containers that each open a 20-connection pool (
- 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-sizeset to ~75–80% of container memory limit so GC runs before the Linux kernel OOM-killer terminates the process with exit code137).
- Monitor container memory working set (
- 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.
- Check container CFS throttling (
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
