DP
Но накопить 2Тб временных файлов с ООМ раз в полчаса - почти невозможно.
легко
Size: a a a
2021 February 01
AB
Это должны быть едрические диски и ооочень странный паттерн нагрузки.
СГ
и гугл в своём облачном ПГ не чистит временные файлы от слова совсем?
VY
Но накопить 2Тб временных файлов с ООМ раз в полчаса - почти невозможно.
ты плохо стараешься!
VY
и гугл в своём облачном ПГ не чистит временные файлы от слова совсем?
они уходят когда запрос кончается же…
DP
Это должны быть едрические диски и ооочень странный паттерн нагрузки.
аналитики ручками на nvme, да
СГ
они уходят когда запрос кончается же…
а если ООМ произошёл во время запроса и ПГ автоматом не почистил (при успешном завершении)?
VY
а если ООМ произошёл во время запроса и ПГ автоматом не почистил (при успешном завершении)?
база перезапуститься, должен чистить
AB
тогда бы на графике места пила была бы как с памятью
AB
Если бы дело было во временных файлах. Я бы поставил литр пива на вал.
LM
max_connections 3k - для 12 ядер это овердофига. Не надо 3к коннектов делать, нужен пул коннектов.
Получается, уменьшив сейчас максимальное количество подключений до 800, есть вероятность избавится от OOM.
Правильно ли я понимаю, что если 1 воркер (читаем как одна машина) обрабатывает только одну транзакцию и ей требуется только одно подключение, то создавать у такой машины пул из коннектов в размере 20 — ошибка? Это, наверное, не играет особой роли, но использую SQLAlchemy (python), и создаю пул подключений с
Правильно ли я понимаю, что если 1 воркер (читаем как одна машина) обрабатывает только одну транзакцию и ей требуется только одно подключение, то создавать у такой машины пул из коннектов в размере 20 — ошибка? Это, наверное, не играет особой роли, но использую SQLAlchemy (python), и создаю пул подключений с
pool_size=20.AB
Надо ставить пулер перед базой, тогда соединение в базе будет использоваться только на время транзакции.
AB
Тогда можно держать пул по 100 соединений на бекенд приложения и не париться.
kp
гайз, привет.
такой вопрос
`SELECT count(*)
FROM (....)
LEFT JOIN ...
LEFT JOIN ...`
я верно понял, что лефт джоины можно вообще выкинуть отсюда, и они никогда не смогут повлиять на правильность счетчика? или путаю что-то?
такой вопрос
`SELECT count(*)
FROM (....)
LEFT JOIN ...
LEFT JOIN ...`
я верно понял, что лефт джоины можно вообще выкинуть отсюда, и они никогда не смогут повлиять на правильность счетчика? или путаю что-то?
LM
1 - это скорее всего копится WAL, надо проверить архивацию, слоты репликации, долгие транзакции и двухфазные транзакции.
Не подскажите, каким образом это можно проверить? Потому что из имеющихся возможностей, думаю, что это не выполнимо в рамках Datagrip, а через Cloud Shell не удаётся подключиться
AB
А у них на графиках нет размера вала?
D
гайз, привет.
такой вопрос
`SELECT count(*)
FROM (....)
LEFT JOIN ...
LEFT JOIN ...`
я верно понял, что лефт джоины можно вообще выкинуть отсюда, и они никогда не смогут повлиять на правильность счетчика? или путаю что-то?
такой вопрос
`SELECT count(*)
FROM (....)
LEFT JOIN ...
LEFT JOIN ...`
я верно понял, что лефт джоины можно вообще выкинуть отсюда, и они никогда не смогут повлиять на правильность счетчика? или путаю что-то?
Путаете
LM
kp
Путаете
поняль, пасиба
AB
select * from pg_stat_archiver ;select * from pg_stat_replication ;select * from pg_replication_slots ;select * from pg_prepared_xacts ;