Size: a a a

pgsql – PostgreSQL

2020 June 03

RU

Roman Usachev in pgsql – PostgreSQL
это новый проект, базу гоняют на мощной машине, условно, домашний говносервер. Ее надо тут привести в порядок, прогнать все злые запросы с полным перебором, что бы потом только в режиме обновления дергать только по обновившимся данным. она в итоге сольется куда-нить на хецнер или хз куда. прод скорее всего будет слабее чем то что есть сейчас
источник

RU

Roman Usachev in pgsql – PostgreSQL
из тех гигабайтов мусора в виде xml-тегов вытаскиваются данные необходимые для быстрого поиска в отдельные таблички
источник

Ð

Ð in pgsql – PostgreSQL
накинь ей тогда больше памяти в конфиге и отключи fsync
источник

Ð

Ð in pgsql – PostgreSQL
у тебя же есть бесперебойник?)
источник

RU

Roman Usachev in pgsql – PostgreSQL
есть )
источник

Ð

Ð in pgsql – PostgreSQL
только с бекапом, конечно
источник

RU

Roman Usachev in pgsql – PostgreSQL
alter table set unlogged ? )
источник

RU

Roman Usachev in pgsql – PostgreSQL
на инсертах, кстати, оч сильно помог
источник

RU

Roman Usachev in pgsql – PostgreSQL
egrip=# alter system set fsync TO off;
ALTER SYSTEM
egrip=# alter system set full_page_writes TO off;
ALTER SYSTEM

это без ребута на следующих запросах сработает или лучше все перезапустить?
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Roman Usachev
сколько дать? я какой-то онлайн-оптимизатор тыкнул и че дали - то и вбил :))
Зависит от того, сколько "горячих" данных (конечно, в обычной ситуации, не при этом удалении).
Если они могут вместиться в RAM — можно вообще попытаться вместить. ;)

> я какой-то онлайн-оптимизатор тыкнул и че дали - то и вбил :))

Прямо любопытно, какой так мало выдаёт...
источник

RU

Roman Usachev in pgsql – PostgreSQL
источник

RU

Roman Usachev in pgsql – PostgreSQL
max_connections = 40
shared_buffers = 15GB
effective_cache_size = 45GB
maintenance_work_mem = 2GB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 500
random_page_cost = 4
effective_io_concurrency = 2
work_mem = 19660kB
min_wal_size = 4GB
max_wal_size = 16GB
max_worker_processes = 20
max_parallel_workers_per_gather = 10
max_parallel_workers = 20
max_parallel_maintenance_workers = 4
источник

RU

Roman Usachev in pgsql – PostgreSQL
вот что я вписал
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Да, похоже, что больше четверти RAM он вообще в принципе не выдаёт, да и параметров выдаёт как-то маловато. ;)
Попробуйте http://pgconfigurator.cybertec.at/
А так — см. https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server (и по ссылкам).
источник

RU

Roman Usachev in pgsql – PostgreSQL
почти то же самое получилось, правда у меня work_mem = 19mb, а тут 256mb
источник

RU

Roman Usachev in pgsql – PostgreSQL
я ваще плохо понимаю work_mem - такое ощущение что оно толком на производительность не влияет. под что оно ваще используется?
источник

RU

Roman Usachev in pgsql – PostgreSQL
при чем там где много оперативы его надо очень мало, какие-то смешные объемы
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Roman Usachev
egrip=# alter system set fsync TO off;
ALTER SYSTEM
egrip=# alter system set full_page_writes TO off;
ALTER SYSTEM

это без ребута на следующих запросах сработает или лучше все перезапустить?
Лучше бы Вы fsync не трогали — чуть что (poweroff / kernel panice) — и кластера баз у Вас уже совсем нет. ;(
https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT даёт почти тот же эффект по производительности, зато только немножко транзакций потеряете, в худшем случае.
Кстати... показали бы Вы \d+ таблицы, из которой удаляете — вдруг там что-то "интересное" есть (вроде FK, триггеров ON DELETE и т.п.). ;)
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Roman Usachev
почти то же самое получилось, правда у меня work_mem = 19mb, а тут 256mb
Вы комментарии (про huge_pages и т.п.) посмотрите, и по ссылкам сходите / настройте — я эту ссылку дал, чтоб не пересказывать. ;)

>  под что оно ваще используется?

work_mem используется род сортировки и хеширование, в основном.
Что для одного из вариантов планов удаления могло бы быть существенно (я там выше писал).
источник

RU

Roman Usachev in pgsql – PostgreSQL
Yaroslav Schekin
Лучше бы Вы fsync не трогали — чуть что (poweroff / kernel panice) — и кластера баз у Вас уже совсем нет. ;(
https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT даёт почти тот же эффект по производительности, зато только немножко транзакций потеряете, в худшем случае.
Кстати... показали бы Вы \d+ таблицы, из которой удаляете — вдруг там что-то "интересное" есть (вроде FK, триггеров ON DELETE и т.п.). ;)
так у меня 4 дня прошло и делейт упал из-за соседнего запроса. куда более безопаснее сделать его за 10часов сделать и ничего не трогать, потом вернуть fsync обратно, чем ткнуть какой-то селект параллельно и уронить базу
источник