pgpro 14. Налили те же самые данные. Данные обновляются раз в сутки sql скриптами. Размер в исходной порядка 600 Gb, в итоговой 900+. Вакуум работает, мертвых строк почти нет, индексов немного, дублей нет, количество строк такое же. Куда можно посмотреть, чтобы понять, почему размер больше?
Другое TOAST сжатие, другой fillfactor, 64bit xid. Возможно переход x32 => x64 и data alignment
От ксидов не должно распухнуть. Там система хранения хитрая.
а царь-то 64битный счетчик не настоящий!
Помню что там не всё так честно, но сходу не могу оченить насколько и как это повлияет на хранение
Врапэраунд на 32 битах зато настоящий.
спасибо, поизучаю
И всё равно в базе одновременно не должно быть более 2млрд жывых транзакцый. За что боролись!
Тех, которые ещё неизвестно -- закоммичены или нет. Более того, не просто жывых. Не обеспечивается надёжная работа, если хоть одна жывая транзакцыя старшэ 2млрд xid! В том числе PREPARED. Осталась одна PREPARED на разборки куда её девать -- и всё, счётчик тикает. При 50к tps -- через пол-суток появляется шанс, что в страницу надо записать значения xid с разницэй более 2млрд, и всё встаёт. Или дажэ не prepared, что там запросу-то 12 часов поработать.
Ну и запросы у вас! Чемодан денег в течении пары лет, думаю, поможет решить эту беду :)
Надо попробовать на свежей версии. Что-то такое делали вроде.
Думаю, при такой нагрузке сервер сложится минут за пять с активной транзакцией.
Мой рекорд — 2 минуты на 9.2
subtransactions использовали?
Нет. Просто штук шестьсот в секунду пишущих. Стоит забыть транзакцию на пару минут — все процессы встают на ожидании lwlocks.
этим можно и 16 положить, всем пофиг в сообщществе 😡😡😡😡😡
Обсуждают сегодня