vitkhvAHDPЕсть подозорение, что вы про разные типы работы сервера говорите. УПП в управляемых формах ещё не вышла.

Программист 1с Боюсь у меня действительно только управляемые.

Блин специально открыл копию продуктивной УПП в управляемом интерфейсе.
Открыл > 10 окон. Перепровел штук 20 документов. Создал и провел еще парочку. Сформировал несколько разных отчетов.
Закрыл все окна с документами и отчетами. Открыл заново штук 20 окон отчетов и документов. Перепровел еще штук 40 документов.
Присоединенные файлы не загружал и не открывал. Нет в УПП в ее куцом управляемом интерфейсе такой функции.
Использованное ОЗУ не вышло за пределы 282 Мб. При этом со 180 до 282 Мб использование ОЗУ активно росло, потом встало и стоит почти как вкопанное, что ни делай. Потребляет по 1-2 Мб на десять новых открываемых окон.

Сервер на тестовой машине 32х на 64х ОС.

Сейчас 64x сервер поставлю - посмотрю что будет.


AHDPЕдинственный минус, при росте количества процессов, увеличивается вероятность свопирования. А это может существенно снизить производительность.

Это уже интересней. Правильно я понимаю, что 8 процессов будут потреблять значительно больше памяти чем 4 процесса?
На сервере планируется SSD и RAID 0 из двух дисков. На каком из дисков будет своп еще пока не решил.

Может имеет смысл обратить внимание на дисковую подсистему, в первую очередь, ибо raid raid'у рознь :) и может быть даже подумать о безопасности, например, 4 диска в raid 10 и 1 на хотспаре? А на SSD все же лучше положить ... к примеру TempDB, это если у вас MS SQL (хотя УПП не на db engine - дело сомнительное :)) ) А памяти, если это не Терминал или web приложение и 16 хватит (да и 12)

vitkhv,

Прочитал внимательно ) для 30 пользователей УПП, покупать отдельный сервер, оплачивать лицензии ОС, более накладно нежели купить сервер на котором будет стоять и 1С и DB, но если деньги дают то почему бы и нет )
Мое мнени, при такой нагрузке лучше купить один физический сервер и для SQL и для 1C c хорошей дисковой подсистемой, а в перспективе, в будущем придать данной "пирамиде" больше креатива - отделить Сервер 1С )
Хотя не могу знать как много документов и отчетов будут делать эти 30 пользователей )

AHDP,

тоже что и тот у кого упадет "красавец" : 1 сервер SQL и 1 сервер 1С )

Резервирование сервера - это совсем другое и к делу не относится и, напрмер, если в связке умрет SQL сервер то с конфигурацией raid 0 , врядли далеко уедешь) вот если бы речь шла о резервировании серверов и закупались бы два одинаковых абсолютно сервера - тут конечно дело ясное, а так ищутся сервера под разные задачи, это мое мнени никому его не навязываю ))

AHDP,

Отказ одного сервера целиком тоже, скорее всего, будет вызван явными внешними причинам, а raid 0, как мне кажется при делах, ибо сервер который покупается: "На сервере планируется SSD и RAID 0 из двух дисков", врядли устроит, тем более если останется в живых именно 1С Сервер - с другой конфигурацией дисковой подсистемы, то не получится восстановить на него с резервных копий (я сейчас имею ввиду полное восстановление , например, с ленты, а не выгрузку базы или sql бэкап, т.к для них подразумевается на Сервере 1С держать еще и службу SQL Server что подразумевает покупку лицензии еще и на него), конечно при падении Сервера 1С можно будет поднять сервис, закинуть туда хасп (уже как то много всего )) ) и заработает все, но бытует мнение ) что Сервер 1С (я сейчас в физическом смысле употребил слово сервер, а не в астральнома ака Служба) врядли будет часто падать очень часто, а вот денег было потрачено очень много. Если других серверов нет ) то уж лучше планировать покупать кластер из двух серверов -пользы будет больше чем разнесение 1С и SQL )