его смотрели, или чем то не удовлетворяет?

Постгре 9.4

А он с 9.5

а так бы выбрал pg_probackup

Версия какая у пг? Проблема известная в узком кругу

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

Кстати

А на сервере видать соединения tcp. Netstat показывает их?

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

Оптимизация - убрали проверки как лишние?

Их просто очень много и гдето не досмотрели

Тк такая проблема уже давно видна

А воспроизводится на всех связках? Или как тут - win клиент, linux сервер?

Думаю не в особенностях реализации сокетов проблема?

С линухами. На винде никого у нас нет

Думаю не в особенностях реализации сокетов проблема?

Было вродь даже однажды что без коннектов уже бекенд висел

Но сам не видел, коллеги видали

Так же одни жаловались что при переходе на 10 чаще стало проявлятся

Поэтому мы статистику собираем по таким случаям, тк воспроизвести у нас пока не получается

Поэтому мы статистику собираем по таким случаям, тк воспроизвести у нас пока не получается

дропни пользователя который сейчас подключен и увидешь что во вьюхе pg_stat_activity его не видно, а соединение есть :)

дропни пользователя который сейчас подключен и увидешь что во вьюхе pg_stat_activity его не видно, а соединение есть :)

Судя по обсуждению, таки имеет место ситуация, когда контакт с БД во вьюхе есть, может даже в выводе netstat оно есть, а вот реально, на стороне клиента (или всё-таки приложения?) нет.

Я такое на 9.4 выидел пару лет назад, и даже как-то обходил, а вот как - уже не помню. :(

Поэтому мы статистику собираем по таким случаям, тк воспроизвести у нас пока не получается

А OS какая?

Вот тут вчера ссылочкой поделились

https://jobs.zalando.com/tech/blog/hack-to-terminate-tcp-conn-postgres/?gh_src=4n3gxh1

А OS какая?

Centos

Я бы все волосы везде повыдирал, если б пришлось дебажить такое: https://postgr.es/p/3_S

Я бы все волосы везде повыдирал, если б пришлось дебажить такое: https://postgr.es/p/3_S

от stat collector зависит работоспособность сервера. помоему отсылать такую информацию по udp - это фейл, не?

от stat collector зависит работоспособность сервера. помоему отсылать такую информацию по udp - это фейл, не?

А что ты предлагаешь, через текстовый фейл общатся?

через юниксовый сокет?

А что ты предлагаешь, через текстовый фейл общатся?

через git же :)

Забавно да

да не надо ничего программировать, всё уже на напрограммировали: https://github.com/iovisor/bcc/blob/master/tools/dbslower.py

USDT probes, which means it needs MySQL and PostgreSQL built with # USDT (DTrace) support. ну как бы... такое вообще по умолчанию сейчас же никто не собирает

USDT probes, which means it needs MySQL and PostgreSQL built with # USDT (DTrace) support. ну как бы... такое вообще по умолчанию сейчас же никто не собирает

а зря, хорошая штука. в mysql 8 их вообще выкинули :(

а зря, хорошая штука. в mysql 8 их вообще выкинули :(

Наверное ,просто больше ручек прикрутили для диагностики?

Наверное ,просто больше ручек прикрутили для диагностики?

там performance_schema очень развилась, да

я всё хочу найти время для сравнения pg_stat_* и performance_schema. по-моему, там сравнение сильно не в пользу постгреса получится

я всё хочу найти время для сравнения pg_stat_* и performance_schema. по-моему, там сравнение сильно не в пользу постгреса получится

в чем именно не в пользу? pg_stat_* вполне адекватную инфу показывает а performance_schema ИНФЫ ДОФИГА. а грамотно ей пользоваться надо долго учиться

полностью включенная performance schema дает просадки в производительности mysql, хотя я давно эту информацию не проверял, может в mysql8.0 уже не так

в чем именно не в пользу? pg_stat_* вполне адекватную инфу показывает а performance_schema ИНФЫ ДОФИГА. а грамотно ей пользоваться надо долго учиться

pg_stat какой-то весь куцый и сиротский на первый взгляд. а performance_schema можно включать/выключать по частям, причём динамически (с 5.7)

для тех, кому лень учиться, придумали sys_schema

Итак, как сделать, чтобы в ПГ остались висящие сессии. 1. Пара фраз про все и всяческие системные и сетевые вещи: kill -9 <клиент> прибивает сетевые соединения, так что не вариант. Короткие запросы, которые генерируют трафик в обе стороны, тоже не вот уж помогут. Сетевые проблемы я настоятельно рекомендую симулировать зарубанием трафика, как с ПГ-порта сервера, так и на этот ПГ-порт. Соответственно, надо: 1. Длинный запрос. Делаем (виртуалке даём гиг оперативы и не лезем в настройки памятежорства): pgbench -h testhost -U test -iqs 100 2. генерируем разного: pgbench -h pgmm01 -U test -nc4 -T180 запускаем команду несколько раз. Ну чтобы разнообразить собственную жизнь. 3. на сервере родить скриптик: #!/usr/bin/env bash # Disable all connection exclude ssh by iptables NONROOT=65 PGDATAPORT="5432" IPTABLESTMP="/tmp/iptables.save.tmp" [ "`id -u`" = "0" ] || { echo "This script require root rights" echo "Start it by command: sudo $0" exit $NONROOT } iptables-save > $IPTABLESTMP iptables -F iptables -A INPUT -p tcp --dport $PGDATAPORT -j DROP iptables -A OUTPUT -p tcp --sport $PGDATAPORT -j DROP 4. После издевательств пгбенча над базой скормить в клиенте что-нибудь вот такое: test@test=> select pa.aid,abalance from pgbench_accounts as pa left join pgbench _history ph on pa.aid=ph.aid order by abalance; 5. А на сервере запустить выше указанный скрипт. Вуаля! Клиента можно прибить kill -9, а в консоли сервера наблюдать вот такое: test=# select datname,usename,backend_start, now(), query from pg_stat_activity where datname='test'; datname | usename | backend_start | now | query ---------+----------+-------------------------------+--------------------------- ---+---------------------------------------------------------------------------- ----------------------------------------- test | test | 2018-01-29 16:14:18.334963+00 | 2018-01-29 16:36:12.40825+ 00 | select pa.aid,abalance from pgbench_accounts as pa left join pgbench_histor y ph on pa.aid=ph.aid order by abalance; test | postgres | 2018-01-29 16:22:52.556845+00 | 2018-01-29 16:36:12.40825+ 00 | select datname,usename,backend_start, now(), query from pg_stat_activity wh ere datname='test'; (2 rows) test=# Т.е. бек запущен в 16:14, сейчас 16:36

в чем именно не в пользу? pg_stat_* вполне адекватную инфу показывает а performance_schema ИНФЫ ДОФИГА. а грамотно ей пользоваться надо долго учиться

Оно показывает обычно что есть проблема на серваке. А в чем она заключается дай бог дадут много гигабайтные логи и дебаггер.

Итак, как сделать, чтобы в ПГ остались висящие сессии. 1. Пара фраз про все и всяческие системные и сетевые вещи: kill -9 <клиент> прибивает сетевые соединения, так что не вариант. Короткие запросы, которые генерируют трафик в обе стороны, тоже не вот уж помогут. Сетевые проблемы я настоятельно рекомендую симулировать зарубанием трафика, как с ПГ-порта сервера, так и на этот ПГ-порт. Соответственно, надо: 1. Длинный запрос. Делаем (виртуалке даём гиг оперативы и не лезем в настройки памятежорства): pgbench -h testhost -U test -iqs 100 2. генерируем разного: pgbench -h pgmm01 -U test -nc4 -T180 запускаем команду несколько раз. Ну чтобы разнообразить собственную жизнь. 3. на сервере родить скриптик: #!/usr/bin/env bash # Disable all connection exclude ssh by iptables NONROOT=65 PGDATAPORT="5432" IPTABLESTMP="/tmp/iptables.save.tmp" [ "`id -u`" = "0" ] || { echo "This script require root rights" echo "Start it by command: sudo $0" exit $NONROOT } iptables-save > $IPTABLESTMP iptables -F iptables -A INPUT -p tcp --dport $PGDATAPORT -j DROP iptables -A OUTPUT -p tcp --sport $PGDATAPORT -j DROP 4. После издевательств пгбенча над базой скормить в клиенте что-нибудь вот такое: test@test=> select pa.aid,abalance from pgbench_accounts as pa left join pgbench _history ph on pa.aid=ph.aid order by abalance; 5. А на сервере запустить выше указанный скрипт. Вуаля! Клиента можно прибить kill -9, а в консоли сервера наблюдать вот такое: test=# select datname,usename,backend_start, now(), query from pg_stat_activity where datname='test'; datname | usename | backend_start | now | query ---------+----------+-------------------------------+--------------------------- ---+---------------------------------------------------------------------------- ----------------------------------------- test | test | 2018-01-29 16:14:18.334963+00 | 2018-01-29 16:36:12.40825+ 00 | select pa.aid,abalance from pgbench_accounts as pa left join pgbench_histor y ph on pa.aid=ph.aid order by abalance; test | postgres | 2018-01-29 16:22:52.556845+00 | 2018-01-29 16:36:12.40825+ 00 | select datname,usename,backend_start, now(), query from pg_stat_activity wh ere datname='test'; (2 rows) test=# Т.е. бек запущен в 16:14, сейчас 16:36

Tcp keepalive еще проверь что будут работать или нет

Оно показывает обычно что есть проблема на серваке. А в чем она заключается дай бог дадут много гигабайтные логи и дебаггер.

> дебаггер и этот человек жаловался на компиляцию c в python

без gdb и не туды и не сюды

> дебаггер и этот человек жаловался на компиляцию c в python

Инегри

так, net.ipv4.tcp_keepalive_time не при делах. Разве что, если время запроса больше этого времени, вот что в логе ПГ: 2018-01-29 16:39:32 UTC test@192.168.191.1/test [psql:17238]: LOG: could not send data to client: Время ожидания соединения истекло 2018-01-29 16:39:32 UTC test@192.168.191.1/test [psql:17238]: STATEMENT: select pa.aid,abalance from pgbench_accounts as pa left join pgbench_history ph on pa.aid=ph.aid order by abalance;

так, net.ipv4.tcp_keepalive_time не при делах. Разве что, если время запроса больше этого времени, вот что в логе ПГ: 2018-01-29 16:39:32 UTC test@192.168.191.1/test [psql:17238]: LOG: could not send data to client: Время ожидания соединения истекло 2018-01-29 16:39:32 UTC test@192.168.191.1/test [psql:17238]: STATEMENT: select pa.aid,abalance from pgbench_accounts as pa left join pgbench_history ph on pa.aid=ph.aid order by abalance;

кмк речь про логические keepalive который сам pg делает

https://www.postgresql.org/docs/current/static/runtime-config-connection.html

tcp_keepalives_idle tcp_keepalives_interval

а так система может в легкую обманывать. на текущей работе был wget из под крона который был запущен в 2015 году и прикидывался что активен

Tcp keepalive еще проверь что будут работать или нет

TCP keep alive включается минут через 15 по умолчанию

tcp_keepalives_idle tcp_keepalives_interval

по-умолчанию используются значения из системы.

И я сейчас не вспомню, чтобы эти значения редактировались в ПГ.

по-умолчанию используются значения из системы.

тоесть pg не анализирует на логическом уровне, а просто устанавливает параметры на сокет?

Судя по докам - да. В код я не лазил, сразу говорю.

тада вообще чему вы удивляетесь.

тада вообще чему вы удивляетесь.

Я давно уже ничему не удивляюсь. Я тупо показываю, как имитировать подвисшие на стороне сервера соединения. А то пролетало, что не ловится такое. Ловится на ура.

Я давно уже ничему не удивляюсь. Я тупо показываю, как имитировать подвисшие на стороне сервера соединения. А то пролетало, что не ловится такое. Ловится на ура.

https://doxygen.postgresql.org/pqcomm_8c_source.html#l01730

ну да. просто на откуп системы.

ну да. просто на откуп системы.

ну вот и ладненько

добрый

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

log_destination "stdout"?

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

Внезапный вопрос: зачем? Что вы хотите этим добиться?

Внезапный вопрос: зачем? Что вы хотите этим добиться?

ох, внезапно мне так нужно для коллектора

докер

https://www.postgresql.org/docs/9.5/static/runtime-config-logging.html офдока говорит что в stderr заворачивается

но, судя по всему, нет

Для коллектора логи заворачиваются в syslog, а сислог уже шлёт куда надо.

Для коллектора логи заворачиваются в syslog, а сислог уже шлёт куда надо.

ну если я спрашиваю, то скорее всего, мое решение чем то обосновано?

причем, меня интересует именно slow log

причем, меня интересует именно slow log

Я ещё раз повторяю вопрос: что вы хотите получить и где?

Я ещё раз повторяю вопрос: что вы хотите получить и где?

хочу чтобы slow query были видны в stdout или stderr

tail -f [файл лога]

Всем привет)

Народ, может кто может помочь? У меня в таблице 120 млн строк и когда делаю запросы, то первый запрос занимает секунд 20-70, но зато следующие по 1 сек. Запросы разные одинаково себя ведут. автовакуум настроен, реиндекс сделал. shared_buffers = '3GB'; effective_cache_size = '6GB'; Сервер: 8GB RAM, 4 CPU, SSD Что это может быть?)

А план что показывает?

сейчас скинуть попробую

Ну сравнить просто надо explain analyse первого и последующих. Может быть план меняется и выборка уже из кеша идет

Покажите план с buffers

сори, а как его получить?)

И 3Gb для shared buffers многотовато при 8Gb RAM.

explain (analyze, verbose, buffers)

explain (analyze, verbose, buffers)

сек