Веб-сервисы

Установка 1с сервер и ms sql

Тему установки MS SQL Server обычно обходят стороной. Действительно, трудно не установить эту СУБД, даже делая это в первый раз, столь же трудно не запустить в связке с ней Сервер 1С:Предприятия. Однако есть ряд неочевидных тонкостей, которые способны существенно отравить жизнь администратору, о чем мы сегодня и расскажем.

MS SQL Server занимает первое место по количеству внедрений в связке с 1С:Предприятием, во многом это объясняется низким порогом вхождения, осилить данную связку вполне способен человек без опыта, сугубо по методу Next - Next - Finish. И, что самое интересное, все это будет работать. Скажем больше, в подавляющем большинстве случаев настройки SQL-сервера по умолчанию более чем достаточно для обеспечения производительной работы сервера 1С:Предприятия и трогать их не только не нужно, но даже вредно.

Прежде всего следует вспомнить про системную базу tempdb , которая активно используется 1С для хранения временных таблиц и промежуточных результатов. Причем она используется сразу всеми базами 1С, работающими на сервере. А так как по умолчанию она располагается в папке установки SQL-сервера, т.е. на системном диске, то при увеличении нагрузки именно tempdb становится бутылочным горлышком для всего сервера. Очень часто это приводит к ситуациям: купили быстрые HDD / SSD, дисковых ресурсов хватает, а 1С тормозит, что способно вызвать у начинающих администраторов серьезные затруднения.

Второй момент. Кодировка сравнения tempdb должна совпадать с кодировкой сравнения информационных баз, иначе это может в ряде случаев привести к неожиданным результатам, вплоть до серьезных ошибок в расчетах.

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

Установка MS SQL Server для работы с 1С:Предприятие

Как мы уже говорили, установка SQL-сервера предельно проста, и мы не будем описывать этот процесс подробно, обратив внимание лишь на необходимые настройки. Начнем с выбора компонентов, так как 1С не использует большинство механизмов SQL-сервера и если вы не собираетесь их использовать для иных целей, то оставляем только Database Engine , Средства связи клиентских средств и Средства управления (опционально).

Средства управления можно не устанавливать на сервер, а установить отдельно на рабочее место администратора и управлять оттуда всеми доступными серверами MS SQL.

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

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

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

Остальные настройки можно оставить по умолчанию и завершить установку.

Настройка MS SQL Server для работы с 1С:Предприятие

Если вы имеете дело с уже установленным экземпляром SQL-сервера, убедитесь, что кодировка сравнения Cyrillic_General_CI_AS , в противном случае данные следует выгрузить средствами 1С, а сервер переустановить (или установить еще один экземпляр, если данный используется другими службами).

Для этого откройте Managment Studio , выберите необходимый экземпляр SQL-сервера и щелкнув на нем правой кнопкой мыши перейдите к Свойствам .

Затем перейдите к закладке Память и укажите доступный SQL-серверу объем ОЗУ, в противном случае SQL-сервер будет стремиться утилизировать всю доступную память . В ситуации совмещения ролей SQL-сервера с другими ролями, а в небольших и средних внедрениях он, как правило, расположен на одной машине с сервером 1С, следует из общего количества памяти вычесть необходимое системе и серверу 1С, отдав SQL то, что останется.

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

Следующая настройка будет связана с безопасностью. Для подключения 1С к серверу чаще всего используется учетная запись sa , что, мягко говоря, небезопасно, так как дает вошедшему под ней полный доступ к SQL-серверу. Учитывая, что администрированием баз 1С часто занимаются сторониие специалисты, то имеет смысл создать для них отдельную учетную запись.

Для этого раскройте Безопасность - Имена входа и создайте новое имя (учетную запись), укажите проверку подлинности SQL-сервер и задайте пароль.

Затем перейдите на закладку Роли сервера и разрешите dbcreator , processadmin и public .

После чего используйте для подключения к SQL-серверу из 1С именно эту учетную запись.

Еще одна настройка относится к уже созданным базам данных, откройте свойства нужной БД и прейдите на закладку Файлы . Найдите опцию Автоувеличение/максимальный размер для файла данных. По умолчанию там стоит 1 Мб, что весьма неоптимально, при активной работе с базой СУБД только и будет заниматься тем, что увеличивать размер файла, кроме того при активной работе нескольких баз это будет приводить к значительной фрагментации файла данных. Поэтому исходя из размера базы и активности работы задайте более высокое значение, которое не будет приводить к постоянному увеличению файла БД.

Перенос базы tempdb

В заключение нашей статьи снова обратимся к базе tempdb , часто встречаются ситуации, когда файл этой БД требуется перенести в другое место. Например сервер был установлен с параметрами по умолчанию и tempdb находится на системном разделе, или вы приобрели SSD и хотите пренести туда не только базы, но и tempdb (что является правильным решением). Также при большой нагрузке на tempdb его рекомендуется выносить на отдельный диск.

Для того, чтобы изменить место расположения файла tempdb откройте Managment Studio , выберите Создать запрос и в открывшемся окне введите следующий текст, где E:\NEW_FOLDER - новое расположение для базы:

Use master
alter database tempdb
modify file(
name = tempdev,
filename = N"E:\NEW_FOLDER\tempdb.mdf")
go

alter database tempdb
modify file(
name = templog,
filename = N"E:\NEW_FOLDER\templog.ldf")
go

Затем нажмите Выполнить , после выполнения запроса перезапустите SQL-сервер, файлы базы и лога tempdb будут создан в новом месте, файлы по старому расположению следует удалить вручную.

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

Преимущества использования 1С:Предприятие на основе Microsoft SQL Server

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

Вы можете использовать в разговоре с техническими специалистами следующие аргументы в пользу SQL Server:

  • Более высокая производительность за счет использования индексирования и секционирования таблиц в СУБД
  • Автоматическое задействование аппаратных ресурсов по мере роста нагрузки, параллельное выполнение запросов
  • Рациональное использование дискового пространства за счет возможности сжатия данных в базе SQL Server до 50% от исходного объема - реже требуется приобретение новых носителей по мере роста объемов хранимых данных
  • Более высокая степень надежности за счет технологий обеспечения отказоустойчивости и резервного копирования данных в SQL Server.

Дополнительная информация:

SQL Server продолжает развиваться: благодаря новой информационной платформе, оптимизированной для работы в облачных средах, выбор возможностей для работы с данными становится всё шире. Теперь есть все необходимые инструменты для проведения глубокого анализа данных и использования облачных решений в индивидуальных нуждах различных компаний.

SQL Server 2014 упрощает и делает более экономичной разработку высокоэффективных приложений для критически важных задач, корпоративных активов с большими данными и решений для бизнес-аналитики, благодаря чему сотрудники могут быстрее принимать обоснованные решения. Эти продукты можно развертывать как локально, так и в облаке, а также в гибридной среде. Управление ими осуществляется при помощи знакомого набора средств.

Критически важная производительность

SQL Server 2014 ускоряет работу критически важных приложений за счет новой технологии обработки в памяти OLTP, обеспечивающей повышение производительности в 10 раз в среднем и в 30 раз при обработке транзакций. Что касается хранения данных, новое обновляемое хранилище столбцов данных в памяти обрабатывает запросы в 100 раз быстрее, чем традиционные решения. Уже 5 лет подряд SQL Server подтверждает свой статус самой безопасной базы данных. (Всесторонняя база данных уязвимостей, составленная Национальным институтом стандартов и технологий 17 апреля 2013 г., доля рынка из исследования IDC за 2013 г.)

Быстрое получение результатов анализа любых данных

Получайте результаты анализа быстрее благодаря платформе бизнес-аналитики, которая ускоряет доступ, анализ, очистку и формирование внутренних и внешних данных. SQL Server 2014 и Power BI для Office 365 упрощают доступ пользователей к необходимым данным, что позволяет им быстрее принимать обоснованные решения.

Платформа для гибридного облака

SQL Server 2014 разработан для использования в гибридной среде, включающей как локальные, так и облачные ресурсы, и содержит новые средства, упрощающие создание решений для резервного копирования и аварийного восстановления с помощью Microsoft Azure. Эти средства обеспечивают быстрый перенос баз данных SQL Server в облако с локальных ресурсов, что позволяет клиентам использовать существующие навыки и преимущества глобальных центров обработки данных Microsoft.

Документация по продукту SQL Server 2014:
http://msdn.microsoft.com/ru-ru/library/dd631854(v=sql.10).aspx

Требования к оборудованию и программному обеспечению для установки SQL Server 2014.

Путем проб и ошибок, путем тестирования на 200+ живых пользователей, консультаций с десятками Гуру и поиска по сотням официальных и не очень сайтов был разработан оптимальный вариант настроек MS SQL для круглосуточной работы более, чем 200 пользователей одновременно.

1. Настройка сервера

Во-первых нам нужен только сервер, остальные службы, которые к нему относятся и возможно кто-то ими пользуется, нам только тормозят работу. Останавливаем и отключаем такие службы, как FullText Search (у 1С собственный механизм полнотекстового поиска), Integration Services и иже с ними.

Оставляем только:

SQL Server (sqlservr.exe)

SQL Server Agent (SQLAGENT.exe)

SQL Writer (sqlwriter.exe)

Максимально отведенное серверу количество памяти из расчета:

[Общее количество оперативной памяти сервера] - - Например если у нас на сервере всего 36 ГБ оперативной памяти, стоит Windows 2008 и запущено 8 процессов rphost то рассчет идет так: 36 - 4 - 1.5*8 = 20 ГБ ставим ограничение для SQL.

Это необходимо для того, чтобы sql сервер рассчитывал на этот объем и чистил память заблаговременно, т.к. если поставить неограниченный объем, и сервер попробует получить память, которой нет, он начинает крепко задумываться над своим поведением и крайне медленно отвечать на запросы.

Максимальное количество потоков (Maximum worker threads) ставим 2048, по умолчанию стоит 0 и с таким значением сервер не создает больше 255 потоков, а этого ему не хватает (установлено опытным путем, что при большом количестве одновременных транзакций сервер реально начинает быстрее работать). Также выставляем галку повышенного приоритета сервера (Boost priority ).

Собственно с глобальными настройками все. Теперь переходим к настройкам рабочей базы данных (или нескольких баз, если такое имеет место быть).

2. Настройка рабочей базы данных

Заходим в свойства нужной нам базы данных:

Если база еще не развернута из.dt файла, и вы знаете примерный ее размер, то первичному файлу размер инициализации лучше сразу указать >= размера базы, но это дело вкуса, он все равно вырастет при развертке. А вот Автоувеличение размера надо обязательно указать примерно по 200 МБ на базу и по 50 МБ на лог, т.к. значения по умолчанию - рост по 1МБ и по 10% очень сильно тормозят работу сервера, когда ему при каждой 3й транзакции надо файл увеличивать. Также, если не используетет RAID массив, то хранение файла базы и файла лога лучше указать на разных физических дисках. Ну и ограничить лог 2-4 ГБ, чтоб сильно не пух.

Остальные настройки как на скришоте:

С настройками базы все. Осталось настроить регламентные задания.

3. Настройка регламентных заданий

Сначала создаем Maintenance Plan в разделе Management:

Дефрагментацию индексов и сбор статистики нужно производить ежедневно, т.к. если фрагментированость индексов > 25%, это резко снижает производительность сервера. Дефрагментация и обновление статистики делается быстро и не требует отключения пользователей. Насколько ваши индексы фрагментированы можно посмотреть очень хорошей и многофункциональной обработкой Гилева Вячаслава, с названием Lock1C.epf, и которую он убрал со своего сайта из-за наезда 1С-ников за нарушение какого-то пункта лицензионного с., но хорошему админу гугл всегда в помощь J . Также желательно делать полную переиндексацию, с блокировкой БД, хотя бы раз в неделю, естественно после полной переиндексации сразу же делается дефрагментация индексов и обновление статистики.

Настройка бэкапа средствами SQL.

Ту все просто, добавляем 2 новых задания Agent"у:

Full BackUp, с периодичностью 1 раз в сутки и 2мя шагами T-SQL скриптов:

1. BACKUP DATABASE [< ИмяБД>] TO DISK = N"< ПутьКПапке>Backup< ИмяБД>.bak" WITH NOFORMAT, INIT, NAME = N"< ИмяБД>-Full Database Backup", SKIP, NOREWIND, NOUNLOAD, STATS = 10

2. USE [< ИмяБД> ]

DBCC SHRINKFILE (N"< ИмяБД>_log" , 0)

И второе задание с периодичностью 1 раз в 1-2 часа Differencial BackUp и с одним T-SQL скриптом:

BACKUP DATABASE [< ИмяБД>] TO DISK = N"< ПутьКПапке>Backup< ИмяБД>Diff.bak" WITH DIFFERENTIAL , NOFORMAT, INIT, NAME = N"< ИмяБД>-Differential Database Backup", SKIP, NOREWIND, NOUNLOAD, STATS = 10

Такой бэкап делается, даже при активной работе пользователей, 4-6 минут и практически не сказывается на быстродействии сервера.

Да, и добавим очистку процедурного после переиндексации (раз в неделю), в задание, кторое у же появилось в агенте после сохранения Maintenance Plan добавляем еще один шаг:

DBCC FREEPROCCACHE

Не забыв поменять в настройках первого шага после завершения не выходить, а перейти к следующему. Спс gilv за подсказку.

Вот, собственно, и все. По поводу бэкапа средствами 1С: http://infostart.ru/public/65849/ - Full BackUp и выгрузку 1С можно делать одновременно.

  • Количества данных, хранящихся в БД;
  • Отношения количества запросов на чтение к запросам на запись;
  • Наличия других процессов, использующих ресурсы.
  • На производительность сервера существенно могут настройки, управляющие , дисков, и т.п.

    Например, в целях окономии электропитания процессоры могут «занижать» частоту процессора, что приемлемо для личных компьютеров и совершенно неприемлемо для серверов с 1С.

    В BIOS сервера отключаем все настройки по экономии электропитания процессора.

    Если есть «C1E» — обязательно ОТКЛЮЧАЕМ!!

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

    В некоторых случаях (особенно для HP!) надо зайти в BIOS сервера, и ВЫКЛЮЧИТЬ там пункты, в названии которых есть EIST и C1E.
    Взамен надо там же найти пункты, связанные с процессором, в названии которых есть , включить Intel SpeedStep и ВКЛЮЧИТЬ их.
    Если в биосе есть общее указание режима энергосбережения - включить его в режим максимальной производительности (он ещё может называться «агрессивный»)

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

    Не забываем и также и про настройки схемы в операционной системе.

    В конечном итоге надо не ориентироваться на названия этих пунктов, а на итоговые максимальные частоты процессоров. Можно контролировать их утилитой CPU-Z. Приведём пример:

    вот снимок системы на базе процессора i7-4770, тактовой частотой 3.4 ГГц (о чём в явном виде написано в поле Specification: @3.40Ghz). В группе Clocks (Core #0) в пункте Multiplier (множитель) указан весь допустимый для данного процессора диапазон множителей: от 8 до 39. 8 – это состояние покоя, а 39 – это максимально возможный множитель при загрузке одного ядра. Если умножить значение множителя на написанную ниже частоту шины (Bus Speed), в данном случае 99.76 МГц, то получится текущая тактовая частота (Core Speed). В данном случае, 99.76*27 примерно равно 2693.57 МГц. Как видим, это ниже даже паспортной тактовой частоты.
    Допустим, мы проделали некоторый набор изменений, и хотим увидеть разницу. Заходим сюда же, и видим искомый максимальный множитель:

    Но не спешим радоваться, на снимке всего лишь моментально зафиксированная частота одного из ядер. А как обстоит ситуация на остальных ядрах? В новых версиях CPU-Z появилась возможность наблюдать множитель и частоту по всем имеющимся ядрам (меню Tools – Clocks)

    Заходим туда, и видим, что не на всех ядрах множитель максимальный, некоторые ядра «сачкуют»!

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

    Вот теперь уже можно со спокойной совестью запускать тест TPC и смотреть там улучшение результата.

    Сервера с архитектурой Intel Sandy Bridge умеют динамически менять частоты процессора.

    Для управления под линуксом отправляем к документации редхат .

    Убедитесь что после настройки схемы энергоснабжения процессор работает на нужной максимальной частоте, заявленной производителем. Для этого посмотрите с помощью утилиты cpu-z на core speed .

    Использование виртуальной среды означает что может быть 4 места где надо проверить влияние настроек на частоты процессора (биос физического сервер, схему электоснабжения хостовой ОС, биос виртуального сервера, схему электоснабжения виртуальной ОС).

    На серверах 1С и MS SQL Server использование антивирусов (даже сам факт инсталяции без включения) будет приводить к снижению производительности в виде периодических массовых замедлений и подвисаний интерфейса.

    Совмещение ролей сервера 1С и сервера MS SQL Server дает большую производительность, особенно если использовать протокол обмена данных напрямую через память «Shared Memory».

    Для настройки протокола воспользуйтесь статьей

    Наши «рекомендуемые практики», полученные на основе опыта выполненных проектов

    Очень многие проекты выполнены нами с помощью MS SQL Server 2008 R2.


    Материал статьи можно обсудить на форуме

    ЕСЛИ ВЫ ВЫПОЛНИЛИ ВСЕ НАСТРОЙКИ И НЕ СМОГЛИ ДОСТИЧЬ НУЖНОЙ ПРОИЗВОДИТЕЛЬНОСТИ, ТО

    2 февраля 2015 в 16:04

    Максимально эффективная по скорости работы - серверная схема, для клиент-серверной 1С 8.х

    Предисловие

    Постоянно сталкивался с высказываниями ИТ специалистов «сеть нагружена на 20%… процессоры на 50%… очередей к дискам мало… Значит сеть и сервера справляются… смотрите код в 1С проблемы исключительно там».

    На самом деле происходило следующее (сервер 1С и SQL разнесены на разные компьютеры): сеть практически использовалась по максимуму(эти "20% загрузки сетевого интерфейса " = «20% полезные данные» + «80% потеря на служебной обработке» ). И соответственно из-за малой ширины канала обмена «полезными» данными - SQL сервер с «Сервером 1С» постоянно ожидали друг друга, что вело к малой утилизации ресурсов CPU и дисковой системы.

    Ведение: Сначала хочу заострить внимание на том что же такое 1С платформа?.

    Итак начнем с главного 1С - построенная на ORM (объектно-реляционном отображении)-система и программист в ней работает не напрямую с реляционным представлением, а с объектами.
    ru.wikipedia.org/wiki/ORM

    Программист в среде 1С - пишет объектную логику, а за сборку/разборку и запись объектов в «плоский вид» по таблицам базы данных отвечает сама платформа.

    Основные "+" и "-" с точки зрения ORM:

    "+" Программист в среде ORM получает преимущество в скорости разработки приложения из-за уменьшения количества кода и его простоты по сравнению с исключительно реляционным программным кодом (пример SQL запросы). А также освобождается от написания кода работающего непосредтсвенно с записями в таблицах Реляционной СУБД.* 1

    "-" Сложности для создателей «платформ» ORM и проблемы производительности:

    Использование реляционной базы данных для хранения объектно-ориентированных данных приводит к «семантическому разрыву», заставляя программистов писать программное обеспечение, которое должно уметь как обрабатывать данные в объектно-ориентированном виде, так и уметь сохранить эти данные в реляционной форме. Эта постоянная необходимость в преобразовании между двумя разными формами данных не только сильно снижает производительность, но и создает трудности для программистов, так как обе формы данных накладывают ограничения друг на друга.

    *1«Уточнение». Несмотря на то, что 1С 8.х позволяет работать с реляционно-подобным кодом (только чтение) в объекте 1С «Запрос» - это все-таки не напрямую один-в-один транслируемый в реляционную СУБД запрос к таблицам хранения данных, а прежде всего «Объектный запрос» - также не минующий стадию сборки разборки объектов. Поэтому зачастую вместо много-тысяче строчных «Объектных запросов» - наиболее оптимально по быстродействию кода и скорости разработки - написать объектный не ряляционно-подобный код.

    Глава 1: Расмотрим модель клиент-серверной 1С 8.х

    Отмечу основные «узкие» места влияющие на производительность:

    1) Первое узкое место - это коммуникационная среда передачи данных .
    На рисунке стрелками показаны потоки обмена данными, где «красные» - это Реляционная СУБД<->Объектная СУБ, «оранжевые» - синхронизация между Объектными СУБД.
    Т.к. при использовании отдельных серверов для СУБД и кластеров 1С – коммуникационная среда это сетевые соединения – то существуют существенные задержки в передаче данных многочисленными мелкими порциями – как из-за латентности самой физической реализации интерфейсов, так и из-за латентности узлов в этой сети.

    Рассмотрим на примере сетевого стандарта Ethernet Gigabit (график зависимости скорости передачи данных… ниже )
    на примере работы Сервера 1С с MS SQL (по умолчанию размер коммуникационных пакетов 4 кб) :

    На графике видно, что при использовании пакетов ДАННЫХ =4 кб пропускная способность рассмотренной сети всего 250 Мегабит/с. (как правильно заметили в комментария к публикаци: это не пакеты протоколов например уровня TCP , а пакеты ДАННЫХ которые генерируют приложения участвующие в обмене)

    Из практики: такое разнесение на Два отдельных сервера
    MS SQL (сервер №1)< - Ethernet Gigabit ---> «Сервер 1С»(сервер №1)
    проигрывало по скорости работы платформы
    на 50%
    варианту MS SQL (сервер №1) < - Shared Memory (без сети через участок памяти) ---> «Сервер 1С»(сервер №1)… и это уже «на одном высоконагруженном пользовательском сеансе»

    2) Узкое место - это количество отдельных компьютеров «кластеров 1С» , чем их больше тем больше затраты на синхронизацию и как следствие уменьшение производительности системы.

    3) Узкое место - количество отдельных процессов сервера 1с , чем их больше тем больше затрат на их синхронизацию… Но тут скорей всего необходимо найти «золотую середину» - для обеспечения стабильности. 2*
    2* «Уточнение» - для MS Windows существует такое правило:
    Процессы дороже чем потоки, что означает применительно к данному случаю на практике следующее: скорость обмена между двумя потоками внутри одного процесса значительно превышает, скорость обмена между потоками находящихся в разных процессах.

    Поэтому например «Файловая 1С 8.х» всегда превышает по скорости однопользовательской работы платформы в клиент-серверном варианте. Все просто т.к. в случае «Файловой 1С 8.х» поток «Реляционной СУБД» общается с потоком «Объектной СУБД» внутри одного единого процесса.

    4)Узкое место – одно-поточность пользовательского сеанса , т.к. каждый отдельно взятый - пользовательский сеанс не распараллеливается платформой на несколько, то его работа ограничивается использованием ресурсов одного ядра CPU => следовательно желательна максимальная скорость каждого ядра, в этом случае быстродействие платформы 1C например на 10-ядерном CPU по 1 ггц - будет значительно уступать быстродействию платформы на 4-ех ядерном CPU по 3 Ггц – естественно до определенного количества потоков.

    Глава 2(Итог): Рассмотрим не масштабируемый и масштабируемый варианты - наиболее эффективных схем для платформы 1с 8.х. для OS Windows (пологаю для Linux ситуация аналогична)

    1-Вариант(не масштабируемый). В расчете на 100 «высоконагруженных пользовательских сеанса»

    1) эффективен обычный 2-ух сокетный сервер с 4-ех ядерными CPU по 3 Ггц.

    3) MS SQL < - Shared memory --> «Сервер 1С»

    2-Вариант(масштабируемый). начиная со 100 «высоконагруженных пользовательских сеанса» и далее ….
    Тут логичней всего пойти по пути немецкой 1с-ки «Sap HANA»))
    Собирать модульный «Супер-компьютер» от фирмы SGI – состоящий из «лезвий» на 2-х сокетных материнских платах, каждое лезвие соединяется друг с другом сложной топологией сверх-быстрого интерконнекта на основе NUMA-чипов, и все находится под управлением единой OS. Т.е. программы внутри такого сервера по определению имеют доступ к ресурсам любого «лезвия».

    1) добавляем «лезвия» по необходимой нагрузке… из расчета примерно одно «лезвие» на 100 пользователей.

    2) быстрая дисковая система на SSD

    3) MS SQL < - Shared memory --> «Сервер 1С»