- Порезанный
- 10 августа 2026 г. в 15:51 UTC
- Автор
- Kamo
- Обещать
- 2a1f5f4
Он работал меньше, чем CockroachDB, который он заменил - 20Gi / 6cpu против 32Gi/8cpu от CockroachDB - при необходимости больше, потому что YSQL работает отдельно PostgreSQL backend процесс для соединения поверх двигателя хранения. Три изменения: 1. tserver 12Gi/3cpu -> 24Gi/8cpu запросы, 20Gi/6cpu -> 48Gi/16cpu лимиты. Измерено 8323 дроссельных периода и ~19 минут кумулятивной остановки процессора на 6-ядерной крышке. Узел работает с 48 ядрами на 7%. 2. **************** заменяется явным -memory limit hard bytes. С hostNetwork флаг размером с YugabyteDB отключен 123 ГБ HOST, поэтому он считал, что у него 18,52 ГБ внутри группы 20 ГБ. Он также должен был содержать 9,9 ГБ бэкэндов PostgreSQL. Это был один трафик Скачок от убийства OOM. Теперь прикреплено: сервер 24 GiB, мастер 3 GiB. 3. --enable ysql conn mgr=true, так что мультиплекс клиентских соединений 150+ Управляемый пул вместо одного процесса. kernel.shmmni увеличен до 32768 на k1m1, как требуется диспетчеру соединения. После, над устоявшимся окном 240s: 0,00% дросселя (было 1,4% периодов), блочный потолок кэша 9,26 ГБ -> 12 ГБ, ограничение корневой памяти правильно 24 ГБ.