LINUX.ORG.RU
ФорумTalks

1С лажанулась... Много букв


0

0

Как известно, фирма 1С выпустила программный продукт 1С:Предприятие 8.1 (текущая версия 8.1.8, имеет статус релиза). Самыми вкусными вкусностями этой версии для нас, бесспорно, стали поддержка сервером приложений платформы GNU/Linux и поддержка в качестве сервера БД свободной СУБД PostgreSQL.

Но с выходом продукта, с начавшейся чередой релизов, возникало ощущение, что с PostgreSQL система работает гораздо медленней, чем с MS SQL Server.

В результате исследований стала ясна причина такой работы:

===== Цитата =====

Три дня парился с поиском причины, удалось найти следующее.

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.

===== Конец цитаты =====

http://www.forum.mista.ru/topic.php?id=297521&forum=it

Только стремление выпустить раскрученный продукт, который на деле является во многом пустышкой, сподвигает коммерческих разработчиков ПО так лажаться...

★★★★

Вообще то неспособность оптимизировать такие запросы не с самой лучшей стороны характеризует Postgres.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

> Вообще то неспособность оптимизировать такие запросы не с самой лучшей стороны характеризует Postgres.

— Ага! — Сказали суровые сибирские мужики.

ero-sennin ★★
()
Ответ на: комментарий от Legioner

>Вообще то неспособность оптимизировать такие запросы не с самой лучшей стороны характеризует Postgres.

Ну так на каждый оптимизатор найдётся исключительный случай, на котором первый подавится.

Ay49Mihas ★★★★
() автор топика
Ответ на: комментарий от Ay49Mihas

А 1с8 вообще для чего? НедоERP и слишком мощное для бухгалтерского по.

krum
()
Ответ на: комментарий от Legioner

>Это я к тому, что у пострегса есть уникальная возможность улучшить свой оптимизатор :D

Угу. Тогда следующая версия 1Ц будет выдавать уже 300к строк на том же запросе.

anonymous
()
Ответ на: комментарий от Legioner

>Вообще то неспособность оптимизировать такие запросы не с самой лучшей стороны характеризует Postgres.

при чем тут Postgres??

grinn ★★
()

Может там проблема в том что: сервер 8.1.17 под WinServer 2003

Хотя конечно вряд-ли. Зависание на select - это работа блокировок, скорее всего.

Evgueni ★★★★★
()
Ответ на: комментарий от Evgueni

> Может там проблема в том что: сервер 8.1.17 под WinServer 2003

hm.. есть информация, что постгрес не дружит с сервером 2003?

ps: информация вида "winsvc 2003 масдай по определению" не принимается.

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

Есть упорные и непроверенные слухи о том, что под Виндоус+Постгрес+Сервер1С проигрывает как Линукс+Постгрес+Сервер1С, так и Виндоус+МССКЛ+Сервер1С. Кто обладает более точными данными, пусть поделиться.

redgremlin ★★★★★
()
Ответ на: комментарий от grinn

При том, что кусок вида

CASE WHEN 0 THEN 0 ELSE NULL END

является совершенно нормальным следсвием лени разработкиков генератора SQL-я. И оптимизатор должен относится к этому абсолютно нормально и молча заменять на NULL.

Переполнение ОЗУ при парсинге 35000 строк - это нонсенс. SQL не является сверхсложным языком для разбора.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

> Переполнение ОЗУ при парсинге 35000 строк - это нонсенс. SQL не является сверхсложным языком для разбора.

Не скажи. Все же парсеры языков часто давятся на автогенеренном коде, даже gcc не безгрешен (там, как минимум, есть захардкоденное ограничение на количество строк в файле, типа 512к (а больше - ICE и все тут). Число большое, но я знаю людей, которые напарывались на это, оптимизируя хранение больших статических словарей - приходилось в генераторе не по слову на строку, а по N выдавать).

А переполняется в pg скорее всего не куча, а стек - если там рекурсивный парсер, то это весьма логично.

anonymous
()
Ответ на: комментарий от Legioner

Имея опыт общения с продуктами 1C могу предположить, что от Postgresа здесь мало что зависит. Есть предел кривости, с которым справляется оптимизатор, но эти товарищи имхо его легко могут перебить.

PS: 1С - уроды.

Ximen ★★★★
()

А как вообще у них получилась такая (CASE WHEN 0 THEN 0 ELSE NULL END) конструкция? Что сподвигло генератор такое нагенерить? :)

m57
()
Ответ на: комментарий от Legioner

>является совершенно нормальным следсвием лени разработкиков генератора SQL-я. И оптимизатор должен относится к этому абсолютно нормально и молча заменять на NULL.

ну это просто бугагец какой-то!

Ты правда думаешь, что парсер обязан безропотно глотать все то дерьмо, которое тупые и ленивые "разработкиков генератора SQL-я" соизволили выдавить из себя по капле?

grinn ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.