- Ya
- 10 Agosti 2026, 15:51 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 2a1f5f4
It was running on LESS than the CockroachDB it replaced -- 20Gi/6cpu against CockroachDB's 32Gi/8cpu -- while needing more, because YSQL runs a separate PostgreSQL backend process per connection on top of the storage engine. Three changes: 1. tserver 12Gi/3cpu -> 24Gi/8cpu requests, 20Gi/6cpu -> 48Gi/16cpu limits. Measured 8,323 throttled periods and ~19 minutes of cumulative CPU stall at the 6-core cap. The node runs 48 cores at 7%. 2. **************** replaced with an explicit --memory_limit_hard_bytes. With hostNetwork the flag sized YugabyteDB off the HOST's 123 GB, so it believed it had 18.52 GB inside a 20 GiB cgroup that also had to hold 9.9 GB of PostgreSQL backends. It was one traffic spike from an OOM kill. Now pinned: tserver 24 GiB, master 3 GiB. 3. --enable_ysql_conn_mgr=true, so 150+ client connections multiplex over a managed pool instead of one process each. kernel.shmmni raised to 32768 on k1m1 as the connection manager requires. After, over a settled 240s window: 0.00% throttled (was 1.4% of periods), block cache ceiling 9.26 GB -> 12 GB, root memory limit correctly 24 GB.