| Summary: | Зависание процессов PostgreSQL | ||
|---|---|---|---|
| Product: | Postgres@Etersoft | Reporter: | Boris Savelev <boris> |
| Component: | СУБД | Assignee: | Евгений Синельников <sin> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | P3 | CC: | andrey, boris, goga, lav, shan |
| Version: | не указана | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | ALT Linux | ||
| Whiteboard: | |||
| Заявки RT: | Связано с: | ||
| Дата напоминания: | |||
| Bug Depends on: | 2213 | ||
| Bug Blocks: | 1272, 2054 | ||
| Attachments: |
Трассировка на 26 ядре
Лог odbcad32 на 26 ядре |
||
важное замечание: проблема у нас в офисе =) Похоже что проблема в PostgreSQL: я попытался на buh создать новую базу, и на этапе создания все зависло, как уже было раньше на других машинах. Зависание происходит в момент создания типа данных mchar, а так же при работе с ним (например тут: DELETE FROM pg_indexes_name). Как эта проблема лечилась ранее? Исправляли же уже, кажется. Что такое сделали на buh, что вывалилось это? на самом buh ничего не делали. обновили сельту по горячему, когда в базе был пользователь, саму базу из оболочки не обновили до новой версии. после этого все валится. раньше исправляли новой сборкой посгреса, щас что-то не очень помогает. проявляется только на ALTLinux сборке postgresql тест для 100% зависания CREATE TYPE mchar; CREATE FUNCTION mchar(mchar, integer, boolean) RETURNS mchar AS '$libdir/mchar' LANGUAGE C IMMUTABLE RETURNS NULL ON NULL INPUT; виснет на futex воспроизводится также на ядре 2.6.24. проблема в glibc? не работает на новых glibc > 2.5-alt4 (не достоверно) на glibc из 4.0 работает Что-то похожее на http://bugzilla.altlinux.org/show_bug.cgi?id=15356 Поступило предложение проверить на ядрах rpm http://www.unsafe.ru/lakostis/RPMS/ALTLinux kernel-2.6.24/repo/i586 kernel rpm http://www.unsafe.ru/lakostis/RPMS/ALTLinux kernel-2.6.26/repo/i586 kernel Андрей проверь, пожалуйста (In reply to comment #9) > Поступило предложение проверить на ядрах > rpm http://www.unsafe.ru/lakostis/RPMS/ALTLinux kernel-2.6.24/repo/i586 kernel > rpm http://www.unsafe.ru/lakostis/RPMS/ALTLinux kernel-2.6.26/repo/i586 kernel > ни с одним ядром не работает, при инициализации зависает, а при попытке CREATE TYPE mchar; CREATE FUNCTION mchar(mchar, integer, boolean) RETURNS mchar AS '$libdir/mchar' LANGUAGE C IMMUTABLE RETURNS NULL ON NULL INPUT; выпадает в ошибку (In reply to comment #11) > ни с одним ядром не работает, при > инициализации зависает, а при попытке CREATE > TYPE mchar; > > CREATE FUNCTION mchar(mchar, integer, boolean) > RETURNS mchar > AS '$libdir/mchar' > LANGUAGE C IMMUTABLE RETURNS NULL ON NULL INPUT; > выпадает в ошибку > какую ошибку выдает? (In reply to comment #12) > (In reply to comment #11) > > ни с одним ядром не работает, при > > инициализации зависает, а при попытке CREATE > > TYPE mchar; > > > > CREATE FUNCTION mchar(mchar, integer, boolean) > > RETURNS mchar > > AS '$libdir/mchar' > > LANGUAGE C IMMUTABLE RETURNS NULL ON NULL INPUT; > > выпадает в ошибку > > > > какую ошибку выдает? > Вроде бы простую надпись Error. Пишите пожалуйста сразу при тестировании, какая именно ошибка выдаётся. Нельзя же так, опосля по памяти что-то вписывать. > rpm http://www.unsafe.ru/lakostis/RPMS/ALTLinux kernel-2.6.24/repo/i586 kernel Linux version 2.6.24-wks-smp-alt2.4 (builder@yalt64.vps) (gcc version 4.1.2 20070626 (ALT Linux, build 4.1.2-alt2)) #1 SMP PREEMPT Wed May 21 01:22:44 MSD 2008 тест пройден: соединение, создание, инициализация, деинициализация и удаление базы - все удачно. > rpm http://www.unsafe.ru/lakostis/RPMS/ALTLinux kernel-2.6.26/repo/i586 kernel Linux version 2.6.26-wks-smp-alt0.4 (builder@yalt64.vps) (gcc version 4.1.2 20070626 (ALT Linux, build 4.1.2-alt2)) #1 SMP PREEMPT Mon Jun 2 10:19:09 MSD 2008 тест пройден: соединение, создание, инициализация, деинициализация и удаление базы - все удачно. а glibc какая? таже самая, везде одна - 2,5 ап, продолжим изыскания Пожалуйста, без намёков. Пишите какие действия планируется предпринять и что было неправильно в прежних. Не надо писать "я понял" и "привет, как дела" в багах. В то же время не надо обмениваться информацией помимо баги. Не забывайте, что обсуждение в баге читают и другие, и они не должны терять нить. на ядрах 24, 25, 26 - все работает. Тестировал в консоли постгреса так DROP TYPE mchar; DROP FUNCTION mchar(mchar, integer, boolean); CREATE TYPE mchar; CREATE FUNCTION mchar(mchar, integer, boolean) RETURNS mchar AS '$libdir/mchar' LANGUAGE C IMMUTABLE RETURNS NULL ON NULL INPUT; rpm -qa | grep glibc ? надо проверять на glibc из сизифа Ядро Linux version 2.6.26-wks-smp-alt0.4 # rpm -qa | grep glibc glibc-timezones-2.5.1-alt5 glibc-devel-2.5.1-alt5 glibc-preinstall-2.5.1-alt5 glibc-i18ndata-2.5.1-alt5 glibc-kernheaders-2.6.24-alt4 glibc-utils-2.5.1-alt5 glibc-locales-2.5.1-alt5 glibc-nss-2.5.1-alt5 glibc-core-2.5.1-alt5 glibc-gconv-modules-2.5.1-alt5 glibc-2.5.1-alt5 в консоли постгреса DROP TYPE mchar; DROP FUNCTION mchar(mchar, integer, boolean); CREATE TYPE mchar; CREATE FUNCTION mchar(mchar, integer, boolean) RETURNS mchar AS '$libdir/mchar' LANGUAGE C IMMUTABLE RETURNS NULL ON NULL INPUT; все удалялось и создавалось. При инициализации через Сельту она висла. Created attachment 628 [details]
Трассировка на 26 ядре
Created attachment 629 [details]
Лог odbcad32 на 26 ядре
Попытался выполнить вот такие запросы. Собственно по логам видно что на них зависал постгрес. CREATE FUNCTION mchar_in(cstring) RETURNS mchar AS '$libdir/mchar' LANGUAGE C IMMUTABLE RETURNS NULL ON NULL INPUT; CREATE FUNCTION mchar_out(mchar) RETURNS cstring AS '$libdir/mchar' LANGUAGE C IMMUTABLE RETURNS NULL ON NULL INPUT; CREATE FUNCTION mchar_send(mchar) RETURNS bytea AS '$libdir/mchar' LANGUAGE C IMMUTABLE RETURNS NULL ON NULL INPUT; CREATE FUNCTION mchar_recv(internal) RETURNS mchar AS '$libdir/mchar' LANGUAGE C IMMUTABLE RETURNS NULL ON NULL INPUT; CREATE TYPE mchar (INTERNALLENGTH = -1,INPUT = mchar_in,OUTPUT = mchar_out,RECEIVE = mchar_recv,SEND = mchar_send,STORAGE = extended); Каждый 2й зависал. Приходилось принудительно выходить из консоли постгреса. НО! после повторной попытке проблемного запроса, запрос проходил. В топе естественно висят процессы, которые по идеи должны убиваться после закрытия. Есть какие идеи? или откладывать багу и пока жить на бранче? обновим Postges и проверим обновил. надо проверить сборку 8.2.9 и glibc из сизифа (In reply to comment #28) > обновил. надо проверить сборку 8.2.9 и glibc из > сизифа > Все также висит на инициализации, а в htop процесс CREATE FUNCTION проверь 8.3 с новой glibc Как только исправлю ошибки даунгрейда на тестинге, так сразу проверю да можно и без иксов проверять-) но делай как удобно С новой сборкой от 22 сентября все то же самое. ps ax | grep postgres 17741 ? Ss 0:00 postgres: writer process 17742 ? Ss 0:00 postgres: wal writer process 17743 ? Ss 0:00 postgres: autovacuum launcher process 17744 ? Ss 0:00 postgres: stats collector process 17800 ? Ss 0:00 postgres: postgres temp 192.168.0.1(60025) CREATE FUNCTION 17854 pts/2 R+ 0:00 grep postgres Процесс виснет. Не надо указывать дату сборки. Указывай название файла пакета с PG. (In reply to comment #33) > С новой сборкой от 22 сентября все то же > самое. > ps ax | grep postgres > 17741 ? Ss 0:00 postgres: writer process > 17742 ? Ss 0:00 postgres: wal writer process > 17743 ? Ss 0:00 postgres: autovacuum launcher process > 17744 ? Ss 0:00 postgres: stats collector process > 17800 ? Ss 0:00 postgres: postgres temp 192.168.0.1(60025) CREATE > FUNCTION > 17854 pts/2 R+ 0:00 grep postgres > > > Процесс виснет. > Поправка: версия PG 8.3.3 Нужно подумать как воспроизвести на обычном PostgreSQL, либо уточнить место проблемы. (In reply to comment #36) > Нужно подумать как воспроизвести на > обычном PostgreSQL, либо уточнить место > проблемы. > скопировать mchar и выполнить пару запросов. Вот такая конфигурация glibc-2.8.90-alt1 postgresql8.2.1C-server-8.2.9-alt0.M41.1e1 Все отлично, нет зависания Сельты. "100% тест" работает. (In reply to comment #38) > Вот такая конфигурация > glibc-2.8.90-alt1 > postgresql8.2.1C-server-8.2.9-alt0.M41.1e1 Ни слова не написано про работу других версий postgresql с этим glibc. 8.2.4. тоже работает, но по причине того, что 8.2.9 поддерживается сельтой 1.0.4, считаю, что 8.2.9 является более актуальной. Исходная причина вроде как решена, не вижу проблем к закрытию баги. На glibc 2.5 от ALT с любым ядром PostgreSQL любой версии не работает. Работает на glibc 2.4 или > 2.5 |
Запускаем POSTGRESQL 1)Запускаем 1с с логами сельты 1с "задумывается" на in_sql: If exists (select * from sysobjects where id = object_id('_1SCONNECT') and sysstat & 0xf = 3) Drop table _1SCONNECT out_sql: SELECT CASE WHEN EXISTS (SELECT * FROM pg_tables WHERE tablename='_1sconnect') THEN exec_query('DROP TABLE _insert__1SCONNECT; DROP TABLE _1SCONNECT CASCADE; DELETE FROM pg_indexes_name WHERE tabname=''_1SCONNECT''') END Закрываем 1с по ctrl+c На сервере postgresql остается процесс с запросом 2)Открываем 1с еще раз Вываливается с ошибкой "Доступ к базе возможен только из одного каталога" В логах сельты in_sql: Select COUNT(*) from master..sysprocesses where dbid=DB_ID('etersoft') and program_name='1CV7' out_sql: SELECT COUNT(*) FROM pg_stat_activity WHERE client_port>0 AND datname='etersoft' Второе можно понять, потому что висит процесс от предыдущего запуска и если его убить, то (1) снова повторится. "Долгий" запрос также проявляется, если его выполнить в консоле.