SS
оперативки
1. железа там хватает(по CPU/ОЗУ/диски)
2. саму БД оптимизировали, индексы есть. как минимум на все FK и тяжелые запросы
Size: a a a
2021 January 30
YS
Если бы хватало — проблем бы почти наверняка не было.
А какое там "железо", примерно?
И почему Вы игнорируете вопрос про настройку (tuninig) PostgreSQL и OS?
А какое там "железо", примерно?
И почему Вы игнорируете вопрос про настройку (tuninig) PostgreSQL и OS?
SS
и когда нагрузка на СУБД на сервере СУБД свя оперативка отъедается
am
Yaroslav Schekin
Если бы хватало — проблем бы почти наверняка не было.
А какое там "железо", примерно?
И почему Вы игнорируете вопрос про настройку (tuninig) PostgreSQL и OS?
А какое там "железо", примерно?
И почему Вы игнорируете вопрос про настройку (tuninig) PostgreSQL и OS?
А каким тюнингом можно угомонить жор CPU? Там только с конкретной базой да запросами разбираться.
m
и когда нагрузка на СУБД на сервере СУБД свя оперативка отъедается
на своп лезет?
YS
А каким тюнингом можно угомонить жор CPU? Там только с конкретной базой да запросами разбираться.
Там же дело не только в нём. А так — именно по CPU я не знаю универсального рецепта, разбираться нужно.
VY
А каким тюнингом можно угомонить жор CPU? Там только с конкретной базой да запросами разбираться.
ну иногда база решает гнать запросы по “левому” индексу, исходя из линейного распределения данных (статистика она такая).
и, к примеру, надо
и, к примеру, надо
ORDER BY id заменить на ORDER BY id+0, что не меняет логики запроса, но вырубает индекс по id. ну или создать нужный составной индекс под запрос…am
Короче, какой-то сплошной неконструктив в этом чате. Давайте лучше заключим договор с любым разработчиком мультимастера и будем получать по 10% за каждого приведенного клиента.
YS
и когда нагрузка на СУБД на сервере СУБД свя оперативка отъедается
И это прекрасно — она там не для того, чтобы простаивать. ;)
В общем, отвечали бы Вы на вопросы... а то Вы как-то зациклились на поисках "альтернативных" решений, мне кажется.
В общем, отвечали бы Вы на вопросы... а то Вы как-то зациклились на поисках "альтернативных" решений, мне кажется.
SS
Yaroslav Schekin
Если бы хватало — проблем бы почти наверняка не было.
А какое там "железо", примерно?
И почему Вы игнорируете вопрос про настройку (tuninig) PostgreSQL и OS?
А какое там "железо", примерно?
И почему Вы игнорируете вопрос про настройку (tuninig) PostgreSQL и OS?
линукс виртуалки. x64. Postgres ессно тюнили. на сервер СУБД выделено 128GB оперативки. но иногда даже этого нехватает и postgres всю память съедает
VY
и когда нагрузка на СУБД на сервере СУБД свя оперативка отъедается
вам нужен мониторинг + ТОП запросов (по CPU, по IO) и курить топовые запросы
am
ну иногда база решает гнать запросы по “левому” индексу, исходя из линейного распределения данных (статистика она такая).
и, к примеру, надо
и, к примеру, надо
ORDER BY id заменить на ORDER BY id+0, что не меняет логики запроса, но вырубает индекс по id. ну или создать нужный составной индекс под запрос…Так это ж не «тюнингом» (слово-то какое, тьфу!) решается, а работой по конкретным запросам.
VY
Так это ж не «тюнингом» (слово-то какое, тьфу!) решается, а работой по конкретным запросам.
а это тоже часть тюнинга. не всё можно решить настройками
SS
Yaroslav Schekin
И это прекрасно — она там не для того, чтобы простаивать. ;)
В общем, отвечали бы Вы на вопросы... а то Вы как-то зациклились на поисках "альтернативных" решений, мне кажется.
В общем, отвечали бы Вы на вопросы... а то Вы как-то зациклились на поисках "альтернативных" решений, мне кажется.
вроде на все вопросы ответил, если чтото пропустил извиняюсь
YS
линукс виртуалки. x64. Postgres ессно тюнили. на сервер СУБД выделено 128GB оперативки. но иногда даже этого нехватает и postgres всю память съедает
> Postgres ессно тюнили.
Показать настройки можете?
> на сервер СУБД выделено 128GB оперативки
Это немного (вот лет десять или более назад это было бы прилично, если не путаю — плохая у меня память на эти вещи).
Т.е. "заваливать железом" можно ещё долго.
Показать настройки можете?
> на сервер СУБД выделено 128GB оперативки
Это немного (вот лет десять или более назад это было бы прилично, если не путаю — плохая у меня память на эти вещи).
Т.е. "заваливать железом" можно ещё долго.
YS
вроде на все вопросы ответил, если чтото пропустил извиняюсь
А какая OS? Её настраивали (по документации)?
И я что-то версию PostgreSQL забыл спросить. ;)
И я что-то версию PostgreSQL забыл спросить. ;)
am
work_mem — это рекомендательная настройка, а не лимит жёсткий. если я не ошибаюсь, HashJoin будет жрать столько, сколько сможет. надо поднимать детали, не помню.
Наверное, я слишком скучно живу, и слишком скучные запросы делаю. Никогда вообще ничего подобного не замечал. Иногда долгий
SELECT пишет гигабайты ерунды на диск, но не более того.YS
Наверное, я слишком скучно живу, и слишком скучные запросы делаю. Никогда вообще ничего подобного не замечал. Иногда долгий
SELECT пишет гигабайты ерунды на диск, но не более того.Хмм... мне кажется, или это уже тут объясняли именно Вам?
am
Про work_mem мне уже второй раз рассказывают. да.
am
И про то, что надо параллельные запросы в полночь в полнолуние запускать, и тогда точно отожрет. Но у меня на графиках использования памяти вечно скука смертная.