1с сервер и sql сервер на разных компьютерах как лучше
Подскажите, на сколько критично, если разместить SQL и сервер 1С на одной машине, особых ограничений в ресурсах нет. Т.е. это будет виртуальная машина?
Скажется ли это на производительности 1С, при размере базы 8 Гб и 10 пользователей. Конфигурацию Бухгалтерия 2.0?
Основной затык сейчас это проведение реализаций за квартал для себестоимости, идет сутки.
у меня на одном серваке крутиться база размером 15 гб (MDF), сревер 1с и скуль, в программе работают одновременно 15 пользователей, правда оперативы там 16гб, серваку уже три года, брали примерно за 160-180 рублей еще тогда. Народ трудиться нормально, документооборот составляет около 400-500 документов в день, бухгалтерия типовая, не самолет конечно, но люди трудятся нормально, машина по железу еще 32 разрядная, если будете брать 64-х думаю проблем особых не будет, базу не допиливал на предмет прямых скуль-запросов.
проведение всех доков за месяц проходит примерно за 5-6 часов, главбух на ночь запускает и уходят утром косяки все правят, потом финальное проведение и закрытие.
Виртуальная машина, берет ресурсы с железки, поэтому удивляет "особых ограничений в ресурсах нет".
Рекомендации по выбору оборудования для работы с 1С:Предприятием 8
Для работы с 1С:Предприятием 8 рекомендуемая конфигурация компьютера, приведенная в “Руководстве по установке и запуску”, имеет следующие характеристики:
компьютер конечного пользователя:
операционную систему: Microsoft Windows 98/Me, Microsoft Windows 2000/XP/Server 2003/Vista (рекомендуется Microsoft Windows XP)
процессор Intel Pentium II 400 МГц и выше (рекомендуется Intel Pentium III 866 МГц);
оперативную память 128 Мбайт и выше (рекомендуется 256 Мбайт);
жесткий диск (при установке используется около 220 Мбайт);
устройство чтения компакт дисков;
USB-порт;
SVGA дисплей;
компьютер, используемый для разработки конфигураций:
операционную систему: Microsoft Windows 2000/XP/Server 2003/Vista (рекомендуется Microsoft Windows XP);
процессор Intel Pentium III 866 МГц и выше (рекомендуется Intel Pentium IV/Celeron 1800 МГц);
оперативную память 512 Мбайт и выше (рекомендуется 1024 Мбайт);
жесткий диск (при установке используется около 220 Мбайт);
устройство чтения компакт дисков;
USB-порт;
SVGA дисплей;
32 разрядный рабочий сервер кластера серверов:
операционные системы Microsoft Windows 2000/XP/Server 2003/Vista или один из дистрибутивов Linux (текущий состав поддерживаемых дистрибутивов Linux публикуется здесь)
процессор не ниже Pentium III 866 МГц (рекомендуется Intel Pentium IV/Xeon 2,4 ГГц). Допустимо и даже желательно использование многопроцессорных машин, так как наличие нескольких процессоров благотворно сказывается на пропускной способности кластера серверов 1С:Предприятия 8.1, особенно в случае интенсивной работы нескольких пользователей;
оперативная память не менее 512 Мбайт (рекомендуется 1024 Мбайт и выше). Хотя рабочие процессы кластера серверов 1С:Предприятия 8.1 могут исполняться в достаточно небольших объемах памяти, при пиковых нагрузках их потребности могут быть весьма значительными;
требуется наличие USB-порта для подключения ключа аппаратной защиты кластера серверов 1С:Предприятия 8.1;
устройство чтения компакт-дисков.
64 разрядный рабочий сервер кластера серверов:
операционные системы Microsoft Windows XP/Server 2003/Vista для x64 или один из дистрибутивов Linux для x86-64 (список дистрибутивов публикуется здесь)
процессор с архитектурой x86-64 (Intel с поддержкой EM64T, AMD с поддержкой AMD64). Допустимо и даже желательно использование многопроцессорных машин, так как наличие нескольких процессоров благотворно сказывается на пропускной способности кластера серверов 1С:Предприятия 8.1, особенно в случае интенсивной работы нескольких пользователей;
оперативная память 1024 Мбайт и выше. И хотя рабочие процессы кластера серверов 1С:Предприятия 8.1 могут исполняться в достаточно небольших объемах памяти, в пиковых ситуациях их потребности могут быть весьма значительными;
требуется наличие USB-порта для подключения ключа аппаратной защиты кластера серверов 1С:Предприятия 8.1;
устройство чтения компакт-дисков.
сервер баз данных:
Microsoft SQL Server 2000 + Service Pack 2 (рекомендуется Service Pack 4);
Microsoft SQL Server 2005;
PostgreSQL 8.1;
PostgreSQL 8.2;
IBM DB2 Express-C 9.1
компьютер сервера баз данных:
в качестве сервера баз данных может использоваться любой компьютер, на котором может работать Microsoft SQL Server, PostgreSQL или IBM DB2. Технические характеристики компьютера и операционная система должны соответствовать требованиям используемой версии сервера баз данных Microsoft SQL Server, PostgreSQL или IBM DB2.
Эти значения можно использовать в качестве базовых при выборе состава оборудования для решения задач автоматизации предприятий.
Разумеется, при выборе аппаратного обеспечения для конкретного внедрения, необходимо учитывать различные факторы: функциональность и сложность используемого прикладного решения (конфигурации); состав и многообразие типовых действий, выполняемых той или иной группой пользователей; количество пользователей и интенсивность их работы и т.д.
В данном документе приводится информация о том, как характеристики оборудования влияют на эффективность использования системы в различных режимах и даются рекомендации по подбору оборудования в зависимости от решаемых задач.
У меня стоит сервер 1С с SQL внутри, проблем не замечаю, всё работает стабильно и быстро. Пользователей около 25, в день до 100 документов. Перепроведение квартала до часа.
В общем случае SQL и 1С разносят на отдельное железо для большей отказоустойчивости, безопасности и возможности масштабирования при многократном увеличении числа пользователей, и вообще это более правильно со всех точек зрения, но и более затратно.
Знакомый спец не советовал устанавливать 1С на виртуальную машину, как и SQL базу данных. Виртуализация признана увеличить отказоустойчивость и надёжность систем, упростить работу админам и прочему обслуживающему персоналу, а так же уменьшить возможный простой дорогостоящего железа. Виртуализация не помогает в скорости, более того немного (а по некоторым тестам много) замедляет общую производительность системы.
Постоянно сталкивался с высказываниями ИТ специалистов «сеть нагружена на 20%… процессоры на 50%… очередей к дискам мало… Значит сеть и сервера справляются… смотрите код в 1С проблемы исключительно там».
На самом деле происходило следующее ( сервер 1С и SQL разнесены на разные компьютеры): сеть практически использовалась по максимуму(эти "20% загрузки сетевого интерфейса" = «20% полезные данные» + «80% потеря на служебной обработке»). И соответственно из-за малой ширины канала обмена «полезными» данными — SQL сервер с «Сервером 1С» постоянно ожидали друг друга, что вело к малой утилизации ресурсов CPU и дисковой системы.
Ведение: Сначала хочу заострить внимание на том что же такое 1С платформа?.
Программист в среде 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 Ггц.
2) быстрая дисковая система на SSD
2-Вариант(масштабируемый). начиная со 100 «высоконагруженных пользовательских сеанса» и далее….
Тут логичней всего пойти по пути немецкой 1с-ки «Sap HANA»))
Собирать модульный «Супер-компьютер» от фирмы SGI – состоящий из «лезвий» на 2-х сокетных материнских платах, каждое лезвие соединяется друг с другом сложной топологией сверх-быстрого интерконнекта на основе NUMA-чипов, и все находится под управлением единой OS. Т.е. программы внутри такого сервера по определению имеют доступ к ресурсам любого «лезвия».
1) добавляем «лезвия» по необходимой нагрузке… из расчета примерно одно «лезвие» на 100 пользователей.
При размещении 1С в облачной инфраструктуре и среде виртуализации наиболее важными и непростыми задачами являются повышение скорости работы платформы «1С» и настройка СУБД. Для достижения максимальной производительности инфраструктуры 1С рекомендуется правильно выбирать архитектуру инфраструктуры, режимы работы, проверить и выполнить ряд важных настроек.
В зависимости от количества пользователей, размера баз данных и ограничений бюджета (с учетом стоимости дополнительных лицензий на сервер «1С:Предприятие 8» и лицензий на СУБД) платформа «1С» может работать в файловом и клиент-серверном вариантах (на основе трехуровневой архитектуры «клиент-сервер» (рис. 1): клиентское приложение, кластер серверов «1С:Предприятия 8», СУБД).
Рис. 1
Как правильно выбрать вариант/режим работы 1С: файловый или SQL?
Обычно для 1-10 пользователей выбирается файловый режим
От 10 и более пользователей выбирается режим работы с использованием SQL
В файловом варианте все пользователи могут работать на одной виртуальной машине в облаке, например на терминальном сервере.
Для клиент-серверного варианта лучше выбрать не менее двух виртуальных машин:
Сервер с клиентским приложением, например терминальный сервер с клиентской частью «1С» (толстый клиент)
Сервер «1С» и СУБД (MS SQL или PostgreSQL)
Как рассчитать мощности сервера для 1С в файловом режиме работы?
В обоих вариантах: файловом и SQL, для работы с пользовательским приложением 1С в классическом режиме, например, «удаленного рабочего стола» (так называемый «толстый клиент»), необходимы следующие минимальные ресурсы виртуального сервера:
Количество виртуальных ядер CPU = 1 или 2 для ОС + 0,25 * количество пользователей
Объем памяти RAM = 1 или 2 ГБ для ОС + 0,5 ГБ * количество пользователей
Размер диска/хранилища HDD = 20-40 ГБ для ОС и приложений + (0,1-10) ГБ * количество пользователей. Для ОС и 1С рекомендуется использовать самые быстрые диски
Как рассчитать мощности сервера для 1С в варианте работы с SQL?
В клиент-серверном варианте работы 1С, в котором используется СУБД SQL, рекомендуется разместить 1С Сервер и сервер SQL на отдельном виртуальном сервере в общей с клиентским сервером локальной подсети. Необходимы следующие минимальные мощности для этого виртуального сервера:
Размер диска/хранилища HDD = 20-40 ГБ для ОС и приложений + (10-1000) ГБ в зависимости от объема и количества баз данных. Для ОС и СУБД рекомендуется использовать самые быстрые диски
------------
ОС - операционная система, например, Windows Server
Здесь Сервер 1С - ПО "сервер "1С:Предприятия 8"
Наиболее важными и непростыми задачами являются повышение продуктивности использования платформы «1С» в облаке и настройка СУБД. Типичные проблемы при развертывании и эксплуатации облачной инфраструктуры для «1С» следующие:
Неправильный выбор мощностей
Неквалифицированная настройка сервисов виртуальной инфраструктуры
Недостаточное внимание к тестированию производительности платформы «1С»
Для достижения максимальной производительности рекомендуется проверить и выполнить ряд настроек. Прежде всего необходимо исключить свопинг, для чего с помощью системы мониторинга следует обязательно удостовериться в том, что объем оперативной памяти достаточен для работы ВМ. Кроме того, файл подкачки ОС, профили пользователей, файлы баз данных, файлы логов транзакций (SQL) и tempDB (SQL) лучше разместить на дополнительных SSD-дисках, а для файла подкачки установить фиксированный размер.
На SQL-сервере необходимо выключить все ненужные службы, например FullText Search и Integration Services, установить максимально возможный объем оперативной памяти, максимальное количество потоков (Maximum Worker Threads) и повышенный приоритет сервера (Boost Priority), задать ежедневную дефрагментацию индексов и обновление статистики, настроить автоматическое увеличение файла базы данных (не менее 200 Мбайт) и файла лога (не менее 50 Мбайт), а также полную реиндексацию не реже одного раза в неделю. При размещении серверов SQL и «1С:Предприятие» на одной ВМ следует включить протокол Shared Memory.
Следуя перечисленным выше рекомендациям, можно добиться увеличения быстродействия платформы «1С» в облаке в 1,5–2 раза.
Квалифицированное размещение ИТ-сервисов, в том числе «1С», на облачной платформе позволяет:
Существенно сократить расходы
Повысить уровни безопасности (доступ к данным, резервное копирование, антивирусная защита и др.) и технического обслуживания
Обеспечить централизованное администрирование и мониторинг
Организовать эффективную и безопасную удаленную работу
Воспользоваться гибкими возможностями масштабирования, лицензирования и оперативного перехода на необходимые версии конфигураций «1С»
ЧЕК-ЛИСТ ПО ОПТИМИЗАЦИИ ИНФРАСТРУКТУРЫ 1С С MS SQL
1. Включить возможность мгновенной инициализации файлов (Database instant file initialization)
Это позволяет ускорить работу таких операций как:
Создание базы данных
Добавление файлов, журналов или данных в существующую базу данных
Увеличение размера существующего файла (включая операции автоувеличения)
Восстановление базы данных или файловой группы
Для включения настройки:
На компьютере, где будет создан файл резервной копии, откройте приложение Local Security Policy (secpol.msc)
Разверните на левой панели узел Локальные политики, а затем кликните пункт Назначение прав пользователей
На правой панели дважды кликните Выполнение задач по обслуживанию томов
2. Включить параметр «Блокировка страниц в памяти» (Lock pages in memory)
Эта настройка определяет, какие учетные записи могут сохранять данные в оперативной памяти, чтобы система не отправляла страницы данных в виртуальную память на диске, что может повысить производительность.
Для включения настройки:
В меню Пуск выберите команду Выполнить. В поле Открыть введите gpedit.msc
В консоли Редактор локальных групповых политик разверните узел Конфигурация компьютера, затем узел Конфигурация Windows
Разверните узлы Настройки безопасности и Локальные политики
Выберите папку Назначение прав пользователя
Политики будут показаны на панели подробностей
На этой панели дважды кликните параметр Блокировка страниц в памяти
В диалоговом окне Параметр локальной безопасности — блокировка страниц в памяти выберите «Добавить» пользователя или группу
В диалоговом окне Выбор: пользователи, учетные записи служб или группы добавьте ту учетную запись, под которой у вас запускается служба MS SQL Server
Чтобы изменения вступили в силу, перезагрузите сервер или зайдите под тем пользователем, под которым у вас запускается MS SQL Server
3. Включить каталоги с файлами базы данных в правила исключения для антивируса.
Если антивирус будет сканировать файлы базы, это может сильно замедлить работу СУБД.
Для опытных администраторов: антивирус на сервер СУБД лучше не устанавливать.
4. Включить каталоги с файлами базы данных в список исключений для системы автоматического копирования.
Если на сервере установлена система автоматического копирования файлов, то, когда она будет копировать файлы базы, это может привести к замедлению работы. Копии базы необходимо делать средствами самой СУБД.
5. Отключить механизм DFSS для дисков.
Механизм Dynamic Fair Share Scheduling отвечает за балансировку и распределение аппаратных ресурсов между пользователями. Иногда его работа может негативно сказываться на производительности 1С.
Чтобы отключить его только для дисков, нужно:
Найти в реестре ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TSFairShare\Disk
Установить значение параметра EnableFairShare в 0
6. Отключить сжатие данных для каталогов, в которых лежат файлы базы.
При включенном сжатии ОС будет пытаться дополнительно обрабатывать файлы при модификации, что замедлит сам процесс записи, но сэкономит место.
Чтобы отключить сжатие файлов в каталоге, необходимо:
Открыть свойства каталога
На закладке Общие нажать кнопку Другие
Снять флаг «Сжимать» содержимое для экономии места на диске
7. Установить параметр «Максимальная степень параллелизма» (Max degree of parallelism) в значение 1.
Данный параметр определяет, во сколько потоков может выполняться один запрос. По умолчанию параметр равен 0, это означает, что сервер сам подбирает число потоков. Для баз с характерной для 1С нагрузкой рекомендуется поставить данный параметр в значение 1, т.к. в большинстве случаев это положительно скажется на работе запросов.
Для настройки параметра необходимо:
Запустить Management Studio и подключиться к нужному серверу
Открыть свойства сервера и выбрать закладку Дополнительно
Установить значение параметра равное единице
8. Ограничить максимальный объем памяти сервера MS SQL Server.
Необходимо ограничить максимальный объем памяти, потребляемый MS SQL Server, особенно это критично, если роли сервера 1С и сервера СУБД совмещены. Максимальный объем памяти, рекомендуемый для MS SQL Server, можно рассчитать по следующей формуле:
Память для MS SQL Server = Память всего – Память для ОС – Память для сервера 1С
Например, на сервере установлено 64 ГБ оперативной памяти, необходимо понять, сколько памяти выделить серверу СУБД, чтобы хватило серверу 1С.
Для нормальной работы ОС в большинстве случаев более чем достаточно 4 ГБ, обычно – 2-3 ГБ.
Чтобы определить, сколько памяти требуется серверу 1С, необходимо посмотреть, сколько памяти занимают процессы кластера серверов в разгар рабочего дня. Этими процессами являются ragent, rmngr и rphost, подробно данные процессы рассматриваются в разделе, который посвящен кластеру серверов. Снимать данные нужно именно в период пиковой рабочей активности, когда в базе работает максимальное количество пользователей. Получив эти данные, необходимо прибавить к ним 1 ГБ – на случай запуска в 1С «тяжелых» операций.
Чтобы установить максимальный объем памяти, используемый MS SQL Server, необходимо:
Запустить Management Studio и подключиться к нужному серверу
Открыть свойства сервера и выбрать закладку Память
Указать значение параметра Максимальный размер памяти сервера
9. Включить флаг «Поддерживать» приоритет SQL Server (Boost SQL Server priority).
Данный флаг позволяет повысить приоритет процесса MS SQL Server над другими процессами.
Имеет смысл включать флаг только в том случае, если на компьютере с сервером СУБД не установлен сервер 1С.
Для установки флага необходимо:
Запустить Management Studio и подключиться к нужному серверу
Открыть свойства сервера и выбрать закладку Процессоры
Включить флаг «Поддерживать приоритет SQL Server (Boost SQL Server priority)» и нажать Ок
10. Установить размер авто увеличения файлов базы данных.
Автоувеличение позволяет указать величину, на которую будет увеличен размер файла базы данных, когда он будет заполнен. Если поставить слишком маленький размер авторасширения, тогда файл будет слишком часто расширяться, на что будет уходить время. Рекомендуется установить значение от 512 МБ до 5 ГБ.
Для установки размера авторасширения необходимо:
Запустить Management Studio и подключиться к нужному серверу
Открыть свойства нужной базы и выбрать закладку Файлы
Напротив каждого файла в колонке Автоувеличение поставить необходимое значение
Данная настройка будет действовать только для выбранной базы. Если вы хотите, чтобы такая настройка действовала для всех баз, нужно выполнить эти же действия для служебной базы model. После этого все вновь созданные базы будет иметь те же настройки, что и база model.
11. Разнести файлы данных mdf и файлы логов ldf на разные физические диски.
В этом случае работа с файлами может идти не последовательно, а практически параллельно, что повышает скорость работы дисковых операций. Лучше всего для этих целей подходят диски SSD.
Для переноса файлов необходимо:
Запустить Management Studio и подключиться к нужному серверу
Открыть свойства нужной базы и выбрать закладку Файлы
Запомнить имена и расположение файлов
Отсоединить базу, выбрав через контекстное меню Задачи – Отсоединить
Поставить флаг Удалить соединения и нажать Ок
Открыть Проводник и переместить файл данных и файл журнала на нужные носители
В Management Studio открыть контекстное меню сервера и выбрать пункт Присоединить базу
Нажать кнопку Добавить и указать файл mdf с нового диска
В нижнем окне сведения о базе данных в строке с файлом лога нужно указать новый путь к файлу журнала транзакций и нажать Ок
12. Вынести файлы базы TempDB на отдельный диск.
Служебная база данных TempDB используется всеми базами сервера для хранения, промежуточных расчетов, временных таблиц, версий строк при использовании RCSI и многих других вещей. Обычно обращений к этой базе очень много, и если она будет лежать на медленных дисках, это может замедлить работу системы.
Рекомендуется хранить базу TempDB на отдельном диске для повышения производительности работы системы.
Для переноса базы TempDB на отдельный диск необходимо:
Запустить Management Studio и подключиться к нужному серверу
Создать окно запроса и выполнить скрипт:
ALTER DATABASE tempdb
MODIFY FILE (NAME = tempdev, FILENAME = 'Новый_Диск:\Новый_Каталог\tempdb.mdf')
ALTER DATABASE tempdb
MODIFY FILE (NAME = templog, FILENAME = 'Новый_Диск:\Новый_Каталог\templog.ldf')
Перезапустить MS SQL Server
13. Включить Shared Memory, если сервер 1С расположен на том же компьютере, что и сервер СУБД.
Протокол Shared Memory позволит общаться приложениям через оперативную память, а не через протокол TCP/IP.
Для включения Shared Memory необходимо:
Запустить диспетчер конфигурации SQL Server
Зайти в пункт SQL Native Client – Клиентские протоколы – Общая память – Включено
Поставить значение Да и нажать Ок
Протокол Именованные каналы нужно выключить аналогичным образом
14. Перезапустить службу MS SQL Server
Внимание! Когда все настройки выполнены, необходимо перезапустить службу MS SQL Server
Есть задача:
Организовать на нем работу серверной 1с. пользователей сейчас до 30, но планируют увеличивать до 100.
Что по вашему мнению выгоднее:
1) на хостовую машину Hyperv-server. на виртуальные 1с и sql ?
2) на хостовую машину MS Server 2012R2 и на нее уже сервер 1с и sql ?
Я бы разнес на вирутуальные _)) Но сейчас многие говорят что можно ставить на 1 машину и 1с и sql и все будет хорошо и быстрее на 30 и выше процентов_))
Физическая неудобна для администрирования, для быстрого восстановления после возможных сбоев.
Современные виртуальные машины класса Hyper-V, ESX и тп. - жрут жалкие проценты производительности.
Только виртуальные машины. На каждую машину - одна роль. И второй такой же сервер для фэйловера. Потерь производительности не будет.
Можно конечно как неандертальцы все на одну ставить, но потом не пишите сюда вопросы что делать, если после очередного обновления какой-либо системы у вас рухнуло ВСЕ. И вам за ночь нужно будет поднять и настроить их все.
нет к сожалению второго такого сервера _))
если б он был, можно было бы все на железе отдельном развернуть, хотя отказоустойчивость тогда 0 _))
В любом случае поставить голый гиперв на любой комп и развернуть на нем бэкапы виртуалок в разы проще восстановления системы на другом железе.
nfire, вы, видимо с энтерпрайзом не сталкивались. Развернуть виртуалку с MSSQL, которой требуется 64Гб оперативы и 100-200Гб SSD, на любой комп не всегда возможно.
Дмитрий, зачем 64 и 100-200? когда пожар и все рушится, поднять рабочую базу на наспех собранном железе, очень ценно.. денек оно поработает и не с кучей оперативки и ссд
На виртуалки - удобнее в обслуживании.
Разница с железом в производительности процентов 5%, то есть вы этого даже не заметите.
Но в случае сбоя поднять виртуалку из бэкапа (если он у вас есть) - минутное дело, всяко-разно никак не сопоставимо с многочасовой настройкой ПО на железе.
Выгодно в плане удобства администрирования.
Крайне невыгодно в плане производительности. Если для вас удобство важнее производительности, то вполне нормальный вариант.
InoMono, Какие полтора процента? В два-три раза как минимум.
Или получать данные напрямую из памяти, или гонять данные через два сетевых интерфейса, с очередями и задержками присущими сетям.
InoMono, суть в том что сервер 1С и mssql нежелательно разводить на разные машины, неважно виртуальные или физические
Какие полтора процента? В два-три раза как минимум.
Или получать данные напрямую из памяти, или гонять данные через два сетевых интерфейса, с очередями и задержками присущими сетям.
1) Вас кто-то обманул.
2) Запомни, студент, в любой задаче, где интенсивно используется СУБД при грамотной организации решения этой задачи - основная нагрузка по перевариванию данных как раз ложиться на СУБД. А уже переваренный в СУБД небольшой по объему результат уезжает по сети в приложение.
3) Локально ты будешь обращаться к СУБД через сетевые интерфейсы тоже. И да, они будет конечно виртуальными, не связанными с реальным железом. Но ненамного более простыми, чем виртуальные интерфейсы виртуальных машин.
InoMono,
отвечу за "студента"
1) никто его не обманул, человек явно работал с 1С ;)
2) вы знаете как 1С работает с СУБД? там используются только самые базовые ф-ции самой базы без переваривания силами СУБД и сокращение издержек в этом месте положительно влияет на производительность
3) локально к СУБД можно (и в данном контексте нужно!) обращаться через SharedMemory (это кстати ответ на то почему нежелательно разносить сервера)
вы знаете как 1С работает с СУБД? там используются только самые базовые ф-ции самой базы без переваривания силами СУБД и сокращение издержек в этом месте положительно влияет на производительность
Вы описываете семерку. Она почила в бозе уже 10 лет как. Хотя кое где используется.
;)
Да, это очевидно, что он работал с 1С, но:
3) локально к СУБД можно (и в данном контексте нужно!) обращаться через SharedMemory (это кстати ответ на то почему нежелательно разносить сервера)
А еще можно вообще от операционной системы отказаться. Она же часть ресурсов забирает.
Oracle в свое время сделал возможность своей СУБД работать с дисками напрямую, минуя файловую систему. И что? Думаете сразу фантастический рост производительности? Отнюдь. Серебряной пули не существует.
Что до конкретно 1С - ФИЗИЧЕСКИ разносить сервера не стоит.
Но на различные виртуальные машины в пределах одной физической машине - не наблюдается никакого страшного падения производительности.
Сеть 1С использует не столь сильно.
Исходя из того, что восьмерка должна отображать пользователям кучу инфы, когда пользователи листают экран журнала документов например - конечно она вытягивает много данных.
Впрочем, чего гадать-то на кофейной гущи. Возьмите хоть встроенный профилировщик Windows и замерьте нагрузку на сеть.
Будете очень удивлены.
Вроде бы да, 1С использует сеть интенсивно. Но при этом сетевая карта не так чтоб даже и нагружена.
Ну а виртуалка вполне годна.
Она не притормаживает работу на вот эти смешные
как написал Артем.
Какие два раза, Артем?
Даже при самом худшем сценарии - и 10 процентов не достигает.
InoMono, "Эффект Даннинга — Крюгера"
Я не буду особо вам доказывать, но сталкиваясь на разных крупных предприятиях с интеграцией 1С, ВСЕ интеграторы однозначно рекомендуют ставить по возможности сервера вместе. или они не профессионалы? не понимают бедные что сеть не тормозит? что sharedmemory глупости?
фантастического роста конечно не будет, но борьба с производительностью в крупных базах у 1С это одна из самых больных проблем тянущихся с семерки до сих пор, и до сих пор нет однозначного способа победы, по этому в бой идут все возможные способы
Ой какую дискуссию развели.
InoMono, При чем тут виртуальные машины вообще? Была дана конкретная ситуация.
Разносить на разные машины сервер 1с и скуля крайне не рекомендуется ввиду просадки производительности.
Это факт. Подтвержденный практикой эксплуатации типовых решений 1с.
Да в восьмерке если взяться и оптимизировать код, то можно свести к минимуму обмен информацией между сервером 1с и скулем.
Но кто блин это делать будет? Нанимать программеров и оптимизировать кучу типового кода, который постоянно меняется. На сопровождении разоритесь, программеры 1с очень жадные люди, и денежки любят.
Цифра не с потолка взята. Типовые базы 1с работают в режиме SharedMemory в два, три раза быстрее нежели по сети.
Поэтому разносят 1с и скуль по разным серверам в двух ситуациях -
1)Железо банально не справляется чтобы тянуть и то и другое.
2)Когда производительность не сильно важна, ресурсов гарантированно больше чем надо, и на первое место выходит удобство.
А как вы оцениваете нагруженность сетевой карты? По диспетчеру задач? Или аналогичным инструментам?
Сетевая карта может быть загружена на 1% и при этом могут быть дикие тормоза из-за того что сетевая карта не справляется.
Не думаю, что надо разносить SQL сервер и сервер 1С на разные машины - скорее всего это приведет к тормозам. Про размещение - никаких физических машин, исключительно ВМ - удобнее со всех сторон, сильного торможения точно не будет.
(1) Однозначного ответа на этот вопрос нет. Очень сильно зависит от базы данных, от количества одновременно подключенных пользователей и ещё от множества параметров.
Да Это очень удобно при миграции на более производительный сервер сервера баз данных + распределение ресурсов
Для миграции очень удобно запускать все на виртуалках. Тогда ты можеш переносить виртуальные сервера между физическими, удобно как для резервирования самого желаза, так и для быстрого апгрейда серверов. Ничего не нужно будет переустанавливать.
УПП, 100 человек, схема работы удаленная сервере, люди в разных городах.
Все параметры есть готов обсудить.
Сам реализовал, работу разделенную.
Если у Вас есть проблемы с производительностью, то нужно принимать меры, разносить ради простого разнесения конечно нет смысла.
Если проблема с производительностью то надо делать комплекс мер и начинать с наиболее простых и очевидных, по повышению производительности:
1. Сколько у вас процессов сервера 1с и какой разрядности, может кластер сделать?
2. Сложно ли перейти на 8.2 (это необходимо рано ил поздно)? Вы лишаете себя управляемых блокировок как минимум и производительности за счет самой платформы.
3. Какой SQL? Производилось ли секционирование?
4. проводилось ли нагрузочное тестирование и проверка узких мест оборудования? Вы пробовали ставить ЦУП?
Вообще 1С сейчас разрабатывает версию платформы с автоматической балансировкой нагрузки между серверами 1С.
У меня на 8.1 работало отлично, 50 пользователей. А вот когда перешли на 8.2 то тормоза жуткие стали. Если честно не могу пока сказать это из за платформы или из за того что всё на одном серваке стоит. Думаем это дело разделять, но я что то сомневаюсь что платформа 8.2 на столько тяжелей..разделение должно помочь
(7) Dima_b,
Скорее кривые запросы из 1С в базу данных.
Если конфа была написана на 8.1, по а ты ее через выгрузку завел в 8.2 то проблемы однозначно будут.
Язык запросов в 8.1 несколько отличается от 8.2
Нужен программер который оптимизирует код 1С.
Если быстродействие устраивает и не планируется заведомо повышать количество пользователей, то смысла - нет.
нет конкретики опиши все железо, бд, версию 1С. Ну а так конечно распределение даст прирост производительности и гибкость в администрировании
Смысл имеет разносить при большой нагрузке на 1С сервер (когда количество одновременно работающих пользователей велико), у меня на прошлой работе только это помогло расшевелить базу при нагрузке в 30 работающих человек. по сути 1С сервер начинает жрать процессорное время, подвигая скуль в ресурсах, а скуль кушает память.
всё завит от кол-ва пользователей, до 30 этим можно не заморачиваться. если железо производительное. больше 30 стоит разносить. сервер 1с потребляет много ресурсов
(16) olegpoz,
Если не автору, то другому человеку, пытающемуся найти ответ на данную тему, данные "догадки" помогут.
Есть. 1с так и рекомендует. Ещё неплохо добавлять несколько рабочих процессов на сервере 1с (имею ввиду Администрирование серверов 1С предприятия)
На самом деле нужно смотреть по нагрузке и по планируемой пиковой загруженности всей системы. Если следовать всем рекомендациям, то под каждую задачу необходим свой сервер, но это невсегда целесообразно и экономически обосновано
Конечно есть. SQL-сервер всегда ставил отдельно и никаких проблем не испытывал. Только сервер 1С должен быть обязательно соединен с SQL-сервером гигабитным ethernet. Кроме этого, файлы SQL-базы данных (*mdf и *ldf для MS SQL) должны быть на SAS-дисках или SSD-накопителях, установленных желательно в RAID0 для надежности.
(22) vprus, цитирую: ". должны быть на SAS-дисках или SSD-накопителях, установленных желательно в RAID0 для надежности."
Имелось в виду RAID 10? Дело в том, что RAID 0 и надежность - диаметрально противоположные понятия ;-) А то щас пионэры наставят, начитавшись :-)
А по сути - сильно улучшается производительность (скажем, хотя бы в тесте Гилева) при отдельном сервере БД?
Я, собсно, вот к чему. Надо ли огород городить, может, до некоторых масштабов, лучше поставить сервак помощнее?
Нонешние процы все же весьма производительные, а уж серверные - так вообще. Система с двумя ксеонами Е5 или Е7 по вычислительной мощности потянет и 1С, и СУБД просто играючи. Оперативки можно набить побольше, и вуаля. А скорость обмена информацией между процом, аппаратным рэйдом и оперативкой всяко же больше, чем через гигабитную локалку.
В общем, все опять сводится к извечному вопросу - где возникают наибольшие тормоза?
сопутствующий вопрос: если кластер и клиент находятся на одной машине (виндоус), что можно сделать с настройками кластера для ускорения обмена данными клиента и базы ? тормозит жутко порой при сохранении больших объемов данных в базу. хотя бы клиент-серверный вариант оставили про запас что-ли. (
Как раз произвел разделение сервера 1С и базы SQL. Не увидел большого прироста в производительности.
Сервер 1с вертится на HP Proliant DL580 G5 64Gb Raid 10. А сервер SQL вертится на HP Proliant DL580 G7 256Gb raid 10. На обоих серверах дури хватает. Процы загружены мало, дисковая подсистема тоже не сильно. Параллельно работает порядка 100-150 пользователей. по счет процов так вообще вопрос - нафига эта куча процессов с кучей ядер и HT. Все равно большинство приложений не умеет использовать их. И висит все это мертвым грузом.
При количестве пользователей от 30-40 - ДА. Согласно рекомендациям самого Microsoft (в случае использования MS SQL Server) сиквэл сервер не рекомендуется совмещать на одном физическом сервере с еще чем либо (домена контроллера или терминального сервера и т.п.). Но одного разделения конечно не достаточно. Нужно еще "разнести" лог и данные, оптимизировать сеть, выровнять разделы. В общем правильно настроить сам SQL
имеет смысл
согласно рекомендациям самого Microsoft (в случае использования MS SQL Server) сервер не рекомендуется совмещать на одном физическом сервере с еще чем либо (домена контроллера или терминального сервера и т.п.). Но одного разделения конечно не достаточно. Нужно еще "разнести" лог и данные, оптимизировать сеть, выровнять разделы. В общем правильно настроить сам SQL
Наблюдал картину когда в конфигурации Управление Торговым Предприятием для Украины.
примерно 10 пользоователей.
24 - 30 тысяч документов в месяц.
Сервер "домашний компьютер", помоему i5 проц с 8 гиг памяти.
Долго заходили в базу, проводили документы и т.д. Причём SQL при загрузке\выгрузки информационной базы загонял в потолок одно из ядер и больше не использовал.
Перенесли сервер 1С и SQL на новый сервер (серверной сборки) полегчало, но не сильно. Заметно полегчало только после разноса на разные, отдельные сервера. Причём на сервере SQL сделали упор на дисковый массив. В итоге жизнь наладилась.. Но всёравно, перепроведение документов за месяц занимает довольно большое время.
Вопрос к разработчикам "из-за чего и что делать?" был получен ответ "ну, запросы там это. не оптимальны. Если хотите - можете оптимизировать". Ну бЭлин! это же получится нифига не типовая конфа! как её потом поддерживать?
А по поводу ускорения работы: можно настроить индексирование регистров базы, и есть обработка "КонсольЗаданий" с помощью которой можно настроить регламентированные задачи 1С-сервера.
Читайте также: