Обсуждение: Re: pg_cancel_backend() не снимает зависшие транзакции
Sergey Konoplev пишет: > transport=# select datname, usename, procpid, current_query::char(15), > waiting, query_start from pg_catalog.pg_stat_activity where procpid = > 20530; Покажи полностью: select * from pg_catalog.pg_stat_activity; select * from pg_catalog.pg_locks ; Может там какие-нить функции используются, которые не умеют CHECK_FOR_INTERRUPTS ? -- С уважением, Алексей Заяц.
Извиняюсь, забыл cc: ---------- Forwarded message ---------- From: Sergey Konoplev <gray.ru@gmail.com> Date: 03.10.2007 14:46 Subject: Re: [pgsql-ru-general] pg_cancel_backend() не снимает зависшие транзакции To: Заяц Алексей <az@antora.ru> Привет, Лёш Сейчас активность и локи показать не могу, т.к. уже перезапустил сервер, но в течение недели обещаю, т.к. раз в неделю у меня эта беда происходит точно. Если ты хотел посмотреть на другие запросы, то они отрабатывают нормально, т.е. вместе с одним запросом никто другой не висит. По поводу CHECK_FOR_INTERRUPTS, большие сомнения, т.к. одна из наиболее часто зависающих процедур просто выводит результат не очень сложной выборки, а вторая формирует текст на основе другой не очень сложной выборки. Экзотика которая используется в этих процедурах это достаточно нагруженные таблицы, вторая процедура на plpython и использование другой процедуры, где строятся динамические запросы. Кстати, где посмотреть кто умеет CHECK_FOR_INTERRUPTS, а кто нет? 2007/10/3, Заяц Алексей <az@antora.ru>: > Sergey Konoplev пишет: > > transport=# select datname, usename, procpid, current_query::char(15), > > waiting, query_start from pg_catalog.pg_stat_activity where procpid = > > 20530; > Покажи полностью: > select * from pg_catalog.pg_stat_activity; > select * from pg_catalog.pg_locks ; > > Может там какие-нить функции используются, которые не умеют > CHECK_FOR_INTERRUPTS ? > > -- > С уважением, > Алексей Заяц. > > -- Regards, Sergey Konoplev -- Regards, Sergey Konoplev
Извиняюсь, забыл копию. 24.10.07, Michael Holzman<michaelholzman@gmail.com> написал(а): > А какая платформа? SuSE 9 Enterprise Server > На HP-UX, например, можно отрубить сокет с помощью ndd. Я думаю, что > это должно срабатывать на других *nix'ах тоже. > > Если так, то написать что-нибудь маленькое, которе будет отключать > сокеты находящиеся слишком долго в CLOSE_WAIT, не трогая при этом сами > процессы. Спасибо за совет, покопаю в этом направлении. Кстати я заметил странную штуку - таймер SSH демона (который висит в FIN_WAIT2 состоянии и не отпускает бэкэнд) не работает (off), не смотря на то что системный таймаут для FIN_WAIT2 (tcp_fin_timeout) выставлен в 60. pgdb:~ # netstat -pnao |grep 37465 tcp 1 131072 127.0.0.1:5432 127.0.0.1:37465 CLOSE_WAIT 24855/postgres: kon unkn-4 (41.30/0/0) tcp 73728 0 127.0.0.1:37465 127.0.0.1:5432 FIN_WAIT2 10511/sshd: dcsshcl off (0.00/0/0) pgdb:~ # cat /proc/sys/net/ipv4/tcp_fin_timeout 60 Может кто-нибудь знает, что ещё, кроме tcp_fin_timeout, может воздействовать на таймаут FIN_WAIT2? -- Regards, Sergey Konoplev -- Regards, Sergey Konoplev