YS
Ну отчеты вполне подойдет собирать.
Или не подойдёт, опять-таки (см. про "неверные"). От важности данных зависит. ;)
Size: a a a
2021 January 30
SS
про не консистентные данные в курсе. у нас еще и на файлухе хранятся данные. такчто транзакции это - не наш случай
YS
про не консистентные данные в курсе. у нас еще и на файлухе хранятся данные. такчто транзакции это - не наш случай
И зачем Вам postgres вообще, в таком случае...
Есть же "дешёвые" способы ускорения для подобных ситуаций.
Кстати, Вы все другие способы оптимизации уже исчерпали?
Есть же "дешёвые" способы ускорения для подобных ситуаций.
Кстати, Вы все другие способы оптимизации уже исчерпали?
SS
Вообще-то все наоборот должно быть.
Память постгрес без спросу не жрет. А жор CPU — это как правило следствие неэффективной работы.
Память постгрес без спросу не жрет. А жор CPU — это как правило следствие неэффективной работы.
а вот CPU и память жрет, как не в себя. возможно уже обсуждали здесь, память от всей виртуалки отъедает - приходиться саму виртуалку ребутать
SS
Yaroslav Schekin
И зачем Вам postgres вообще, в таком случае...
Есть же "дешёвые" способы ускорения для подобных ситуаций.
Кстати, Вы все другие способы оптимизации уже исчерпали?
Есть же "дешёвые" способы ускорения для подобных ситуаций.
Кстати, Вы все другие способы оптимизации уже исчерпали?
я бы и рад, но ограничен технически. у нас платформа Alfresco. на базе Postgres
SS
как оказалось Postgres тоже имеет свои больные места. как и любой продукт собсвенно. раньше с Ораклом работал
YS
как оказалось Postgres тоже имеет свои больные места. как и любой продукт собсвенно. раньше с Ораклом работал
Может, это у Alfresco есть больные места? ;)
Тем не менее, ещё раз, Вы все другие способы оптимизации уже исчерпали?
Тем не менее, ещё раз, Вы все другие способы оптимизации уже исчерпали?
SS
Yaroslav Schekin
Может, это у Alfresco есть больные места? ;)
Тем не менее, ещё раз, Вы все другие способы оптимизации уже исчерпали?
Тем не менее, ещё раз, Вы все другие способы оптимизации уже исчерпали?
ну как, по бэкэнду все оптимизировали. щас много доработок по приложению - и все упирается в запросы БД. СУБД Postgres
am
а вот CPU и память жрет, как не в себя. возможно уже обсуждали здесь, память от всей виртуалки отъедает - приходиться саму виртуалку ребутать
Гонять базу внутри виртуальной машины — очень, очень плохая практика.
am
Задумываться о мультимастере на том этапе, когда база в виртуальной машине — очень, очень глупо.
YS
ну как, по бэкэнду все оптимизировали. щас много доработок по приложению - и все упирается в запросы БД. СУБД Postgres
> СУБД Postgres
Так вот её Вы оптимизировали? Настраивали хотя бы (postgres и OS)?
Кстати, чем "думать", не легче ли "завалить" эту проблему "железом"?
Так вот её Вы оптимизировали? Настраивали хотя бы (postgres и OS)?
Кстати, чем "думать", не легче ли "завалить" эту проблему "железом"?
SS
Задумываться о мультимастере на том этапе, когда база в виртуальной машине — очень, очень глупо.
подскажите как сделать умно? не касаемо физики или виртуалки
m
подскажите как сделать умно? не касаемо физики или виртуалки
оптимизация сиквела, возможно и структуру
VY
Вообще-то все наоборот должно быть.
Память постгрес без спросу не жрет. А жор CPU — это как правило следствие неэффективной работы.
Память постгрес без спросу не жрет. А жор CPU — это как правило следствие неэффективной работы.
увы, жрёт 🙁
m
и да входных данных нет, куда что думать...
am
подскажите как сделать умно? не касаемо физики или виртуалки
А в чем, позвольте узнать, смысл «не касаться физики», когда у вас месячная зарплата больше суммы необходимого апгрейда? 2021 год на дворе, компустеры копейки стоют.
am
увы, жрёт 🙁
Как вашим постгресам удается отожрать больше, чем в postgresql.conf написано?
SS
Yaroslav Schekin
> СУБД Postgres
Так вот её Вы оптимизировали? Настраивали хотя бы (postgres и OS)?
Кстати, чем "думать", не легче ли "завалить" эту проблему "железом"?
Так вот её Вы оптимизировали? Настраивали хотя бы (postgres и OS)?
Кстати, чем "думать", не легче ли "завалить" эту проблему "железом"?
1. железа там хватает(по CPU/ОЗУ/диски)
2. саму БД оптимизировали, индексы есть. как минимум на все FK и тяжелые запросы
2. саму БД оптимизировали, индексы есть. как минимум на все FK и тяжелые запросы
SS
Как вашим постгресам удается отожрать больше, чем в postgresql.conf написано?
извиняюсь, у нас больше 250Gb СУБД отьедает
VY
Как вашим постгресам удается отожрать больше, чем в postgresql.conf написано?
work_mem — это рекомендательная настройка, а не лимит жёсткий. если я не ошибаюсь, HashJoin будет жрать столько, сколько сможет. надо поднимать детали, не помню.