настройки вакуума пришлите пжл

vacuum_cost_delay = 50 vacuum_cost_limit = 150

там будет кол-во прочитанных байт

настройте вакуум на более агрессивный

вакуум если не ошибаюсь 2-3 раза читает, не больше

повышайте vacuum_cost_limit и понижайте vacuum_cost_delay

только для конкретной таблицы

можете послать hup конкретному бакенду vacuum

чтоб не потерять прогресс

повышайте vacuum_cost_limit и понижайте vacuum_cost_delay

с каких цифр начать , рекомендуете ?

можете послать hup конкретному бакенду vacuum

посылал

после выставки параметров

вам нужно быстрее - выставляйте delay в 0

с каких цифр начать , рекомендуете ?

начните инкрементально изменять. И смотрите как влияет на систему. Идеальные параметры вам никто не скажет

а если диски умирают

то увеличивать этот тормозистор

по дискам загрузка вообще мизерная сейчас

после delay в 0

сам процесс вакумирования жрет 2Мбит.с

что тоже настораживает

что так мало

процесс vacuum уйдет под 100точку

и начнет жрать диск

delay в 0.

Сейчас попробую дэлэй в 0

сколько вакуум пожрал в cat /proc/$pid/io

?

сейчас посмотр.

на pgconf кстати приежал японец, который прикрутил паралельный автовакуум

но коре тим с патчем его послала

говорят нинужно

cat /proc/5623/io rchar: 325761540252 wchar: 57434284797 syscr: 39765852 syscw: 7007401 read_bytes: 298675843072 write_bytes: 57435086848 cancelled_write_bytes: 0

у нас говорят на ноутбуках vacuum в 100 cpu не уходят

cat /proc/15897/io rchar: 223230 wchar: 2 syscr: 64 syscw: 1 read_bytes: 0 write_bytes: 0 cancelled_write_bytes: 0

read 278 Gb

или я не выспался

скоро должен закончиться

С индексами база 326 GB

а.

ну значит не скоро

делай delay

сделал , смотрю IO

бакенд на стороне postgresql, который обслуживает vacuum в 100 не уперся?

смотрю

у нас говорят на ноутбуках vacuum в 100 cpu не уходят

Сказки

бакенд на стороне postgresql, который обслуживает vacuum в 100 не уперся?

нет не уперся , в среднем получается 40 % сейчас

а диск как?

нет не уперся , в среднем получается 40 % сейчас

maintenance_work_mem сколько?

дор 25 Мбит подскочила скорость на чтение

^^^ ага, памяти дайте бакенду

правильный вопрос ☝️

max_connections = 150 shared_buffers=25GB work_mem = 300MB maintenance_work_mem = 8GB effective_cache_size = 64GB

maintenance_work_mem сколько?

а сколько pg может использовать в реальности?

1gb вроде?

или 4?

1gb вроде?

Для vacuum вроде около 1Gb

Григорий не подскажешь сколько может использовать бакенд вакуум от work_mem?

Create index умеет использовать больше

на серваке Доступно 90GB

Григорий не подскажешь сколько может использовать бакенд вакуум от work_mem?

а разве не весь maintenance_work_mem использовать должен?

ну так написан

в те времена вроде больше 512 mb не было наверно :)

шутка конечно, но факт.

ну это было 7 версия

может использовать больше, но конкретно вакуум не больше 1gb

и в 9.6 тоже

ERROR: S client not available

может использовать больше, но конкретно вакуум не больше 1gb

а кто больше может create index?

в те времена вроде больше 512 mb не было наверно :)

Капец!

Можно размер процесса вакуума посмотреть

Сейчас ггляну

сколько read_bytes?

не ну тут он висит

ага, логический лок

Развесил его

Щас смотрю развеился или нет

Пошла скорость 186 Мбит/ сек

Спасибо !

Сейчас побыстрее закончится все должно

Если вижу в такого вида процес стоит ли очоковать ?

VACUUM public.fraud_filt_result (to prevent wraparound)

интересуют слова to prevent wraparound

это freeze

интересуют слова to prevent wraparound

это все

скоро остановится

вакуум давно не работал, скоро база войдет в майнтенс режим

хотя, да, это все

и ничего не разрешит делать

пока не прогонишь vacuum

у pgpro сейчас 64битный счетчик

на сколько помню, за 10 млн он отказжется от примениения транзакций, а за 25 млн начнет логи засирать

:)

у pgpro сейчас 64битный счетчик

это с какой версии?

помоему с 9.6.2

у pgpro сейчас 64битный счетчик

В Enterprise-версии. В стандарте нет.

Пошла скорость 186 Мбит/ сек

ну че, просралось?