Связал весь этот зоопарк на обычной офисной машинке (потестировать). Скормил две крупных базы с данными за три года. Так эта связка их пережевывает и не давится, вываливая целенаправленно формируемые мега-портянки в пределах минуты. Создал шесть одновременных подключений, в которых запулил массовые обработки, отчеты и т.д. Результат опять же превзошел все ожидания. В ущерб чему достигается такая производительность? Какие подводные камни? (с)

С чем сравниваешь?

вываливая целенаправленно формируемые мега-портянки в пределах минуты.

Целая МИНУТА!!!
Офигеть, это чем кормите?

(2) В том смысле, что "в пределах минуты" - это очень даже не быстро.

(1) С тестовым сервером на Win2k8+SQL2008. Сервер старенький, железо практически на одном уровне с этой офисной машинкой  (чуть быстрее дисковая подсистема за счет рейда). Остальные условия практически идентичны.

(2) Отчеты бизнес-анализа в "Консолидации" с на скорую руку написанным запросом по всем возможным показателям с присоединением справочных данных. Так-то обычные ОСВ за год в бухне секунд 5 обрабатываются, карточка счета с кучей движухи за год - секунд 10.

Мы частенько из обычных мощных компов собираем сервера. Работают нормально.
Из подводных камней - надежность хромает, несколько раз сыпались аппаратные вещи. В том время когда серверные компы работают годами.
Но если бэкапы делать, то они себя окупают, так как при одинаковой производительности стоят в 2-3 раза дешевле.

(5) Я сейчас не об аппаратной части. Меня удивило то, что решение, где платный только сам сервер 1С, на практике справляется с очень нажористыми задачами лучше монстрячих связок на коммерческой платформе (не в разы, но ощутимо быстрее молотит большие объемы). Возможно, в жертву быстродействию приносится надежность в механизмах постгре - пока сказать не могу.

Надежность в механизмах постгре на корп уровне, подводные камни схемы 1С сервер, Linux и PostgreSQL в сложности промышленной эксплуатации(нет вендора как такового, нету SLA) и дороговизне в обслуживании(хорошие спецы по Linux и PostgreSQL редки и дороги)

(7) Хм... ну эти-то подводные камни как раз вовсе не подводные, тут все понятно :) А есть у кого опыт эксплуатации баз >50 Гб на подобной связке?

(6) Я думаю, ты что-то упустил.

(6) Мы 5 месяцев назад перешли на 1С сервер, Linux и PostgreSQL.
У нас РИБ 2 одинаковых по жлезу сервера. Один 1С сервер, Linux и PostgreSQL, второй Win2k8+SQL2008, пользователей примерно одинаково.
Ну что могу сказать из минусов постгре.
Трудно найти нормального линуксоида.
Отчеты да быстрее почему то формируются. Но вот проведение доков в 2-3 раза медленее. Постоянные блокировки, конфу надо оптимизировать. Стоимость настройки постгре и оптимизации конфы примерно равна стоимости Win2k8+SQL2008, ну и нафиг оно надо.

Короче мы возвращаемся в ближайшее время на скуль.

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

А смысл? компания с базой >50 Гб это не ларки, позволить коммерческую платформу(MS, IBM или Oracle) себе может. Стоит ли эксперементировать?

Кстати один момент, отраслевые решения 1C в основном тестируются на MS SQL и как они себя поведут с другими СУБД это загадка.

(12) Нет смысла, конечно, т.к. поддержка на этом уровне гораздо важней стоимости продукта. Вопрос чисто из разряда "а что, если?".
(13) Тут согласен. Помнится, что-то у меня на оракле категорически не взлетело (при этом на MS SQL прекрасно работало). То ли УПП, то ли та же консолидация, точно не вспомню.

(12) мы вот по тестировали, приобрели опыт, тоже думали халява ))
(13) да конфу пилить и пилить по блокировкам ))

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

(10) Кстати, в двух параллельных процессах групповое проведение однотипных документов запускал - все пучком, рогами не упирались. Конфа - Бухня для Казахстана 2.0.2. Мож, отдельные решения уже довели до ума?

(15) Да я и думаю, что такое решение можно небольшим компаниям проталкивать, где файловой базы уже недостаточно, а решение на MS по карману бьет.

На самом деле свзяка Linux и PostgreSQL и надежна и производительна если ее не использовать в связке с 1С, у нас положительный опыт (3года аптайма) использования отраслевого решения написоного нами и использующее Linux и PostgreSQL в качестве платформы. Приложение было написано конечно же не на 1С)))

(17) Я думаю - там нужен Express

(19) 4 Гб ограничение же. Да и не такой уж он бесплатный - ставить-то его все равно на платную ОС надо.

проблемма MS Expressа ограничение по обьему 10Gb, лучше IBM DB2 Express там ограничение по обьему опер.памяти 4Gb

(21) Да, в 2008 10 Гб. В принципе уже что-то более пригодное.

+(22) Вот только использовать он будет при этом всего 1Гб ОЗУ, что совершенно неприемлемо для серьезных задач даже 10 пользователям.

А вот еще момент к (0) мы когда тестировали 1С сервер, Linux и PostgreSQL он летал.
Когда в работу запустили, он начал через некоторое время проседать. Админ дня 3 потом оптимизировал сидел искал где нагрузка идет, вроде настроил, но опять же скуль поставил и забыл.

(24) А это я еще проверю. Оставлю пока это для разрабов, пусть там базы свои гоняют, заодно и посмотрим.

1С на PostgreSQL работает и очень даже хорошо. На больших справочниках номенклатуры и большом количестве пользователей в этой связке подбор раза в 2 быстрее, чем на MSSQL.
Для быстрого восстановления последовательности документов необходимо чаще делать обслуживание базы данных (полный вакум и реиндексацию по ночам). В принципе можно делать средствами 1с реиндексацию. После реиндексации средствами 1С перепроведение документов начинает просто "летать" как на POSTGRESQL, так и на MSSQL.
Перевод баз с торговлей на PostgreSQL предпочтительнее, базы бухгалтерии лучше пока оставить на MSSQL (пока не выйдет 1С сервер 8.3).
Что PostgreSQL очень любит - так это много памяти, что не любит, так это кривые руки программистов, которые плюют на оптимизацию запросов.
При работе в Linux очень удобно использовать утилиту HTOP, с помощью которой можно сравнительно легко отследить прожорливые и неоптимизированные отчеты.
Если база 1с начала тупить под PostgreSQL и подвешивать Linux сервер, то не думайте, что она будет работать нормально под Win серверам с MSSQL. Скорее всего будет дикий своп, тормоза и резкое сокращение работы дискового массива.

(27) ну немножко тороплюсь, но в целом верно.

2(26) Винда свопит данные МС СКЛ? точно?

(29) Винда свопит данные. Когда MSSQL не хватает оперативы.

2(30) это гарантированно? Потому что например Винда также имеет использует упреждающее чтение, помещая  читаемые с диска файлы в системный кэш, но для МС СКЛ этио не актуально, потому что он использует низкоуровневый доступ к ФС, и читает свои файлы мимо системного кэша Винды.  и использует дя кэша свои механизмы. Так вот про то что Винда свопит данные МС СКЛ - это гарантировано? Он использует памяти более физической? Или это догадки?

вы мне вот скажите на каком линуксе ставить этот Postgresql и сервер приложений? пробовал на CentOS 6.3 и Ubuntu. везде каких то пакетов не хватает...

а важный недочет, что блокировка не на уровне записи как в IBM DB-2, а на целую таблицу идет не учитывается? Просто сталиквался с PostgreSQL , скажем так, работал медленне чем IBM DB-2 бесплатный.

2(33) это только если не использовать управляемые блокировки.

(32) На любом. Недостающие пакеты просто подтягиваешь. К слову, на 1С даже в сорцах лежит, так что хоть под генту собирай.

Кстати, замерил гилевскими попугаями на идентичных виртуальных машинах на одной железяке (ВМ запускал по очереди для чистоты эксперимента). 19 попугаев постгре против 13 МС. Конечно, нужно учесть ресурсоемкость самой системы (линь без гуя ставил, с минимумом сервисов, в винде даже без установленных ролей сам интерфейс и фоновые службы МС покушать любят).

2(26) не репрезентативная выборка.

то есть (36)

(31) Я может неправильно выразился. Винда свопит данные при недостатке памяти, но я не сказал что она свопит данные MSSQL. Скорее она свопит данные 1C сервера в виде кучи процессов rphost. балы такая проблема - при вводе новой базы на измененной конфе CentOS 8.4 начал безбожно отключаться - 1с Сервер 8.2.17.253 съедал по 8гб за 2-5мин. 1С программисты выразили предположение, что это Postgre. Перевели базу на MSSQL, практически ничего не поменялось, только сервер перестал зависать. После часа исследований выяснилось, что проблема возникала при работе под ограниченными правами. Поэтому и говорю, что если база под PostgreSQL съедает всю оперативу и вешает сервак, то это не говорит, что она будет работать нормально под MSSQL, а вот отследить ошибку под MSSQL зачастую намного сложнее.

(34) ну вы хотите сказать, что iBM хуже? IBM рекомендуют использовать управляемые блокировки.

2(39) а откуда предпосылка что сервер 1С на той же машине что и сервер МС СКЛ?

(37) Какбе для масштабных тестов нет времени и особого желания. В конце концов, реалии показывают, что гибкость и масштабируемость MS SQL перевешивают потенциальную "быстроту" постгре в долгосрочной перспективе, поэтому все эти тесты делаются сугубо из факультативного интереса.

2(40) пофантазируй еще.

2(42) а в чем гибкость и масштабируемость? Постгресс гораздо более масштабируем.

(41) Я и не говорил, что они на одной машинке.

(42) В MS SQL помимо самой СУБД входят еще и Analysis Services, Reporting Services, много вкуснейших плюшек в плане сопряжения с другими продуктами. Много там чего, в конечном итоге. Конечно, напрямую к 1С это не относится, но не 1С единой жив человек.

(43) ну судя из ваших слов, про прочих равных PostgreSQL  будет лучше IBM DB-2 во всем? я думал из за блокировки на уровне записи, лучше PostgreSQL  , это даст перепроведение более быстрым и менее заметным для других пользователей.

(32)CentOS. Кое-какие файлы все равно необходимо доустанавливать, SELinux отключить.

2(45) Ну так тогда смысл упомининания свопа?

(48) а что именно и где взять нормальный мануал?

(47) PostgreSQL перепроводит документы достаточно быстро, особенно после выполнения реиндексации. Другое дело, что в течение рабочего дня лучше не эксперементировать такими вещами.

2(47) смысл моих слов в том, что ваше замечание неверное в случае управляемых блокировок.

(49) Опять не так выразился - 2 физических сервака, на одном Windows 2008, 1С сервер и MSSQL, на другом CentOS, 1с сервер и PostgreSQL

http://infostart.ru/public/173394/

пользуйтесь внутренней базой данных виндуз - бесплатно и легально

(50) да полно информации, хотя бы здесь http://www.alsigned.ru/?p=1756. И еще на сайте 1С дополнительная информация.

+(44) Чисто гипотетически базы 1С на постгрессе могут работать на вот таких машинах:
wiki:POWER7

(52) не ты ли обещал до 9 мая тесты ДБ2?

2(58) А уже какое?

(59) а где и что за тесты?
не понял iBM Db-2 Лукчше работает в автоматических блокировках или управляемых?  просто я читал, что управляемые желательные, щас даже тему найду.
(51) что каждый день надо делать реиндексацию БД?

Ну и еще один "маленький" нюанс: в Windows-инфраструктуре использовать никсы - это тратить ежемесячно атстатыщ на хорошего никс-админа, умеющего еще и в постгре.

(59) ну, типа 8 :)

(61) ложь

(61) Достаточно один раз настроить. И можно наблюдение повесть на любого адекватного работника.

(60) управляемые вообще лучше. особенно для постгре, но и для дб2 и мсскуля тоже выигрыш есть

(61) правда

(56) по ссылке работа с исходниками... а что у 1с за инструкция?!

2(60) Что такое лучше? лучше в абсолюте? Так не бывает. потому что любые усложнения, любые костылики несут с собой overhead'ы. Просто на каких-то лобъемах эти оверхеды все равно приносят в сумме преимущества, а в каких-то нет.

Вот пулемет - это клевое оружие? Наверное клевое, если бить носорогов, и видимо плохое если перепелов.

(68) Особенности релиза:
1. Изменен списк поддерживаемых дистрибутивов Linux:
RPM
   Centos 5.7, RedHat 5, Fedora 8, ASP Linux 12(14)
   Centos 6, RedHat 6, Fedora 8, 9-16  (необходима установка openssl098e)
Установка openssl098e:
yum install openssl098e
ИЛИ
openssl098e-0.9.8e-17.el6.centos.i686.rpm (http://rpm.pbone.net/index.php3/stat/4/idpl/17474708/dir/centos_6/com/openssl098e-0.9.8e-17.el6.centos.i686.rpm.html)
openssl098e-0.9.8e-17.el6.centos.x86_64.rpm (http://rpm.pbone.net/index.php3/stat/4/idpl/16618304/dir/centos_6/com/openssl098e-0.9.8e-17.el6.centos.x86_64.rpm.html)

DEB
   Ubuntu 10.04, 10.10, 11.04, 11.10

2. Включен по умолчанию сбор статистики по временным таблицам( модуль online_analyse(ссылка на README.online_analyze))
3. Включена по умолчанию коррекция оценки оптимизатором количества строк в пустой таблице ( модуль plantuner(ссылка README.plantuner))

(0) ну, наконец-то кто эту связку похвалил.
у самого так.

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

(64) Правда.
(65) "Достаточно один раз настроить" - это разве что к роутерам относится. В раз и навсегда предопределенной схеме сети. А мы говорим про продакшн-сервер, который и на аутсорс не отдашь из-за крайне жесткого SLA, и дятлу-эникею не доверишь.

2(72) А виндовс доверишь, или платить ему будешь в два раза меньше?

(71) что ?

(72) поверь мне, в роутерах тоже периодически надо что-то делать ;)
например acl-листы

(68) Там не работа с исходниками.

(76) да и вообще можно готовую сборку взять с эзерсофта и не париться.

(62) до 12-го оттягиваю тогда

(75) а чо это ?

Эникейщики тоже разные бывают. Некоторым даже картриджи бы не доверил увозить на заправку.

(77) Этерсофт у нас не пошел.

(57) Если соберут сервер приложений хотя бы для Linux on Power, то будет. Правда, уже который год ожидается выход беты CentOS для Power.

(73) За быкапами следить - доверю. А вот в нюансах, которые могут возникать (к примеру, отчет отказался формироваться из-за слишком малого shmem) эникей уже вряд ли разберется.

хватит кормить жирных котов Майкрософта!
Даешь толстого клиента 1с под линукс!

(80) я таким у себя говорю самим заправить. В грязной комнате.)

2(82) почему агент сервера 1С и сервер ИБ должны быть на одной машине?

(75) А что мне верить-то? Я этим пятнадцатый год занимаюсь :) Поэтому и оговорку добавил насчет "раз и навсегда предопределенной сети".

Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/da0s1a    495M    445M     10M    98%    /
devfs          1.0k    1.0k      0B   100%    /dev
/dev/da0s1e    495M    176M    279M    39%    /tmp
/dev/da0s1f     28G     18G    7.4G    71%    /usr
/dev/da0s1d    1.9G    1.8G    -36M   102%    /var
/dev/da1s1d    132G    120G    1.4G    99%    /mnt/volume

2(82) Есть версии Постгреса для AIX

+(87) чо посоветуете ?

(78) лучше в плане производительности и основных действий:
1) Массовое перепроведение
2) Построение отчетов
3) Хранение данных большого количества данных.
4) не каждый день индексировать.
5) Отказустойчивость в IBM Db-2 плохо работае с трэшом и каталог.
6) Закрытие месяца 20 счета, IBM DB-2 че то не в типовых конфа при больших данных жрет память жеского диска очень много и не закрывает...

2(90) что за хрень? почему мне?

(91) вы как то связаны с IBM db-2 я знаю точно ))

2(92) серьёзно? и в таком случае хрень из (90) сразу становится ясна?

(93) ну я отметил основные вещи, что считаю важным, для работы 1С и где оно быстрее работает)

это я на ваш ответ про пулемент, по ком стрелять надо.

(94) быстрее работает там, где меньше документов.

(85) Не должен, конечно. Просто использовать Power только для СУБД как то неинтересно, что ли. Там  и повышенная частота и кэш на процессоре в несколько раз больше, чем на х86 и масштабирование до 32-х процессоров...
(88) Очень хорошо, значит, с большой долей вероятности, и PostgreSQL от 1С тоже соберется без особых проблем.

(70) ссори конечно за отзыв, но дельной инфы в этом списке ноль

2(95) А я сказал что управляемые блокировки это не панацея.
Например берем монопольный доступ. Проводим документы. Все проводится за 1 минуту.
Потом переписываем проведение с управляемыми блокировками, проводится за 70 секунд.

Но, если брать не монопольный, а конкуретный доступ, то при 10 пользователях, которые пытаются проводить например каждый свой документ прихода, проведет только один. А остальные девять только по очереди после первого. И в итоге это у них займет ну например 10 минут.

А при управляемых бблокировках эти же 10 пользователей проведут свои документы каждый за 70 секунд, и все вмсете тоже за 70 секунд, при чем ни один не будет подозревать что кто-то еще что-то проводит.

Теперь понятно?

вот что я имел в виду про пулемет, носорогов и перепелов.

Вообще, думаю, в порядке эксперимента можно такие комплекты продавать особо прижимистым клиентам, которым жалко оплачивать лицензирование серверной винды и MS SQL. И посмотреть на стоимость владения.

Но если то что тебе не нравится в Постгресе - это то что он версионник и блокирует всю таблицу, то все что нужно - переписать конфу так, чтобы использовались управляемые блокировки, проведение одного документа при этом быстрее не станет,  а  даже увеличится - понятно почему, потому что блокировку еще нужно организовать и наложить. Но зато это в потенциале повысит паралельность работы пользователей.

Ну и в этой связи я по-прежнему не понимаю. как (90) ко мне относится и что вообще означает.

особенно такие забавные, измеряемые выражения как "данных большого количества данныхъ" или "очень много".

Маратыч , в связке "CentOS+1С:Сервер+PostgreSQL" нашёл только одно узкое место -системный администратор. Как только наш линуксовоид уволился - первое же обновление платформы показало благодаря кому пять лет всё летало и всех всё устраивало.

(98) Качаешь с сайта 1с архив пакетов. Распаковываешь его. Установить достаточно 4 пакета в определенном порядке. После этого заходишь в каталог /opt/1C/v8.2/x86_64/utils и запускаешь config_server. Дальше смотришь каких пакетов нет и доустанавливаешь. Где-то так.

(104) Вот-вот, я о том же. Выше товарисчи утверждают, что можно один раз настроить и забыть, хехе.

2(97) сарказм оценил.. :) да, это конечно ничего не значит... до тех пор пока кто-то не попробует и у него не получится...

(106) просто 1с клепает платформы как пирожки. постгре можно настроить и забыть...

(106) А что - не так? Пришел человек, установил операционку, накатил постгрю, рассказал, как обновлять 1с сервер, задокументировал порядок и все. Разовая работа фактически.

(109) При обновлении 1С сервера могут поменяться зависимости, соответственно, нужно уметь как минимум читать сообщения консоли и уметь устанавливать новые пакеты, не угрохав при этом существующую экосферу. Рядовой эникейщик при виде самой консоли уже в ступор впадает, не говоря уже о пользователях.

(107) а выставление режима блокировок в конфигурации, что нам дает?
"большое количество данных", это количество записей более 1 млн в регистрах бух. и тд.

(108) Кто сказал, что с обновлением платформы ВНЕЗАПНО не понадобится пропатчить постгре?

2(111) это дает ровно то, что написано в букварях.
Буквари - полезные.

(112) любой человек с мозгом сможет сделать бэкап, воспользоваться гуглом, потренироваться на кошках, сделать в продакшене. Если у вас нет человека с мозгом - рекомендую нанять.

(111) У среднего пошиба дистрибьютора продуктов питания блокировки в конфигурации - это крайне больная тема, когда работают несколько операторов и при этом идет выгрузка данных с КПК, формирующая проведение однотипных документов.

(110) Если уж на то пошло - на крайний случай можно настроить сервер PostgreSQL на Linux, а 1с сервер на Windows и дать канал на 1Гб.

(114) Ну что за сказка про белого бычка? Человек с мозгом и будет стоить атстатыщ, о чем я и говорю. Или вы идейных имеете в виду, которые, умея пользоваться мозгами, гуглом и памятью, сидят до пенсии на 20 килорублях?

(116) См. (112).

(118) Зачем?

(117) нет. просто если есть человек с мозгом, который админит виндовс, то он не будет сильно сопротивляться расширению своего кругозора. человек без мозга - будет. ничего сверх сложного там нет.

(119) Что "зачем"? Я говорю о том, что изменение в механизмах платформы может повлечь необходимость апдейта СУБД.

(120) С точки зрения инженера, вообще не бывает неразрешимых задач. Человек, который во всем этом разобрался, редко зацикливается на админстве.

(121) судя по http://users.v8.1c.ru/project.jsp?id=AddCompPostgre она обновляется раз в год, а судя по http://downloads.v8.1c.ru/content/Platform/8_2_18_44/1cv8upd.htm - ни разу не _требовалось_ обновление СУБД

(122) да, но админство в виде настройки сервера 1с и субд занимает 1 раз несколько дней (если вообще с 0), затем при обновлении платформы по нескольку часов. нагрузки почти не дает.

(121) Версия 8.4 держится уже около 3 лет. В любом случае - обновление версии PostgreSQL тестирование - это разовое вложение.

(125) Перефразируя: "Нет ничего более постоянного, чем разовое". Приведу пример - у нас была развитая сеть по республике, все организовывалось через VPN зоопарком роутеров, наличествовал полный комплект геморроев вроде IPSec и VoIP со своими заморочками. Изначально задача стояла: "Настроить, закрыть шкаф и выкинуть ключ", - т.е. ничего больше в конфигах не ковырять.

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

разве это плохо?

(127) Смотря с какой точки зрения. А вообще я имел в виду, что "один раз настроил и забыл" редко применимо к продакшн-сервисам, подобным 1С, и от ОС/СУБД/железа особо не зависит.

(126) В любом случае можно договориться с человеком на меньшую сумму поддержки. У нас как времени на циско-администрирование были намного выше, чем на постгрю.

конкретизирую свой вопрос.
на какую ось можно поставить последнюю версию PostgreSQL и есть ли инструкция без всяких сборок из исходников?

(130) речь про линукс есесно, на винде все работает как часы. желательная ось должна быть CentOS, которая хорошо работает под виртуализацией.

(130) Поставил на убунту сервер. Инструкций полно, к примеру: http://ipclub.dp.ua/2013/02/06/установка-1с-8-2-17-143-на-ubuntu-12-10-x64/ или http://servis-it.ru/index.php/Установка_сервера_1С:Предприятие_8.2_на_Ubuntu_12.10

+(132) Ну и на центос вот: http://www.achlab.ru/ach/2011/12/23/1c-8-2-postgresql-centos-6-1/

(130) И да, не надо ставить _последнюю_ версию постгре, нужно ставить ту, что 1С предлагает, уже пропатченную.

(130) CentOS, PostgreSQL качать с http://users.v8.1c.ru/version.jsp?id=AddCompPostgre&ver=9.1.2-1.1C

(130) Windows

(137)PostgreSQL не оптимизирована для работы под Windows.

(138) Вы точно знаете ?

(139) судя по данным моего теста производительности - при многопоточной работе постгре сливает на виндусе: http://forum.infostart.ru/bitrix/components/bitrix/forum.interface/show_file.php?fid=303313&width=500&height=500
и на линуксе
http://wstaw.org/m/2013/05/08/0.png

первая ссылка вот: http://forum.infostart.ru/bitrix/components/bitrix/forum.interface/show_file.php?fid=303314&width=500&height=500

или вот суммарная на линуксе: http://wstaw.org/m/2013/05/08/0_1.png

правда там в это время типа юзеры работали - по этому флуктуации

(140) Многопоточное тестировалось на конфе с управляемыми блокировками?

(144) да

(144) И насколько сливает? Может, все в пределах погрешности из-за тонких настроек? У меня, наоборот, проведение ЧУТЬ быстрее, но в пределах погрешности (в отличие от чтения данных, где прирост весьма высокий).

До 30 подключений постгрес работает очень хорошо, около 100 помирает, больше 150 - просто все стоит. На неплохом сервере работала только бухгалтерия - добавлял зуп - все умирало. Сейчас на нем микрософт скл - работает все без тормозов, на втором серваке зеркало настроил на всякий случай

(147) виндус? см графики (140)-(142)

(147) Хм. По идее постгре все-таки промышленного уровня СУБД, не должно на таких нагрузках укладываться намертво.

(146) при достижении (в винде) количества подключений > количество ядер суммарная производительность всех протоков падает в несколько раз, на линуксе суммарная прозводительность остается примерно на одном уровне (как мсскуль на винде)

характерный график мсскуля http://wstaw.org/m/2013/05/08/0_2.png

(151) + 32 (16*гипертрединг) ядра

(149) Там ничего не слыхать про PostgreSQL 9.2? Когда ее оттестят, а то уже кучу ошибок поправили, а там все еще прежний пакет болтается.

(153) ХЗ, я не настолько вплотную этим занимаюсь :)