Или это будет еще медленней чем с дискового кеша курсора который не влазит в память? Они в этом случае все записи близко на диске лежат

select * from forensics_forensic limit 1000 offset 5000000; Time: 0.771s

пичаль

я прям счас ответить не могу, но общий смысл в том что курсор можно двигать не только вперёд отсюда и необходимость держать все данные для него

хотя

больше похоже на багу так как у вас стоит NO SCROLL

это значит что можно толькот вперёд

а какая версия постгреса?

PostgreSQL 9.6.5 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406, 64-bit |

пичаль

народ проснёться, я думаю скажет больше, я могу то же покопать но не сейчас

больше похоже на багу так как у вас стоит NO SCROLL

Возможно баг, а может быть что-то не так понимаю или не знаю.

там кажется как то хитро сделан курсор... он ведь по некоему запроссу, запросс висит пока курсор не отработает.

но вообще логично очищать данные которые уже были забраны если стоит NO SCROLL,

Логично, но наверно не реализовано :D

там может быть много подводных камней

может @funbringer что то знать, хотя курсоры кажется это отдельная магия

Я думаю может создать багрепорт

Ребят, никто не будет против, если я добавлю чатик в https://github.com/mr-mig/ru-tech-chats ?

Ребят, никто не будет против, если я добавлю чатик в https://github.com/mr-mig/ru-tech-chats ?

Это секретный чатик для избраных о котором никто не должен знать (нет)

Я думаю может создать багрепорт

А EXPLAIN того запроса, который использует много памяти, Вы смотрели?

Нет, я нуб

https://explain.depesz.com/s/lj6

Я знаю что там действительно много данных должно быть

А EXPLAIN (ANALYZE, BUFFERS), если не слишком долго? Какое текущее значение work_mem, кстати?

слишком долго будет

точней я не знаю как перенаправить вывод explain в файл, а данные которые вернулись никуда не выводить

Хмм... какие данные? EXPLAIN ANALYZE никаких данных, кроме плана, не возвращает.

Точно? :D Я всю ночь не спал

https://explain.depesz.com/s/ruJE

Hash кушает

но это нормально

понятно чё оно не освобождает память...

С виду тут толькл полгигабайта используется (плюс-минус)... Так какое значение work_mem у Вас? И это точно тот же запрос, что и в процедуре?

Народ какая-то мистика. Есть мастер с репликой через pg_replication_slots. На 100 мб канале. База 60 гигов. На метрике же запускается pg_basebackup, которая делает снимок кластера с мастера pg_basebackup -c fast -v --xlog-method=fetch --gzip --format=tar -D - > $BACKUPFILE 2> /var/baseback.log Схема работает уже пару месяцев время бекапа было 13-14 минут. Последние 4 дня бекап делается ровно на час дольше. Мониторю оба сервера mamonsu+zabbix в поведение ничего не поменялось. Даже ночной бекап когда загрузка нулевая тоже делавется больше часа. Все что понимаю, что происходит какая-то дичь. postgresqpro-9.6 + 1c

Я поменяя настройки чтобы посмотреть как оно ведет когда мало памяти max_connections = 10 shared_buffers = 560MB effective_cache_size = 680MB work_mem = 256MB maintenance_work_mem = 640MB min_wal_size = 1GB max_wal_size = 2GB checkpoint_completion_target = 0.7 wal_buffers = 16MB default_statistics_target = 100

Добавить памяти в конфиг и показать новый explain?

С виду тут толькл полгигабайта используется (плюс-минус)... Так какое значение work_mem у Вас? И это точно тот же запрос, что и в процедуре?

> И это точно тот же запрос, что и в процедуре? так точно

А физической памяти у Вас сколько? А одновременных подключений к базе (клиентов)? А сам запрос (или, лучше, всю функцию) можете показать?

Народ какая-то мистика. Есть мастер с репликой через pg_replication_slots. На 100 мб канале. База 60 гигов. На метрике же запускается pg_basebackup, которая делает снимок кластера с мастера pg_basebackup -c fast -v --xlog-method=fetch --gzip --format=tar -D - > $BACKUPFILE 2> /var/baseback.log Схема работает уже пару месяцев время бекапа было 13-14 минут. Последние 4 дня бекап делается ровно на час дольше. Мониторю оба сервера mamonsu+zabbix в поведение ничего не поменялось. Даже ночной бекап когда загрузка нулевая тоже делавется больше часа. Все что понимаю, что происходит какая-то дичь. postgresqpro-9.6 + 1c

А ожидания (pg_stat_actiivity) смотрели во время backup-a?

не оно меньше не будет... всё было бы хорошо если бы это было просто SELECT * FROM blabla; тогда бы это было возможно, а тут всё скушивают hash для join.

А где Вы это видите? Он же говорит, что съедается около 8GB, а в плане вроде всё же меньше...

16gb память это мой домашний пк Вот запрос https://dumpz.org/2702725/

А где Вы это видите? Он же говорит, что съедается около 8GB, а в плане вроде всё же меньше...

в плане меньше, согласен

но то же прилично

max_connections = 10 shared_buffers = 6560MB effective_cache_size = 6680MB work_mem = 5256MB maintenance_work_mem = 640MB min_wal_size = 1GB max_wal_size = 2GB checkpoint_completion_target = 0.7 wal_buffers = 16MB default_statistics_target = 100

В общем, с подобным планом, по мере увеличения work_mem потребление памяти должно только расти (и это правильно).

Моя теория такова, что этот запросс для ПГ не такой потоковый как кажется снаружи, по этому данные и не очищаются.

к слову вообще не используются индексы....

это могло бы уменьшить нагрзку на память

А как Вы определили, что используется именно около 8 ГБ? Как измеряли?

А как Вы определили, что используется именно около 8 ГБ? Как измеряли?

+1

А как Вы определили, что используется именно около 8 ГБ? Как измеряли?

На скриншоте видно

КДЕшным System Monitor

Или это не правильно?

На скриншоте видно

Не знаю, правильно ли он измеряет —- не пользовался.

Если уменшить размер памяти то я вижу что размер занятого места увеличивается

Постгрес пишет кеш на диск

доброе утро) вопрос про оптимальный алгоритм) задача - есть таблица model, там поля id, date_modified (Python, Django, date_modified = models.DateTimeField(_('date modified'), auto_now=True), там дата изменения документа с микросекундами, которые стоит игнорить), есть некий список словарей на питоне [{‘id’: 1, ‘date_modified’: 1508817032}, …], тут unixtimestamp в секундах, задача - написать, какие id из этого списка имеют отличные date_modified от СУБД, то есть сделать список id изменённых документов допустим, в списке 100 000 пар объектов, как лучше сделать - выгрузить все данные одним запросом и на питоне сравнивать или делать кучу запросов к базе? или какой-нибудь третий вариант (один неведомый запрос к базе)?

если принципиальной разницы нет, грузить db или app сервер, какой вариант лучше?

Если уменшить размер памяти то я вижу что размер занятого места увеличивается

Да, естественно. А проблема-то у Вас в чём, тогда? ;) Про измерение занятой памяти, кстати: https://www.depesz.com/2012/06/09/how-much-ram-is-postgresql-using/

доброе утро) вопрос про оптимальный алгоритм) задача - есть таблица model, там поля id, date_modified (Python, Django, date_modified = models.DateTimeField(_('date modified'), auto_now=True), там дата изменения документа с микросекундами, которые стоит игнорить), есть некий список словарей на питоне [{‘id’: 1, ‘date_modified’: 1508817032}, …], тут unixtimestamp в секундах, задача - написать, какие id из этого списка имеют отличные date_modified от СУБД, то есть сделать список id изменённых документов допустим, в списке 100 000 пар объектов, как лучше сделать - выгрузить все данные одним запросом и на питоне сравнивать или делать кучу запросов к базе? или какой-нибудь третий вариант (один неведомый запрос к базе)?

пачками по 10 000 Если у вас Django 1.11 и postgres то можно .iterator() использовать

да, поддерживается

Если уменшить размер памяти то я вижу что размер занятого места увеличивается

Да, а сам запрос какой-то ORM сгенерирован? Вам действительно нужны все эти возвращаемые поля?

да, поддерживается

Ну тогда просто .iterator() https://docs.djangoproject.com/en/1.11/ref/databases/#server-side-cursors Оно не упадет по памяти

Да, а сам запрос какой-то ORM сгенерирован? Вам действительно нужны все эти возвращаемые поля?

да DjangoORM сгенерировал, но там в .only() есть тщательно отобраный список полей который надо использовать

короче все поля там нужны

Да ладно. ;) Например: INNER JOIN ... ON "forensics_forensic"."vendor_id" = "sources_datavendor"."id"... И возвращаются оба поля. Хотя это мелочь, конечно...

Да ладно. ;) Например: INNER JOIN ... ON "forensics_forensic"."vendor_id" = "sources_datavendor"."id"... И возвращаются оба поля. Хотя это мелочь, конечно...

Я так понимаю это для того что-бы ORM сумел построить обджекты и зависимости между ними(Я не знаю как он это делает). Я имел ввиду поля з данными

короче все поля там нужны

В общем, попробуйте измерить, сколько памяти на самом деле использует тот backend PostgreSQL, который выполняет Ваш запрос, если Вам интересно, почему есть отличие между тем, что показывает план и System Monitor. Заодно узнаете, правильно ли работает последний.

А ожидания (pg_stat_actiivity) смотрели во время backup-a?

Много idle, 1 -2 active

Много idle, 1 -2 active

А сам pg_dump ждёт чего-то или нет?

В общем, попробуйте измерить, сколько памяти на самом деле использует тот backend PostgreSQL, который выполняет Ваш запрос, если Вам интересно, почему есть отличие между тем, что показывает план и System Monitor. Заодно узнаете, правильно ли работает последний.

У меня тот сприкпт не работает. Сейчас пробую исправить

А сам pg_dump ждёт чего-то или нет?

А, извините, это был pg_basebackup. ;)

А сам pg_dump ждёт чего-то или нет?

pg_basebackup xlog забирает же и ничего не ждем. О даже запросы не делает жи

Ну тогда просто .iterator() https://docs.djangoproject.com/en/1.11/ref/databases/#server-side-cursors Оно не упадет по памяти

понял, то есть, получается, с iterator’ом будет много запросов к базе? и в каждом запросе (на каждой итерации) я буду проверять даты, верно?

но на Django это кешироваться не будет, это будет где-то на сервере

будет один запрос, но Python процес не будет принимать все строки в свою память и сразу же закрывать соединение с базой. 100000 обджектов в питоне могут много занимать

но на Django это кешироваться не будет, это будет где-то на сервере

да

pg_basebackup xlog забирает же и ничего не ждем. О даже запросы не делает жи

А размер backup-ов не увеличился?

А размер backup-ов не увеличился?

тот же. И размер базы тот же.

разобрался, спасибо)

➜ ~ ps -u postgres o pid= | sed "s/^[ \t]*//" | sed 's#.*#/proc/&/smaps#' | xargs sudo grep ^Pss: | awk '{A+=$2} END{print A}' 168923 ➜ ~ ps -u postgres o pid= | sed "s/^[ \t]*//" | sed 's#.*#/proc/&/smaps#' | xargs sudo grep ^Pss: | awk '{A+=$2} END{print A}' 9247719 ➜ ~ ps -u postgres o pid= | sed "s/^[ \t]*//" | sed 's#.*#/proc/&/smaps#' | xargs sudo grep ^Pss: | awk '{A+=$2} END{print A}' 10421329

10gb чтоле? o_o

тот же. И размер базы тот же.

А в выводе / логах за этот период искали?

➜ ~ ps -u postgres o pid= | sed "s/^[ \t]*//" | sed 's#.*#/proc/&/smaps#' | xargs sudo grep ^Pss: | awk '{A+=$2} END{print A}' 168923 ➜ ~ ps -u postgres o pid= | sed "s/^[ \t]*//" | sed 's#.*#/proc/&/smaps#' | xargs sudo grep ^Pss: | awk '{A+=$2} END{print A}' 9247719 ➜ ~ ps -u postgres o pid= | sed "s/^[ \t]*//" | sed 's#.*#/proc/&/smaps#' | xargs sudo grep ^Pss: | awk '{A+=$2} END{print A}' 10421329

Возможно, и 10. Тут же не видно, в какой момент и при каких настройках Вы измеряете. ;)

max_connections = 10 shared_buffers = 6560MB effective_cache_size = 6680MB work_mem = 5256MB maintenance_work_mem = 640MB min_wal_size = 1GB max_wal_size = 2GB checkpoint_completion_target = 0.7 wal_buffers = 16MB default_statistics_target = 100

с этим настройками

в момент когда cделал FETCH 1000 FROM cursor1; но не закрыл курсор

С такими —- это ещё очень мало. :)

в этот момент

С такими —- это ещё очень мало. :)

значит можно уменшить без ущерба по скорости или как?

Подождите. В чём у Вас проблема, конкретно?

Проблема в том что процес на Python который должен обрабатывать этот запрос падает от рук OOM килера. Я вот пытаюсь заставить его работаеть с server side cursor, но мне кажется если запустить это на продакшене где таких запросов будет много начнут уже падать сервера с Postgres

> Проблема в том что процес на Python который должен обрабатывать этот запрос падает от рук OOM килера Если "убивают" именно его, то проблема только в нём, и никакие настройки PostgreSQL тут не помогут. Если же "убивают" backend PostgreSQL, связанный с этим клиентским процессом, это другое дело. Правильно настроенные сервера от этого падать не начнут, кстати, будут только "умирать" connections.

Далее. По показанным Вами планам видно, что backend PostgreSQL-а действительно использует немало памяти для обработки этого запроса, и курсор тут вообще ни при чём.

Объём потребляемой памяти зависит, в первую очередь, от work_mem (это, примерно, максимально допустимое использование памяти на один "узел" запроса (node)).

Т.е., например, в плане Вашего запроса 40 nodes. Значит, он потенциально мог бы использовать 40 x work_mem памяти.