Глюки 1С 8.1 с PostgreSQL #297521


#0 by ManHunter
Глюки PostgreSQL с ЗУП. При расчете НДФЛ, даже при самом минимальном (5 сотрудников в документе из 2000 чел работающих) на postgresql-8.1.5-x.1C - падает клиентское подключение с Out of Memory (причем память сервера СУБД забивается процессом PostgreSQL полностью - вся оперативка (8 гигов) и своп на 2 гига. На postgresql-8.2.4-x.1C - все считается, но сервак использует только 2,7 Гб ОЗУ и тормоза жуткие (на MS SQL 2005 - 20 сек. против 30 мин. на PostgreSQL). Данная проблема возникает на сервере под Linux и под Windows. Отсюда предположил, что дело не в ОС. Кто нибудь сталкивался?
#1 by Postgresmen
какие настройки Постгреса используете (shared_buffers, effective_cache_size и т.д.)?
#2 by ManHunter
Используются настройки по умолчанию, для 8.2.4-x.1C: max_connections = 100 shared_buffers = 27MB max_fsm_pages = 204800 autovacuum = on max_locks_per_transaction = 150
#3 by Ay49Mihas
fsync отключал?
#4 by Rusel
С партнерского сайта: ВОПРОС ЗУП 2.1.9.2  при  Расчете НДФЛ в документе Начисление Зароботной платы работникам организации на сервере начинает расти память до предела после чего вылетает сообщение Error: Out of Memory. сервер 8.1.17 под WinServer 2003          PostgreSQL 8.2.4          ОЗУ 2048 Mb клиент WinXp  512Mb Данная проблема тестировалась  и воспроизводилась несколько раз 1. в файловой базе - расчет проходит за 5 секунд   2. серверный вариант под SQL - расчет был за 4 секунды 3. серверный вариант под PostgreSQL - расчет был около 5 минут и выдал ошибку Как можно решить эту проблему ??? p.s. переход на SQL не решение. ОТВЕТ Это проблема конфигурации, которая не оптимизирована для работы с различными СУБД. В этом документе используется конструкция ПОЛНОЕ ВНЕШНЕЕ СОЕДИНИЕ, для которой в PostgreSQL реализована лишь частичная поддержка (подробности есть на диске ИТС). Кроме того, эта конфигурация разрабатывалась для использования с 1С:Предприятием 8.0 и не оптимизирована для работы с 1С:Предприятием 8.1.
#5 by Rusel
+ Такая или похожая проблема может возникать и в других местах программы. Код конфигурации ЗУП редакции 2.1 не оптимизировался для использования под различными СУБД и вообще для использования в версии 8.1 платформы. Для работы в версии 8.1 разрабатывается конфигурация редакции 2.5. То явление, с которым Вы столкнулись, с большой вероятностью связано с применением в текстах запросов полного внешнего соединения. Пересмотр кода конфигурации и его оптимизацию для работы с различными СУБД мы стараемся выполнить в ред. 2.5.
#6 by budidich
Такая же фигня и с УПП. И что теперь делать? Там по моему в запросе, который подвисает полного внешнего соединения нет.
#7 by ManHunter
Три дня парился с поиском причины, удалось найти следующее. 1. В ЗУП 2.1.12.3 в запросе расчета НДФЛ нет полного внешнего соединения, там вообще во всей конфигурации таких конструкций не встречается. Поэтому комментарии техподдержки 1С в случае с типовой ЗУП 2.1 не совсем понятны. 2. При включении детальных логов в PostgreSQL выявлено, что 1С запрос НДФЛ - около 500 строк транслируется в запрос pgSQL - около 35000 строк (не слишком ли много ?!), в котором часто встречаются не совсем понятные с логической точки зрения конструкции типа: CASE WHEN 0 THEN 0 ELSE NULL END 3. В случае с PostgreSQL версии 8.1.5 - зависание запроса и последующее переполнение ОЗУ происходит на стадии PARSE, т.е грамматического разбора запроса pgSQL и подготовки данных для его выполнения. В случае с PostgreSQL 8.2.4 - длительное подвисание без переполнения памяти происходит на стадии SELECT, т.е во время выполнения запроса. 4. Скачал исходники PostgreSQL 8.2.5 с официального сайта postgresql.org, собрал их с патчами 1C от версии 8.2.4-3.1С, уменьшилось время выполнения эталонного запроса на 10%, но это очень мало. Я думаю что основная причина кроется в неоптимизированном трансляторе запросов 1C -> pgSQL. У кого какие мнения?
#8 by Ay49Mihas
Непечатные мнения принимаются?
Тэги:
Ответить:
Комментарии доступны только авторизированным пользователям