делись :)

запатчили, локов нет

да там приложение жопой написано, нечем особенно делиться

но сильно легче от этого не стало

там короче приложение открывало транзакцию на апдейт, а только после этого шло собирать данные для апдейта в дикий интернет

треды - зло

так, сейчас пока попустило

но оно через полчасика точно взорвется опять

так что я еще вернусь ;)

длинные транзакции везде зло

2017-04-27 09:53:13 UTC ERROR: index "batchupdatejournal_master_id_idx" contains unexpected zero page at block 89665 2017-04-27 09:53:13 UTC HINT: Please REINDEX it.

это очень плохо?

вообще хз насколько, но плохо

сделай че бд просит)

2017-04-27 09:53:13 UTC ERROR: index "batchupdatejournal_master_id_idx" contains unexpected zero page at block 89665 2017-04-27 09:53:13 UTC HINT: Please REINDEX it.

Херово :)

пожалуйста, напишите что делать

я паникую, прод падает

Реиндексируй, надеюсь если что бэкапы у тебя были

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

и как его сделать

лучше созадть в в конкурентном режиме такой же индекс , а этот удалить в конкурентном режиме

и еще хорошо бы SET maintenance_work_mem = <тут-сколько-не-жалко>

перед реиндексом

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

Точно !

а сколько лучше дать? оно зависит от шареных буферов и прочего?

делаю бекап

страшно (:

о, ну вот опять

top - 13:07:17 up 184 days, 11:48, 7 users, load average: 37.28, 15.60, 8.60

слейв начинает отрываться от стойки

на мастере при этом в районе двух

блин

postgres=# select count(*) from pg_locks ; count ------- 59135 (1 row)

но при этом запрос под заголовком "Сombination of blocked and blocking activity" из https://wiki.postgresql.org/wiki/Lock_Monitoring возвращает ничего

как эти локи-то отловить?

Может посмотреть топ pg_stat_statements, чтобы увидеть, какие запросы, изменяющие данные вносят наибольший суммарный вклад? Ну и дальше их переписать.

в 9.6 появилась функция pg_blocking_pids (pid), которая возвращает массив pid, блокирующих pid из аргумента можно совместить её с pg_stat_statements

Может посмотреть топ pg_stat_statements, чтобы увидеть, какие запросы, изменяющие данные вносят наибольший суммарный вклад? Ну и дальше их переписать.

топ по времени выполнения?

в 9.6 появилась функция pg_blocking_pids (pid), которая возвращает массив pid, блокирующих pid из аргумента можно совместить её с pg_stat_statements

в этом проекте все еще 9.5 :(

ретрограды, чо...

pgBadger проще для анализа локов

топ по времени выполнения?

По total_time

есть возможность узнать прогресс реиндексирования?

всем привет, подскажите, пожалуйста, куда копать. с помощью pg_pathman разделил таблицу с 50 млн на 19 штук по месяцам (правда вышло с 15 числа по 15, а, не с 1 по 1, но это тут роли не играет же, насколько я понимаю?) SELECT create_range_partitions('table', 'date', '2015-09-15'::date, '1 month'::interval); и в итоге все запросы выполняются намного медленее и даже простой count по конкретной дате очень долгий zz7=# explain analyze select count(*) from transactions where trans_date='2017-03-02'; QUERY PLAN Aggregate (cost=8891.82..8891.83 rows=1 width=8) (actual time=36996.932..36996.933 rows=1 loops=1) -> Append (cost=0.43..8681.65 rows=84066 width=0) (actual time=0.027..36978.710 rows=80796 loops=1) -> Index Only Scan using transactions_18_trans_date_idx on transactions_18 (cost=0.43..8681.65 rows=84066 width=0) (actual time=0.025..36951.611 rows=80796 loops=1) Index Cond: (trans_date = '2017-03-02'::date) Heap Fetches: 80796 Planning time: 0.198 ms Execution time: 36996.964 ms (7 rows) Time: 36997.581 ms индекс используется, в чем дело, почему так долго, может при создании нужно было параметры указать или в конфиге пострес что-то поменять? свободной оперативки на сервере гига 4, если это важно

Та же фигня

Оперативки почти анлим

Ты посмотри , какой IO у тебя в это время

Ты посмотри , какой IO у тебя в это время

хорошая идея, сейчас гляну

34649 be/4 postgres 4.75 M/s 0.00 B/s 0.00 % 40.87 % postgres: 9.6/main: autovacuum worker process zz7 4-6 M/s даже после выполненого запроса держется, проблема видимо в этой autovacuum

всем привет, подскажите, пожалуйста, куда копать. с помощью pg_pathman разделил таблицу с 50 млн на 19 штук по месяцам (правда вышло с 15 числа по 15, а, не с 1 по 1, но это тут роли не играет же, насколько я понимаю?) SELECT create_range_partitions('table', 'date', '2015-09-15'::date, '1 month'::interval); и в итоге все запросы выполняются намного медленее и даже простой count по конкретной дате очень долгий zz7=# explain analyze select count(*) from transactions where trans_date='2017-03-02'; QUERY PLAN Aggregate (cost=8891.82..8891.83 rows=1 width=8) (actual time=36996.932..36996.933 rows=1 loops=1) -> Append (cost=0.43..8681.65 rows=84066 width=0) (actual time=0.027..36978.710 rows=80796 loops=1) -> Index Only Scan using transactions_18_trans_date_idx on transactions_18 (cost=0.43..8681.65 rows=84066 width=0) (actual time=0.025..36951.611 rows=80796 loops=1) Index Cond: (trans_date = '2017-03-02'::date) Heap Fetches: 80796 Planning time: 0.198 ms Execution time: 36996.964 ms (7 rows) Time: 36997.581 ms индекс используется, в чем дело, почему так долго, может при создании нужно было параметры указать или в конфиге пострес что-то поменять? свободной оперативки на сервере гига 4, если это важно

ну тут пафман не работает, вы только разделили таблицу с помощью него. А тот же запрос на непартицированной таблице был быстрее?

ну тут пафман не работает, вы только разделили таблицу с помощью него. А тот же запрос на непартицированной таблице был быстрее?

я понимаю, что в самом запросе он не учавствует, просто описал всю историю с начала. да, было быстрее, но ожидалось то, что на меньшей таблице будет вообще быстро, в ней же не 50млн, а всего 2-3 и индекс меньше само собой. вообще я не менял стандартные настройки постгес, сейчас читаю о них, явно можно улучшить как-то

https://medium.com/@agafonkin/a-dive-into-spatial-search-algorithms-ebd0c5e39d2a

Fedor, Denis, спасибо за помощь, все нашли виновата была приложенька

каким образом 2 базы при ресторе весом в 5 гб(фаил dump) могут занять 32гб??

каким образом 2 базы при ресторе весом в 5 гб(фаил dump) могут занять 32гб??

Индексы, например.

или сжатие

Индексы, например.

ну да она на инлексах так выросла)

ну значит норм)

pg_dump ведь сжимает

Если в plain sql дамп дампить, то нет.

20гб жмется в 2 гб у меня на хорошем сжатие

ERROR: S client not available

Индексы же при ресторе заново строятся, в бэкапе они нахера?

20гб жмется в 2 гб у меня на хорошем сжатие

+1 25 гигов база в формате каталога сжимается до 2.2. из 25 гигов, индексы гигов 10

Индексы же при ресторе заново строятся, в бэкапе они нахера?

Я про то и говорю. Поэтому развернутая база тяжелее.

каким образом 2 базы при ресторе весом в 5 гб(фаил dump) могут занять 32гб??

Как дампишь?

Парни, а кто знает - как из постгис доставать запросом зная lat, long адрес типа Санкт-Петербург,проспект Науки,52

в постгис залита россия из osm

можно поглядывать на https://github.com/osm-by/OpenStreetMap.by/blob/master/geokot/index.py

спасибо, завтра поразбираюсь

для вечера многовато запросов

=)

Postgres pro enterprise могут дать бесплатно для тестирования? Никто не пробовал ? Хочу сравнить стандарт и энтерпрайс, стоит ли закупать лицензию

а что ты хочешь сравнить?

Производительность

какую именно производительность?

1с

а что именно ты будешь замерять? :)

Гилев, многопоточный тест

Кто больше попугаев дасть

Postgres pro enterprise могут дать бесплатно для тестирования? Никто не пробовал ? Хочу сравнить стандарт и энтерпрайс, стоит ли закупать лицензию

Дают. Ну я точно могу

У нас серверы разработки и тестирования не требуют приобретения лицензии

Был бы не против, клиентов много, большая часть на постгресе работает 1с

Напишу тогда письмецо с запросом на тестировние

всем привет, подскажите, пожалуйста, куда копать. с помощью pg_pathman разделил таблицу с 50 млн на 19 штук по месяцам (правда вышло с 15 числа по 15, а, не с 1 по 1, но это тут роли не играет же, насколько я понимаю?) SELECT create_range_partitions('table', 'date', '2015-09-15'::date, '1 month'::interval); и в итоге все запросы выполняются намного медленее и даже простой count по конкретной дате очень долгий zz7=# explain analyze select count(*) from transactions where trans_date='2017-03-02'; QUERY PLAN Aggregate (cost=8891.82..8891.83 rows=1 width=8) (actual time=36996.932..36996.933 rows=1 loops=1) -> Append (cost=0.43..8681.65 rows=84066 width=0) (actual time=0.027..36978.710 rows=80796 loops=1) -> Index Only Scan using transactions_18_trans_date_idx on transactions_18 (cost=0.43..8681.65 rows=84066 width=0) (actual time=0.025..36951.611 rows=80796 loops=1) Index Cond: (trans_date = '2017-03-02'::date) Heap Fetches: 80796 Planning time: 0.198 ms Execution time: 36996.964 ms (7 rows) Time: 36997.581 ms индекс используется, в чем дело, почему так долго, может при создании нужно было параметры указать или в конфиге пострес что-то поменять? свободной оперативки на сервере гига 4, если это важно

Меня смущает heap fetches 80796. У вас из индекса вытаскивается 84066 строк и потом запрос идёт в таблицу и почти все перепроверяет. Конечно, это долго. Попробуйте сделать vacuum freeze на партицию и посмотрите, как изменится heap fetches в плане запроса (ну и скорость)

CREATE INDEX CONCURRENTLY batchupdatejournal_master_id_idx2 ON batchupdatejournal USING hash (master_id);

почему это в одном постгресе запускается

а а в другом ошибка синтаксиса с указанием на начало строки? оба 9.1

набрал руками и оно тоже запускается. какие-то шеллопроблемы.

Люди опытные, подскажите, можно ли что-то сделать для восстановления? Есть БД, извлеченная с помершего рейда в двух вариантах: 1) Копия папка /var/lib/postgresql/9.4/main/ 2) SQL-файл, сделанный чуть ранее pg_dump > sile.sql Установка postgres 9.4 с перекидыванием папки приводит к тому, что на некоторых таблицах валятся SQL запросы. Пишет "неверная страница в блоке" таком-то. Загрузка SQL дампа валится, сообщая сначала на каждой строке "неверная команда \N", затем "\�b���z�*������6�:J2��" (и подобное вида бинарного или поехавшей кодировки) и в конце "нехватка памяти" (ее на машине прилично, 256Гб при размере дампа в 105Гб). ОС Debian 8

sql дамп достали с того же помершего рейда? В таком случае прогоните его через pgloader, и он соберет невалидное мясо в отдельном файле, залив все что читается

или сначала придется прогнать дамп iconv, чтоб удалить non-utf8 sequences

https://medium.com/@agafonkin/a-dive-into-spatial-search-algorithms-ebd0c5e39d2a

Агафонкин случаем на русском то же самое не опубликовал?)