Производительность 1с и *nix платформ в серверном исполнении

Производительность 1с сервера 8.1 в линухах такая же как и в винде. Все это упрется в производительность сервера баз данных. Постгри он и в Африке постгри. При очень больших объемах данных вы уткнетесь в его производительность. DB2 лучше, но мы его пробывали только в качестве теста. Реально на нем работать страшновато, хотя при серьезной подготовке специалиста можно было бы попробовать. Все это касаемо 8.1 и больших баз данных. На маленьких базах постгри вполне хватит.
8.2 пробуем только в тестовых режимах. И я думаю у многих так, поскольку готовых конфигураций под 8.2 со всеми документами управляемыми формами я еще не видел, УПП по крайней мере точно . Так что реальные данные о производительности, и что немаловажно, стабильности можно будет услышать только после февраля-марта.

 

мои коллеги неоднократно сталкивались с "экономией" денег предприятиями, когда они выбирали Postgres, через некоторое время они начинали сильно сожалеть об этом.

 

Если базы небольшие (менее 100 гигов) то с постгри (имею опыт только под мандривой) проблем не будет никаких (я так надеюсь), при условии что бэкапы делаются регулярно. При базе в 200 - 300 гигов я бы уже побоялся ставить постгри.. На такие объемы используем пока что только MS SQL. Переводить на другие платформы знаний не хватает да и острой необходимости пока что не было. Только из "спортивного" интереса пробуем.
А так,Постгри для 1с 8.1 - вполне бюджетно. У нас на одном из заводов по финансовым причинам он стоит. За 2 года был только один затык но действительно серьезный. Решили проблему только снеся базу начисто с сервера и создав ее заново. Причем именно в новую базу!!! с загрузкой из dt и соответственно генерацией таблиц и индексов. Видимо серьезный косяк был в служебных данных, кэше или в планах запросов если даже поднятие бэкапов или загрузка dt в туже базу не приводило к востановлению работоспособности.

---------- Сообщение добавлено 16.11.2010 11:42 ----------

А можете привести примеры причин почему они начали жалеть об этом? Профессиональный интерес ..

---------- Сообщение добавлено 16.11.2010 11:48 ----------

У меня были случаи когда запрос с большим количеством объединений по куче полей просто отказывался работать в MS SQL2000. Потом конечно его переписали, разбив на временные таблицы, но в оригинале он выносил мозг MSSQL2000 (Расчет взносов ЕСН в одном из первых релизов ЗУП 2.5). Это я к тому что иногда и код не расчитан на возможности сервера БД.

 

а какая версия постгреса используется в 1С-ке?

 

вам сюда http://pg1c.ru/
и сюда
http://v8.1c.ru/overview/postgres_patches_notes.htm

 

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

---------- Сообщение добавлено 16.11.2010 14:15 ----------

выдавал синтаксическую ошибку или медленно работал?

 

Вылетала Ошибка SQL с определенным кодом (сейчас уже не помню, но попытаюсь поискать). Как удалось расшифровать код ошибки - ошибка переполнения возникшая при большом количестве объединений (так по крайней мере отписалась 1с). Решили тогда эту проблему оперативно - перебросили базу на ms sql 2005 (как посоветовали 1с-ники) и забыли об этом. Благо было 2 сервера sql.
Сейчас на одном из заводов крутится на postgreSQL 8.3 под федорой 8.0 несколько баз. Самая большая больше 40 гигов. Да запросы работают медленнее чем в MSSQL раза в 2 но они и нестоит ничего... Если говорить о привязке к 1с то кроме CAL 1c еще бы пришлось оплачивать CAL MS SQLServer`а (которые стоят кстати дороже CAL`а 1с). Падений индекса нет. Сервера загружены круглосуточно.
Вот что наш админ конкретизировал

---------- Сообщение добавлено 16.11.2010 14:56 ----------

Вот кстати похожая ошибка, но не она... Тоже воспроизводилать только на 2000м. на 2005-м работала.
http://www.forum.mista.ru/topic.php?id=364948
http://www.forum.mista.ru/topic.php?id=373135
http://www.buh.ru/forum/thread.jsp?id=481103
ошибки в данных (типе данных) там небыло!! Запрос прекрасно проходил в 2005-м.
к сожалению ссылку на партнерский сайт, где обсуждалась эта ошибка, выложить не могу.

 

не знаю. Уже давно использую только серверные варианты.

 

Skype использует PostgreSQL для хранения базы пользователей и ничего не боится. Я думаю, база у Skype будет побольше гигабайта. Возможно, конечно, что криворукие 1С-ники что-то поломали внутри постгреса своими патчами. Но я подозреваю, что "не покладающий рук" админ просто не в курсе про существование файла postgresql.conf.

 

постгрес хорошо улучшается от версии к версии, а 1С до сих пор сидит на 8.3, судя по

 

Что подразумевается под некими ограничениями?

 

http://v8.1c.ru/overview/postgresql.htm
и
http://v8.1c.ru/overview/Term_000000642.htm#1
особенно


Если я правильно понимаю, то фраза (для postrgre) о том, что "в режиме автоматического управления блокировками в транзакции используются табличные блокировки СУБД" говорит о том, что MS SQL оно точно проиграет при тестах на производительность при многопотоковом проведении документов в типовых конфигурациях.

 

MenBS, все зависит от квалификации специалиста, занимающегося настройкой системы. Вот достаточно показательный пример: http://www.sql.ru/forum/actualthread.aspx?tid=528465

 

Beagle 2,
это не показательный пример, это какой-то частный случай какой- то обработки в какой-то организации.
за показательными примерами нужно сюда:
tpc.org

 

AlTk, топикстартер вроде спрашивал не о производительности синтетических тестов, а как раз про частный случай обработки в организации, конкретно в 1С.

 

Beagle 2,
да мало ли что он там накрутил в серверах. может если бы он дальше стал крутить - MS SQL быстрее оказался, с другой стороны может какая-то другая операция на постгресе теперь гораздо медленнее выполняется или на том же сиквеле.
зачем на примере какого-то конкретного частного случая, приучастии человеческого фактора проводить обобщения?

ПС. я уже писал как-то. вроде бы одна и таже БД, а на разных филиалах разная подкрутка нужна.

 

[удалено]

 

Т.е. вы считаете, что постгрес на винде - несинтетический тест?

 

Странный вопрос. Постгрес на винде - это вообще не тест. Тест - это выполнение какой-либо задачи. Работа 1С на реальном наборе данных - это не синтетический тест.

 

Beagle 2, Выполнение одинаковой задачи на ксеоне с мсскл и селероне с постгресом - тоже будет реальным тестом?
+ конфиг не выложил тестер. Тот же мускул после ковыряния конфига в несколько раз быстрее будет работать. Не учли?

 

Вот мусклу я бы точно ничего ценного не доверил, особенно на штатной MyISAM... А если учесть его манеру работы со вложенными запросами, то неудивительно, почему 1С выбрала постгрес.