| 1.1, Вадим (?), 17:38, 14/10/2002 [ответить]
| +/– |
Интересно почему в PostgreSQL постоянно возникают deadlock. Причем для простейших таблиц (5 int полей с int ключем, 60 записей) с достаточно интенсивным UPDATE (примерно от 5 раз в минуту до 3 раз в сек.)- dead lock выскакивают регулярно, несмотря на ежедневный VACUUM ANALYZE и еженедельный VACUUM FULL базы. Запросы простейшие, даже транзакций нет. Просто постоянные SELECT и UPDATE, гораздо реже INSERT.
Раньше грешил на транзакции, dead lock вываливались на совершенно других базах, порядок следования доступа к таблицам был одинаковым.
| | |
| 1.2, saper (?), 10:40, 15/10/2002 [ответить]
| +/– | |
Какая у вас версия PostgreSQL? У нас в промышленной эксплуатации 7.0.3, потом перешли на 7.1 - все в полном порядке. Что касается deadlock: 1. Попробуйте PostgreSQL на классическом Linux-e (известно, что под FreeBSD он не очень хорошо себя показал, а под модифицированными ядрами Linux-a возможны проблемы). Итог - Slackware 8.1 + PostgreSQL 7.2.3 (собирать из исходников, все собирать с установками по-умолчанию). После такой кратко описанной установки надеюсь у вас заработает. | | |
| |
| 2.4, Вадим (?), 12:50, 15/10/2002 [^] [^^] [^^^] [ответить]
| +/– | |
>Какая у вас версия PostgreSQL?
7.2.1
> У нас в промышленной эксплуатации 7.0.3, потом
> перешли на 7.1 - все в полном порядке.
В том-то и дело, что при 7.0 и 7.1 проблем тоже небыло, хотя нагрузка на базу была намного меньше текущей.
>1. Попробуйте PostgreSQL на классическом Linux-e (известно, что под FreeBSD он
У меня на SMP системе под FreeBSD, очень вероятно, что именно SMP и приводит к проблемам, так как на старом однопроцессорном сервере я deadlock'ов тоже не помню.
| | |
|
| 1.3, port22 (?), 11:01, 15/10/2002 [ответить]
| +/– |
Скорее всего у Вас алгоритм работы программы не
проработан. У меня десятки таблиц с кучей ФК и апдейтов несколько (~ 2 - 10) раз в секунду, без проблем. Вообще,если начинать работать с БД, то лучше PostgreSQL, в перспективе, нет.
| | |
| |
| 2.5, Вадим (?), 12:58, 15/10/2002 [^] [^^] [^^^] [ответить]
| +/– |
>Скорее всего у Вас алгоритм работы программы не
>проработан.
Я тоже так думал, пока deadlock не стали вылазить на ровном месте и на самой простейшей таблице при апдейте без транзакции. Есть скрпипт который выполняет SELECT/UPDATE||INSERT, скрипт запускается хаотично, вполне вероятна ситуация одновременного запуска. Но по идее PostgreSQL отлично справляется с этой ситауцией, мне кажется , что из-за SMP два управляющих фронтэнда PostgreSQL (при запуске на 2-процессорной системе) не разбирают ситуацию блокировки при одновременном запросе к обоим фронтэндам.
Про порядок следования операций с таблицами в пределах транзакции я в курсе, про тонкости описанные в LOCK-мануале тоже.
>2 - 10) раз в секунду, без проблем. Вообще,если начинать работать
>с БД, то лучше PostgreSQL, в перспективе, нет.
Согласен, но начинать мне поздно, я с PostgreSQL года с 1997 не расстаюсь, проблемы появились только на SMP машине.
| | |
|
| 1.6, saper (?), 10:18, 16/10/2002 [ответить]
| +/– | |
Кстати у нас PostgreSQL на Linux-e 2.4 Slackware 7.1 с SMP (2xP3-1000). | | |
| 1.7, Barmaley (?), 10:38, 21/10/2002 [ответить]
| +/– |
 У меня FreeBSD 4.x и PostgerSQL 7.2.x работают
несколько месяцев.
Автоматическая заливка статистики с маршрутизаторов
CISCO (IP Accouning, Netflow).
Система в постоянной работе. Очень активной.
И все пучком... никаких проблем вообще не наблюдалось...
На сегодняшний день pgsql 7.2.3 на FreeBSD 4.7 P4-2000 | | |
| |
| 2.8, Денис (?), 11:53, 22/10/2002 [^] [^^] [^^^] [ответить]
| +/– | |
У меня - тоже. Free + PostgreSQL. На одном процессоре. А на SMP в реальной работе эту связку кто использует, а? Какие результаты? | | |
| |
| 3.9, Антон (?), 12:39, 19/11/2002 [^] [^^] [^^^] [ответить]
| +/– |
 >У меня - тоже. Free + PostgreSQL. На одном процессоре. А на
>SMP в реальной работе эту связку кто использует, а? Какие результаты?
Пользуемся, почти все нормально. FreeBSD, PostgreSQL 7.2.2. Объем - ~800000 записей.
Из проблем - периодически (от 0 до 5-7 раз в день) падает одно из соединений, предположительно, из-за ошибок в протоколе. В результате чего сервер сразу отключает всех остальных клиентов. Сделали автоматический reconnect при потере соединения у клиента.
| | |
|
|
|
