1с виртуальная машина sql настройки

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

Из полученных результатов самый главный вывод не цифры, а то что по прежнему требуется опыт чтобы нащупать на практике, а не теоретически оптимальный вариант эксплуатации 1С под вашу конкретную нагрузку.
Влияние слоя виртуализации особенно заметно на очень быстрых операция информационной базы 1С и это логично. Чем меньше время операции, тем больше оно сопоставимо с временем задержки на обслуживание слоя виртуализации.
Другими словами если мы выполняем одну длительную операцию тысячу секунд, то лаг в одну десятую на обслуживание виртуализации будет каплей в море и не заметен. А вот если мы выполняем десять тысяч операций с временем каждой операции одна десятая секунды, то задержки на обслуживание будут заметны так как будут соизмеримы с длительностью операции.

2. Использовать только физические диски под данные, а не виртуальные.

4. Передача по сети между двумя виртуальными машинами на одной физической машине медленней протокола Shared Memory

5. Функции динамического перераспределения ресурсов между несколькими виртуальными машинами увеличивают возможности по ресурсам, но само перераспределение также вносит замедление. Для 1С рекомендуется выключать такие функции. Если стоит динамическое распределение ресурсов, также может «слететь» программная лицензия 1С.

7. На хостовой машине исключите из проверки антивирусом каталоги виртуальных машин

Параметры Microsoft Hyper-V и VMware ESXi & vSphere

VMware ESXi & vSphere

Коллективное использование виртуалок для балансировки нагрузки
Проблема заключается в работе компонента vCenter под названием DRS (Distributed Resource Scheduler), задача которого заключается в балансировке нагрузки виртуальных машин на физические серверы.При появлении больших нагрузок по процессорным мощностям или по загрузке ОЗУ, DRS мигрирует виртуальную машину на другой физический хост, наименее загруженный в данный момент; в кульминации данного процесса возникают кратковременные проблемы с доступом к ресурсам этой VM.

ОПЕРАТИВНАЯ ПАМЯТЬ

Если же вы хотите отключить этот механизм уже прямо сейчас, то нужно сделать следующее:

В старых версиях

1. Залогиниться на ESX\ESXi или vCenter Server через vSphere Client.
2. Выбрать нужный хост и зайти на вкладку Configuration, затем перейти в Advanced Settings в секции Software.
3. Выбираем раздел Mem и в нем устанавливаем значение параметра Mem.ShareScanGHz в 0.

После патча и обновлений ESXi механизм TPS можно будет включить следующим образом (Advanced Settings в секции Software):

ПРОЦЕССОР

ДРАЙВЕРА

Первое, что необходимо сделать, после установки операционной системы гостя внутри виртуальной машины, это установить программный пакет – гостевые дополнения VMware Tools для VMware. Эти пакеты содержат специальные драйвера, которые обеспечивают более быструю работу гостевой операционной системы на аппаратных средствах виртуальных машин.

Выберите пункт Install VMware Tools в меню виртуальной машины . Следуйте инструкциям на вашем экране для завершения установки. Если вы используете гостевую ОС Windows, то вы увидете, что данный процес не отличается от установки других приложений.

Проверка VMware Tools

• Выберите хост в vClient;
• Перейдите на вкладку Virtual Machines;
• Добавьте столбец «VMware Tools Status»;
• Оцените статус. OK->значит все хорошо, ничего делать не надо. Not Running/Out of date — устраняем.

Если VMware Tools не запущены, необходимо разбираться с гостевой операционной системой. Причина может скрываться в обновлении ядра Linux либо отключенной (кем-то) службе VMware Tools в Windows.

Если VMware Tools устарели, необходимо их обновить из контекстного меню vClient. Как правило, это случается после установки обновлений на хосты ESX/ESXi. После этого зачастую требуется обновить и VMware Tools.

ДИСКИ

• Independent Persistent Mode vmdk-диска — наиболее производительный, поскольку изменения вносятся сразу на диск, не журналируясь. Но такой диск не подвержен снапшотам, его нельзя откатить.
• При использовании iSCSI рекомендуется настроить jumbo frames (MTA=9000) на всех интерфейсах и сетевом оборудовании.
• MultiPathing — для большинства случаев RoundRobin — ОК. Fixed может дать большую производительность, но это после вдумчивого планирования и ручной настройки каждого хоста до каждого LUN. MRU можно поставить при active-passive конфигурации, если какие-то пути время от времени пропадают — чтобы не перескакивало туда-обратно.

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

При размещении 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

Как вы уже знаете, мы запустили новую услугу VPS сервер с предустановленной 1С. В прошлой статье вы задали много технических вопросов в комментариях, сделали несколько ценных замечаний. Оно и понятно — каждый из нас хочет иметь какие-то гарантии и расчёты на руках, чтобы принять решение об изменении IT-инфраструктуры компании. Мы прислушались к голосу Хабра и решили провести тестирование реального железа офисного хлама, который вполне возможно служит вашим сервером 1С и сравнить их с виртуальными серверами.

Для этого мы взяли несколько наших офисных компьютеров и виртуальных машин, созданных в разных дата-центрах и провели тестирование с помощью «Теста Гилёва».

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

В тестировании участвовали следующие машины:

VM1 – 2 ядра по 3,4ггц, 4 Гб ОЗУ и 20 Гб SSD.
VM2 – 2 ядра по 2.6ггц, 4 Гб ОЗУ и 20 Гб SSD
PC1 – I5-3450, Asus B75M-A с HDD ST100DM003-1CH162
PC2 – I3-7600, H270M-Pro4, с SSD Toshiba TR150
PC3 – i3-8100, Asrock Z370 Pro4, с SSD Intel SSDSC2KW240H6
PC4 – i3-6100, Gigabyte H110M-S2H R2 с SSD Patriot Spark на 512 Гб
PC5 – i3-100, Gigabyte H110M-S2H R2 с HDD Hitachi HDS721010CLA332

Надеемся статья будет полезна при выборе конфигурации железа для работы с 1С. Далее представляем результаты тестов.

Итоги теста в баллах

Первое место занял виртуальный сервер с новеньким GOLD 6128 @ 3.4 GHz — 75.76 баллов
Второе место за i5-7600 – 67.57 баллов. Третье и четвертое место за i3-8100 и Gold 6132 @ 2.6GHz по 64 и 60 баллов соответственно.

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

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

PC1 с I5-3450 на борту — ценнейший раритет, поэтому мы считаем его бесценным и не будем брать во внимание стоимость его эксплуатации. (Мы не нашли в продаже эту же модель диска.)
Цены на железо установленное в эти ящики взяты из яндекс маркета, без учета стоимости кулеров, корпусов и блоков питания. Всегда находилась конкретная модель плашки оперативной памяти, материнской платы, установленный в каждый из компьютеров и из этого всего выбиралось самое дешевое предложение.

Итоговая таблица в баллах и стоимости

Выводы

Размещение 1С на VDS стало достаточно выгодной опцией, если сравнивать его с приведенным железом.

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

Последние несколько лет стала очень широко использоваться виртуализация, администраторы очень быстро увидели плюсы для себя: очень удобно работать с такой машиной, легко переносить её между несколькими физическими серверами, можно настроить отказоустойчивую схему, когда одну виртуальную машину могут обслуживать более одного физического сервера. Кроме того, виртуалка перезагружается на порядок быстрее. Кто не знает, приличный физический сервер может спокойно перезагружаться по 10-15 минут: пока всё потушит, пока сразу после старта неспешно всё у себя проверит, затем даст возможность контроллерам дисковых накопителей потестировать себя и диски всласть, и только после этого начинает грузить операционную систему. Виртуальный же сервер все проверки проскакивает за секунды, с точки зрения железа это всего лишь обычная программа. А для руководства компании мощнейший плюс виртуализации состоит ещё и в том, что можно взять например десять устаревших серверов, и запихнуть их функции на один физический, получается серьёзная экономия что на модернизации оборудования как такового, что на площади серверной комнаты, что на электричестве, нужном для работы и охлаждения сервера. Или можно арендовать в дата-центре вместо десяти слабеньких серверов один сильненький за меньшие суммарно деньги. К тому же, если например раньше вам потребовалось бы увеличить в два раза мощность двух из этих десяти серверов, это могло повлечь за собой необходимость апгрейда этих серверов. А в виртуальной системе достаточно изменить настройки выделения ресурсов. Ну и если вдруг мощности конкретного хост-сервера перестало хватать, можно вынести отдельные виртуалки на другой сервер, причём в некоторых случаях можно их даже не выключать.

Ну то есть замечательная технология. А есть ли у неё минусы? К сожалению, есть.

Во-вторых, свои штрафы накладывает эмуляция сетевых интерфейсов и эмуляция сетевых дисков, которые тоже отнимают каждая свои процентики.

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

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

А кроме того, есть ещё и неудобные для 1С сочетания факторов, вот как на снимке: использование сетевого интерфейса WMXNET3 практически гарантирует узкое место на передаче данных 1С по сети.

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

Мы же выделим один наиболее значимый. Теперь кроме всех прочих факторов, добавляется ещё один, совершенно непредсказуемый для виртуальной машины: на этом же железе может исполняться неизвестное количество других виртуальных машин, нагрузка которых может колебаться от условного 0 до 100%. Благодаря этому можно наблюдать например такую картину: сидит один пользователь в базе, на сервере 1С кроме него никого нет, и запускает один и тот же несложный отчёт, например взаиморасчёты по отдельным контрагентам с расшифровкой по документам. Объём данных примерно одинаковый, и время формирования должно быть примерно одинаковым, но нет! То отчёт формируется за секунду, а то приходится ждать целую минуту. Почему? А потому что на этом же физическом сервере в это время например другой бухгалтер в другой базе на другом сервере запустил закрытие месяца, и сервер страшно занят. Изнутри виртуальной машины вот это внешнее влияние отследить совершенно никак невозможно, только с тоской наблюдать, как скачут замеры времени ключевых операций.

Что делать в данном случае? Обеспечить гарантированно высокую производительность системы можно только в том случае, когда ей никто не может помешать. То есть ответ простой: если высокая производительность какой-то конкретной базы 1С является ключевым показателем работы сервера, то всех остальных пассажиров приходится подвинуть. Либо на конкретном примере с объективными замерами показываем админам, что разница в производительности слишком велика, чтобы её игнорировать, и дальше конкретно эта база 1С обслуживается физическим сервером без виртуализации, либо разгружаем виртуальный сервер от всех сторонних виртуальных машин, и эта база 1С обслуживается виртуальным сервером, но её производительность в любом случае становится стабильной.

В книжке 1С эксперта на 22й странице методика считает, что наиболее значимый вклад составляют плохая работа запроса и плохая работа кода. При этом способность среды выполнять действия с необходимой скоростью не рассматривается. Считается, что во-первых скорость среды неизменна, хотя в виртуальной среде это может быть совсем не так. Кроме того, схожая по внешним признакам среда на практике может кардинально отличаться способностью выполнять такой же объём работ за единицу времени. На сервер может быть возложена куча других задач («резиновый сервер»: купили дорогой, надо использовать ) Обычно, когда проводят нагрузочное тестирование – его всегда проводят с имитацией деятельности в базе, но в реальной жизни надо учитывать и имитировать любую другую стороннюю нагрузку (веб-сервер, терминальный сервер, другая ERP), которые могут отнимать непредсказуемую часть ресурсов сервера. В учебнике приводится упрощённый вариант, которого в жизни обычно не бывает. Написанное в учебнике правильно, но этого явно недостаточно для того, чтобы решать задачу по-настоящему. Умение разложить состав нагрузки по составляющим источникам позволяет существенно сократить объём денег и усилий, необходимых для решения проблем.

Кроме того, многие компании, обеспечивающие работу в ЦОД, зачастую не могут сказать – где находится физически виртуальная машина. Таким образом, эксплуатируемое приложение в виртуальной среде, не привязанное к физическому оборудованию, при частой миграции виртуальной среды между узлами, может кардинально менять скорость исполнения в виртуальной среде. Также вы можете встретиться с ситуацией, когда несколько айти-специалистов берут из одного источника один и тот же образ виртуальной машины, запускают на своих компьютерах с максимально похожими характеристиками, и получают совершенно разные результаты тестов производительности. Более того, даже запуская на одном компьютере несколько копий одного образа, неожиданно выясняется необходимость понимания механизма привязки виртуальных ядер к физическим ядрам процессора. Например, когда на четырёхсокетной машине виртуальная система выбирает ядра разных процессоров, скорость отличается от той же самой виртуалки, ядра которой привязаны к одному физическому процессору.

В качестве ещё одного примера: у нас в своё время был неприятный опыт отладки запроса на базе 1С, размещённой в облаке Амазон. Сервер 1С был развёрнут на одной амазоновской виртуалке, сервер СУБД на другой. Сидим на тестовом сервере в одном сеансе, никого больше нет. Запускаем один и тот же довольно несложный запрос и замечаю, что время его выполнения может отличаться на порядок. То есть к примеру он может выполниться за 3 секунды, в следующий раз за 25, потом за 10. Внутри тестовых серверов не происходит ничего, что могло бы объяснить такую разницу. Всё зависит от того, сколько и каких виртуалок ещё развёрнуто на тех же физических серверах, какую они генерируют загрузку процессоров, памяти, дисков и сети.

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

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

Читайте также:

  
• Как посмотреть rtmp в браузере
  
• В ворде слова разрываются и переносятся на другую строку
  
• Epson xp330 программа для сканирования
  
• Что делать после установки драйвера
  
• Что такое lastpass для яндекс браузера