67 lines
3 KiB
Markdown
67 lines
3 KiB
Markdown
# Core Hub PostgreSQL capacity admission — 2026-08-20
|
|
|
|
Workplan: `RPF-WP-0021-T02`
|
|
|
|
Target: railiance01 `databases/platform-pg`
|
|
|
|
Mode: bounded live occupancy probe; no application data or credential value
|
|
was read or recorded.
|
|
|
|
## Question
|
|
|
|
Can Core Hub occupy the fourth and final declaration slot on `platform-pg`
|
|
without raising the current 1Gi pod limit or exceeding the explicit
|
|
100-connection aggregate?
|
|
|
|
The four declarations are `audit-core`, `tenant-engine`, `core-hub`, and the
|
|
counted isolation probe. Each workload declaration reserves 12 runtime plus
|
|
two migration connections; the probe's smaller allowance is deliberately
|
|
overstated here, making 56 a conservative declared-pool occupancy.
|
|
|
|
## Method
|
|
|
|
A temporary namespace labeled as a `platform-pg` client received the existing
|
|
bootstrap Secret by namespace-to-namespace projection without printing its
|
|
values. A separate client pod opened 56 sessions in four named groups of 14.
|
|
This kept client-process memory outside the database pod. The run then repeated
|
|
the same 56-session occupancy with 13 idle and one bounded active sort query
|
|
per group. The namespace and copied Secret were deleted after the run.
|
|
|
|
The active query materialized and sorted 100,000 generated integers, then held
|
|
the backend briefly for observation. It did not access an application table.
|
|
|
|
## Observations
|
|
|
|
| Signal | Before | Declared occupancy / observed peak |
|
|
| --- | ---: | ---: |
|
|
| Probe sessions | 0 | 56 (14 in each named group) |
|
|
| All PostgreSQL sessions | 9 | 65 |
|
|
| Active / idle sessions | 1 / 2 | 5 / 54 in the mixed run |
|
|
| PostgreSQL pod memory | 89Mi | **174Mi maximum observed** |
|
|
| PostgreSQL pod CPU | 7m | 82m during connection startup |
|
|
| Node memory | 6,210Mi / 16Gi | 6,342Mi / 16Gi (39%) |
|
|
| Node CPU | 470m | 2,002m transient startup peak |
|
|
|
|
The 85Mi database-pod increase across 56 opened backends is approximately
|
|
1.52Mi per connection at declared pool occupancy. That replaces ADR-0004's
|
|
unmeasured 10Mi literature estimate for idle/backend occupancy on this live
|
|
instance; it does not claim every query operator is limited to that figure.
|
|
|
|
The earlier quiet preflight observed 362Mi. Conservatively adding the entire
|
|
measured connection delta to that higher historical sample gives 447Mi, under
|
|
44% of the 1Gi limit. The four bounded active queries did not exceed the
|
|
174Mi maximum already observed during connection startup.
|
|
|
|
## Decision
|
|
|
|
Core Hub is accepted as the fourth declaration on `platform-pg` without a
|
|
memory-limit increase. It reaches the declared ceiling and does not authorize
|
|
a fifth declaration. The renderer must continue to reject any additional
|
|
consumer on this cell; the named overflow remains `platform-pg-2`.
|
|
|
|
This is capacity admission evidence, not a latency or workload-peak guarantee.
|
|
Core Hub is latency-critical beside batch `audit-core`, and community
|
|
PostgreSQL provides no service-class priority. The private shadow run must
|
|
therefore capture application health, query latency, pod memory, and backend
|
|
counts; material regression is a placement trigger, not a reason to reinterpret
|
|
this probe as stronger evidence.
|