Столкнулся тут намедни с совсем непростой задачкой
- развернуть трехзвенку на 100 баз

1С сервер сдох сразу при добавлении в список ИБ такого количества баз,
наплодил более 1000 рабочих процессов и как следствие "сдох" сервер, те ОС Win 2008R2 c 32 гигами памяти.

Настройки стояли по умолчанию - 8 ИБ на процесс, 128 подкл. по процесс

Дальнейшее кручение 1С сервера не помогло.
Решил разнести сотню на 3 сервака, по 30+ баз, результат тот же, только процессов стало по 30-40 шт, но лучше от этого не стало - теперь 3 сервака загружены под 100% проца и памяти.

Вопрос - чего делать-то?
или на такое кол-во 1С сервер не способен и забыть про эту платформу
%(

(0) есть такой глюк в 8.3
у тебя, я так понимаю не актуальная версия?

Со всеми базами одновременно работают? Верится с трудом...
Ну так и добавляй-удаляй ее автоматом при запуске

(79) Да какие проблемы-то? Базы бэкапятся средствами PostgreSQL еженочно (а иные и чаще), все автоматизировано через скрипт на bash, который запускается кроном.
Некоторые не бэкапятся вообще, ибо тестовые.
Например, есть базы:
buh-firma1-2014
buh3-firma2-2013
zp-firma1-2011
zp-firma2-2013
ut-firma3-2014
buh-firma3-test
audit-firma5-2012
audit-firma6-2013

Скрипт делает список баз, отсеивает из списка базы, в названии которых есть test и audit, затем бэкапит все базы, кроме ut-firma3-2014 каждый день в 02:15, а ut-firma3-2014 бэкапится в 8-30, 10-30, 12-30, 14-30, 16-30 и 18-30. Все это, конечно, кроме выходных.
Скрипт - десяток строк на bash, если кому интересно, могу запостить.

Все бэкапы копируются на специальный сервер-хранилище с аппаратным рэйд-массивом на кучу терабайт.
В итоге можно вытащить любую базу на любой день за три последних года.
Здесь присутствие админа сводится к выборочному тестированию восстанавливаемости баз из бэкапа и контролю системы мониторинга (nagios).

(27)"Ну и что, выгружаешь нужные данные в др. базу и отдаешь клиенту." - когда-нибудь объединения баз делал? навряд ли.
Там все разное - настройки, документы, ответственные и т.д.
Да что объяснять человеку, который ничего не видел.

(39)"А попробовать запустить сервер 1С строго на железке?"
- это виртуализация заставляет плодить процессы у сервера 1С? весьма.

(76)"Работал со 120 базами"
на одном 1С сервере?

(90) Todorov:
Все это прекрасно.
Вопрос один: "Кто создает и перепрописывает базы в трехзвенке, если бухгалтера впадают в ужас от просьбы скачать и запустить файл?"

(90) ни одна нормальная база не работает на PostGre.
Или постоянно проблемы. И не будем "что я делаю не так?!" и ручки в боки.
Пользователи "не так" сильно мучают базу.

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

(96) Вообщето это так сказать"мировая практика". По крайне мере обычно "работа на скуле" оговаривается отдельно, вон даже у scloud это отдельная опция за реальные деньги.
Единственное сервис где нет выбора - это 1С фреш, по крайне мере они это не афиширует, но при условии что разделитель в платформе не просто так появился (а он там походу реально юзается), то скорее всего у них на скуле

(96)
> зачем бухгалтерам чего то качать и запускать
1Сное "Руководство пользователя" бухам тоже читать противопоказано?

(98) хотя бы НК читали бы, а ты про руководство

(91)Вы похоже не в теме немного.
При чем тут объединение?
Какие могут быть разные настойки?
Есть одна база, ее ведет аутосорсер, пока клиент ему платит.
Клиент заявил что уходит, и платить больше не будет - аутосорсер отдает ему базу.
Все.

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

Иначе он не нужен, и более того может быть вреден.
Бухгалтерский аутсорс предполагает множество баз клиентов и нескольких работающих с ними специалистов.
Т.е следующие утверждения в 95% случаев будут верными -
1)С одной базой в один момент времени работает один пользователь.
2)Количество одновременных пользователей работающих с базой никогда не превышает трех.
3)Все базы типовые.

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

(102): 95% времени эти базы там просто ЛЕЖАТ. А не постоянно крутятся пользователями. У меня 5 клиентов бух-аутсорсеров, я знаю, про что идет речь.

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

(102)
"восьмерка в файловом режиме изначально работает очень печально" - очень спорное утверждение. При условии что бух на аутсорс это обычно не 200 документов в день, а дай бог 200 в месяц, т.е. размер копеечный и на файловой версии будет летать, особенно по сравнению со скулем, где всё делается через фоновые процедуры, т.е. минимум с задержкой в 2 секунды

(104)"т.е. размер копеечный и на файловой версии будет летать" - проблема файловой не в плоскости "200 доков в день или в месяц" (файловая даже будет быстрее при прочих равных), а в блокировках и корректному размежеванию пользователей.

+ при работе от нескольких пользователей по сети.

(94) Вариантов много - от "специально обученного специалиста" до http://habrahabr.ru/post/179405/

(95) В том-то все и дело, что все работает. Нормальное железо и выверенные настройки postgresql.conf. Так что не надо  безапелляционных утверждений, что "не работает". Точно также получается, "у меня не получилось, значит программа хлам".
Проблемы, с которыми мы сталкивались, были связаны в основном с платформой 1С, реже - с ошибками в конфигурации, но СУБД ни разу не доставила никаких неприятностей. Одновременно с одной базой работают от 1 до 20 человек, как правило 8-15.

(105) ?
На файловой в рамках одной организации вполне себе 2-3 человека уживаются без проблем
Что там делать среди пользователей? 1 файловая база = 1 фирма.
В одной базе врядли одновременно будут работать больше 1,5 человек, в силу специфики, поэтому о каких " блокировках и корректному размежеванию пользователей." идёт речь?

(103) Не совсем, он один раз включит мозг, напишет скрипт, который будет сам делать в нужное время архивы, копировать их в места хранения, при этом упорядочивая либо по дате, либо по клиенту, либо и то, и то, скажем, через жесткие ссылки.
И главный плюс архивации средствами СУБД как раз в том, что не надо останавливать процессы или выгонять пользователей, поэтому архив (снапшот, по сути) можно делать хоть каждый час, пользователи об этом даже не догадываются.
Хотя, если 1 база = 1 бух, может, и правда, проще файловую.

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

(110) в файловой - без выгона пользователей, с гарантированной целостностью? О_О

(102)
100 ИБ хранящихся на диске это нулевая нагрузка.
А запущено одновременно бывает лишь несколько.

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

(105)Откуда там блокировки возьмутся при одном ползователе работающем в базе?

(11) нуда, теневое копирование

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

А когда в базе сидит один бух и подгоняет годовой отчет к более менее приличному виду, это вообще никакой нагрузки, и файловый вариант тут по скорости наоборот выигрывает у скуля.
По поводу надежности, да меньше.
Но опять же при такой низкой нагрузке на базу и одном пользователе, вероятность краха базы минимальна.
Да и собственно крах базы не вызовет никаких особых проблем.
Ну что страшного будет, если базе придет кирдык? Бухгалтер восстановит базу из снапшота, потеряв данные за несколько часов, и все.

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

(108) полтора человек терпимо.
(114) очень даже может и один сам себя заблокировать. Видел не раз.
1С, все-таки.

(117) > полтора человек терпимо.
Даже полтора на базу это 150 это одновременно(!) в пессимистическом прогнозе в период сдачи отчетности/ расчета зарплаты - удачного хостинга и легкой нагрузки на жесткие диски)).

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

(118) по идее, должно быть 150 виртуалок и 150 серверов 1С.
Так что тут ничего не докажешь - не работает, покупай отдельный 1С.

(180)Откуда такие цифры?
Объясню подробно -
в конторе   5 бухгалтеров штате, еще три приходящих/работающих удаленно.
Контора оказывает услуги по ведению бухучета на аутсорсе.
У нее сто баз клиентов.
Как правило с ними работают только штатные сотрудники, т.е в конкретный момент времени как правило открыто пять баз, и в каждой базе работает по бухгалтеру.
Иногда бывает что удаленщики тоже подключаются и получается сем баз открыто, и в каждой базе работает один человек.
Остальные базы спокойно на диске, их никто не трогает.

(121) ну не 150, 100 серверов.
Раз не работает - то и претензии предъявить некому: покупай 100 серверов 1С.
Файловая база 1С8 - это вообще концепт-СУБД от 1С (так и оставшийся демо), и не предназначен для рабочей базы. Если какие проблемы в файловой - ставьте 1С сервер. Это\т вопрос решен раз и навсегда, и закрыт для обсуждения с 1С.

+ 122
т.е. файловая - это реально "СУБД от 1С", в отличие от "клиент-серверного" недоразумения.

(122)Это не концепт, а нормальный рабочий вариант, прекрасно и стабильно работающий.
Просто надо понимать что файловый вариант не предназначен для многопользовательской работы.

Откуда ты этот бред про концепт вычитал? Когда и какому клиенту сидящему на базовой и имеющему одного пользователя 1с рекомендовала переходить на скуль?

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

(124)"и имеющему одного пользователя 1с рекомендовала переходить на скуль?"
это и есть демо-режим, если ты не знал. Раньше он даже на сервере был бесплатный.

(126)Ага, вот человек пришел в магазин, купил базовую версию 1с, и работает спокойно.
Т.е он отдал деньги за демо версию? Чисто поробовать?

(0) что то ты автор звездишь. У меня сейчас крутиться 25 баз 1 управленка УТ, остальные пополам ЗУП и БП, понятно что не все они активно используются, но всякие там фоновые задания в ЗУП и БП регулярно что то исполняют, ну у управленка само собой активно. Все это вертится (MS SQL и 1С сервер) на древнем E7320 xenon и 11 Гб озу

(128)Ну почему обязательно звездит?
Давай я тебе настрою так, что у тебя и две базы с трудом будут работать на скуле. Не веришь? :)

(127) если ты не знал - то да. Хочешь "быстро" - покупай сервер.

(130)Где там на коробке или в документации написано что это демо версия, и с ней нельзя работать с реальными данными?
Почему 1с в рекламе продвигает базовую версию как рабочую, а не как демо?
Короче ссылку на официальное заявление 1с, что все базовые однопользовательские версии являются демонстрационными и не предназначены для работы.

Вот описание базовой версии - http://v8.1c.ru/buhv8/324.htm
Где сказано что это демо? Там наоборот сказано что она предназначена для ведения учета.
Или 1с намеренно обманывает покупателей подсовывая демо версию в качестве рабочей?

(0)что-то настроено не так
работал в нескольких организациях где на серваке крутилось овер 50 баз

(131)"Где там на коробке или в документации написано что это демо версия, и с ней нельзя работать с реальными данными?"
потому и не написано, что как столкнешься с ограничениями - беги, снова плати.

(132)"Или 1с намеренно обманывает покупателей "
мне даже писать не надо, сами сказали :)

(133) когда 100 баз "крутится" - она работает так, как в (0)
А когда лежат "мертвым грузом" - то это не "крутятся".

Количество баз как бы непонятно что должно продемонстрировать. Вот у меня сейчас 127 ИБ подключены к серверу, но сеансов при этом всего 82. А на прошлом месте работы баз было около 30, зато одновременно работающих пользователей, случалось, превышало полторы сотни. Ну и где нагрузка на железо больше?

(134)И какие же там ограничения, кроме явно указанных? Я вот как то не сталкивался, не довелось.

(137)"Ну и где нагрузка на железо больше?"
во втором случае. Весь смысл - что сотня баз, более сотни процессов, все висит.

(138) негарантированность работы по сети нескольких пользователей достаточно? Остальные ограничения поискать лень?

(140)Это разве недостаток для однопользовательской версии?

(110) Еще раз, снапшоты гарантированно без риска потери информации и во время активной работы пользователей. В файловой это сделать как? А SQL это позволяет делать штатно. А если еще есть задача сделать PITR?
Спор ни о чем, ИМХО.

(141) ну да, 4 Гб тоже "не недостаток"...

(142)"А если еще есть задача сделать PITR?"
что сделать? "ПИДР" - опустить кого-то?

(144) Матчасть учить надо. Point-in-time recovery

ну до сокращение восстановления на момент до "питр" вижу первый раз. Оно как-бы не требует сокращения )

(146) http://www.postgresql.org/docs/9.3/static/continuous-archiving.html

(147) а, ну понятно, откуда эти "ПИТРы" пошли :)

(148) не только http://www.oracle-base.com/articles/12c/rman-table-point-in-time-recovery-12cr1.php

Леша, это общепринятое в буржуйском мире сокращение, пользуются все, и т.к. книжки и мануалы в основном сугубо на английском, и профильные форумы тоже, вот оттуда оно и пошло. Это не исключительно относящееся к Postgre.

(142)А кто запретил снапшоты в файловой? И восстановление на время снапшота?
За день четыре снапшота делается, через каждые три часа.
Прозрачно для пользователей, по нагрузке незаметно вообще, ибо базы на SSD, а теневое копирование идет на другой том.
В любом момент можно либо подключить папку со снапшотом и читать ее, либо восстановить.

(149) ну нет в MS SQL никаких ПИТРОВ ))
http://msdn.microsoft.com/ru-ru/library/ms190982(v=sql.105).aspx
В Postgre - есть.
(150)"это общепринятое в буржуйском мире сокращение"
ничего подобного. Это сокращение - сугубо "выделиться среди равных", т.к. совершенно бессмывсленно :)
http://msdn.microsoft.com/en-us/library/ms179451.aspx

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

(150)"и т.к. книжки и мануалы в основном сугубо на английском, и профильные форумы тоже"
я ж не виноват, что Майкрософт на русском все пишет... притом правильно ))

(51) что мешает разделителем сделать не организацию а другой справочник ?

(153)"скуль в курсе транзакций, а файловая система нет."
да ну? в файловой запрещены транзакции?

(151) При этом точно не может произойти никаких накладок? Это штатная процедура, рекомендованная разработчиком?

(153)"скуль в курсе"
вы транзакции в 1С и в SQL различаете вообще?

(155)И как такой разделитель поможет оперативно отдать базу клиенту удалив у себя?

(156)Файловая система работает с файлами, БД для нее файл.
Про то что с этим файлом работает какая-то другая БД и совершает какие то транзакции она вообще не в курсе.

(153)"Поэтому теоретически при неудачном стечении обстоятельств можно получить битую базу."
именно из-за того, что вы не понимаете, где какие транзакции, вы на SQL имеете более высокий шанс получить битую базу "при неудачном стечении обстоятельств" ))

(160)"Про то что с этим файлом работает какая-то другая БД"
как раз в курсе. Только 1С не сделала никаких нормальных инструментов администрирования базы - почему? Правильно: это ДЕМО СУБД от 1С!

(158)В скуль версии 1с на диск ничего не пишет, поэтому на чисто 1сные транзакции пофиг.
Пишет скуль, и он за своими транзакциями следит, и может корректно откатить.

(163)"В скуль версии 1с на диск ничего не пишет"
кто вам это сказал? ))
вы про логи, ТЖ и прочее знаете?

(162)Объясни каким образом файловая система знает о БД работающей с файлом?

По поводу файловой версии от 1с - если вы не умеете ее готовить, это не значит что она плоха.
Для справки - большинство пользователей 1с работают с файловой.

(163)"и он за своими транзакциями следит, и может корректно откатить."
ничего подобного.
Так нет никакой обратной связи - SQL, может, и откатывает чего-то там, что он считает транзакцией, но 1С обю этом не знает, а априори считате, что "раз в SQL брошено - все прошло ОК, и нефиг думать".

(165)" большинство пользователей 1с работают с файловой."
если только у вас ))

(164)Хорошо, тогда на скуль версии вырубите скуль сервер, и посмотрите как сервер 1с запишет базу на диск.
Если все корректно получится, я бутылку коньяка поставлю.

(152) у Оракл и DB2 тоже. У мелкомягких все по-своему. Не в том даже дело. Просто как ни называй - как сделать откат на произвольную точку во времени средствами файловой?

(165)"Объясни каким образом файловая система знает о БД работающей с файлом?"
точно таким же, каким об этом знают все СУБД.

(169)"Просто как ни называй - как сделать откат на произвольную точку во времени средствами файловой?"
копии файловой на каждую секунду? )

(167)С скулем работают только более менее крупные организации.
Организации с числом сотрудников порядка 20человек, и одним бухгалтером в штате работают с файловой.
А таких компаний значительно больше.

(171)Этого там нет, но как правило и не требуется, если вам это нужно, переходите на скуль.

(168)"тогда на скуль версии вырубите скуль сервер"
ну я уже понял, что вы не в курсе ))
Хотя б даже того, что 1С СНАЧАЛА проверяет наличие SQL сервера, а потмо устанавливает связь и делает запрос/запись.

(168) понятно, в какой момент бьются SQL-базы 1С? ))
подсказка: все в 174

(170)Ты хочешь сказать что файловая система NTFS знает что с файлом 1Cv8.1CD работает база данных такого то производителя?
Бред.
Файловой системе совершенно пофиг кто работает с файлом.
И она никак не может определить БД туда что-то пишет, или это пользователь блокнотом открыл и редактирует.

(174)Ну я вообще то утверждал, что в скуль версии вся запись на диск идет исключетельно средствами скуля.
Поэтому невозможно ничего записать средствами сервера.

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

(167) Кстати, он прав - к нам приходит юная леди от франча и приносит диски ИТС, так она говорит, что на ее участке только у двух контор SQL, у остальных одна-две файловых, которые эта девушка и обновляет. Так что если по кол-ву - файловых, наверное, больше.
(171) Вот-вот. Именно об этом я и говорю.

(178)Когда у тебя десятки и сотни пользователей в базе, такая возможность бывает очень нужна.

Но вот если у тебя один пользователь в базе, в какой такой ситуации у тебя может появится необходимость откатить базу на конкретное время с точностью до секунды?
Я такой ситуации не представляю.
Достаточно раз в три часа, да и то редко используется.

(179) Пост 109, последняя строчка :-)

Похоже, тема скатывается к вопросу "SQL или файловая?" Думаю, http://www.gilev.ru/mssqlvsfile/ самый нормальный ответ

(125) список того по чем 1С несёт ответственность?
Что типа если у меня рухнула база на скуле, то виновата 1С, а если база была файловая, то 1С не виновата?

(128) у меня было такое, поставил чисто посмотреть УТ11.0 на сервере, и даже не заходил туда, лежало без надобности, но (!) она начала активна рожать фоновые задачи и загнала в ступор сервер предприятия. Пришлось срочно удалять её.

Так что всякое в жизни бывает

(180)Ну дело в том что на этом диске не только базы лежат, там есть еще кой какие ответственные документы.
А поскольку доступ бывает по сети - корзина не работает.
Бухгалтерша зашла, и по неосторожности снесла базу, или папку с отчетами и все паника, в корзине нет ничего.
А так - зашли на сервер и выдернули вытащили все что надо.

Т.е теневое копирование при сетевом доступе удобно еще и в качестве заменителя корзины.

(181)Ну это давно всем известно.
Просто люди начинают кидаться в крайности.
Кто-то сидит с десятком пользователей на файловой
Кто то ради одного юзера ставит скуль.
ИМХО под задачи надо подбирать решение.

(186) Кто бы спорил.