1с не запускается на виртуальной машине
Обновлено: 08.07.2024
А давайте поговорим про синтетические тесты? Мы заметили, что часть клиентов использует их, оценивая «профпригодность» любого облачного решения. Иногда нас просят предоставить результаты какого-либо теста или сами проверяют систему во время бесплатного пробного периода. Причём то же нагрузочное тестирование проводят редко. В фаворитах — тест Гилева. Про него-то мы и расскажем. Ведь если и делать подобный тест, то делать его нужно правильно.
Введение
Стоит понимать, что тест Гилева никак не отражает быстродействие реальной конфигурации с реальной базой данных. Он запускается на пустой платформе без установки каких-либо конфигураций и тем более загрузки реальных баз 1С. А ведь многопоточный тест может быть запущен в качестве нагрузочного и на реальной системе с реальными данными.
Более того, тест в первую очередь разрабатывался для проверки дискретных серверов (поскольку именно их рекомендует использовать производитель платформы), а однопоточный тест изначально разрабатывался для проверки файловой архитектуры хранения баз 1С. И если по настройке дискретных серверов и операционных систем на сайте авторов имеются рекомендации, хотя и неполные и отчасти устаревшие, то по виртуальным и облачным технологиям присутствует только приглашение к заключению договора с авторами теста на проведение работ по оптимизации.
Тем не менее, многие технические специалисты считают результаты теста истиной в последней инстанции, придавая очень большое значение полученным результатам. При этом зачастую внимание обращают только на результаты однопоточного теста, как самые наглядные и простые. Это не совсем правильно, но стереотип весьма устойчив.
Данная статья описывает результаты исследования влияния различных оптимизаций виртуальной машины, её гостевой ОС и прикладного программного обеспечения на результаты прохождения теста Гилева.
Исходные данные
Тест Гилева – синтетический тест, позволяющий оценить быстродействие платформы «1С:Предприятие». В основном используется для оценки производительности при использовании СУБД для хранения баз данных 1С, но может использоваться и для файлового варианта хранения баз данных 1С. Поставляется в виде файла конфигурации (*.cf) для дальнейшей загрузки в конфигураторе «1С:Предприятие».
Тест состоит из двух частей, которые могут быть запущены независимо друг от друга.
Первая часть – однопоточный тест, оценивает производительность выполнения операций в один поток, что является характерной особенностью платформы «1С:Предприятие». По результатам теста строится график в виде столбчатой диаграммы, в котором слева направо представлены текущий результат теста и результаты, соответствующие оценкам «плохо», «удовлетворительно», «хорошо» и «отлично». «Оценочные» результаты имеют фиксированные значения (10, 15, 35 и 60 соответственно). Результат однопоточного теста предоставляется в неких условных единицах.
Вторая часть – многопоточный тест, позволяет оценить скорость записи на диски при одновременном обращении к базе данных нескольких запросов. В качестве результатов выводятся максимальные скорости записи отдельных строк, однопоточной записи, максимальной скорости записи и рекомендуемого числа пользователей. При использовании файловой архитектуры хранения баз 1С этот тест недоступен.
Дополнительно тест позволяет сохранить результаты в облако авторов теста и получать результаты других пользователей теста для сравнения.
Среда тестирования
Для тестирования в «обычном» облаке Cloud4Y мы создали виртуальную машину с гостевой ОС Windows Server 2019. ВМ развернули из стандартного шаблона в варианте с паравиртуальным драйвером дисков. Данный тип контроллера не даёт преимуществ по скорости работы в сравнении с LSI Logic SAS, но активно продвигается вендором и может стать типом контроллера по умолчанию в будущем.
В качестве СУБД использовали Microsoft SQL Server 2019 редакции Standard. Редакция Express даёт схожие результаты тестирования, однако неприменима на реальных базах из-за ограничений редакции. Следовательно, использовать её в шаблоне виртуальной машины не имеет смысла.
На виртуальной машине установили сервер «1С:Предприятие» и настроили кластер серверов 1С. Также установили дополнительные средства администрирования серверов 1С. В качестве единственной конфигурации использовался тест Гилева.
Для тестирования раздельной конфигурации, где сервер 1С и СУБД размещаются на отдельных ВМ, мы клонировали исходную ВМ, после чего в гостевой ОС каждой из получившихся виртуальных машин удалили лишние компоненты и провели дополнительную настройку.
Оптимизации
Оптимизировали виртуальную машину. На виртуальных машинах, использующихся в тестировании, отключили функции добавления на лету виртуальных процессоров и оперативной памяти, как потенциально снижающие производительность.
Оптимизировали СУБД. В частности, мы:
Установили минимально необходимый набор компонентов СУБД MSSQL
Установили лимит потребления памяти сервером СУБД: минимальное значение равное половине объёма оперативной памяти, максимальное – полный размер RAM, за вычетом 1 ГБ на каждые выделенные 16 ГБ оперативной памяти
Установили максимальную степень параллелизма равную 1
Базу tempdb, пользовательскую базу данных, лог базы данных разнесли на отдельные файловые системы на отдельных виртуальных дисках
Выполнили тонкую настройку параметров баз model и tempdb: значения начального размера базы от 1 ГБ до 10 ГБ, начальный размер журнала транзакций от 1 ГБ до 2 ГБ и авторасширение в 512 МБ
В СУБД разрешили операции по обслуживанию томов
Для раздельной архитектуры для пользователя, от имени которого запускался сервер СУБД, дополнительно установили политику «Блокировка страниц в памяти». Для совместной архитектуры эта политика не должна использоваться, что подтверждается результатами тестов
Для совместной архитектуры отключили все протоколы обмена данными, кроме shared memory, для раздельной – все, кроме tcp
Тестирование
Настройки сделаны, давайте посмотрим на то, какое влияние на результаты теста оказывают разные параметры инфраструктуры
Влияние виртуальных процессоров и сокетов
Рис.1 Рис. 2 Рис. 3На рис. 1-3 приводятся результаты исследования влияния сокетов для совмещённой конфигурации. Как можно увидеть, максимальные значения достигаются при одном сокете, при увеличении их количества результаты теста снижаются.
Рис. 4 Рис. 5
На рис. 4 и 5 показано слияние увеличения количества виртуальных процессоров. Как можно увидеть, значительного выигрыша в результатах теста Гилева увеличение количества виртуальных процессоров не даёт.
Примечание: но при работе с реальной базой данных и при подключении более одного пользователя количество виртуальных процессоров будет существенно влиять на производительность, и это нужно учитывать.
Влияние объёма RAM
Теперь давайте оценим влияние объёма оперативной памяти на результаты теста
Рис. 6
Как можно увидеть, увеличение памяти не даёт ощутимого влияния на результаты теста.
Примечание: но при работе с реальной базой данных и при подключении более одного пользователя объём оперативной памяти будет существенно влиять на производительность, и это нужно учитывать.
Влияние размера кластера файловой системы тома с базой данных
Рис. 7 Рис. 8 Рис. 9На рис. 7-9 представлено влияние размера кластера файловой системы тома с базой данных. Как вы видите, размер кластера файловой системы не даёт ощутимого влияния на результаты теста.
Примечание: при работе с реальной базой данных размер кластера файловой системы может оказывать существенное влияние на производительность, и это нужно учитывать и использовать размер кластера, рекомендованный для имеющегося размера тома.
Влияние совместной или раздельной архитектуры
На рис.10 представлены результаты теста Гилева для раздельной архитектуры (отдельный сервер СУБД). Обратите внимание, тест никак не учитывает в однопоточном тесте конфигурацию сервера СУБД, учитывается только конфигурация сервера, где развёрнута платформа «1С:Предприятие». В целом, производительность в тесте Гилева у раздельной архитектуры несколько ниже, чем у совместной, поскольку используется протокол tcp вместо более быстрого протокола shared memory.
Влияние нагруженности кластера и выделения ресурсов
На рис. 11 представлены результаты теста Гилева на виртуальной машине, расположенной на изолированном от основного кластера хосте. Результаты существенно выше предыдущих, поскольку все ресурсы хоста гарантированно предоставляются единственной виртуальной машине.
Рис. 12
На рис. 12 представлены результаты теста в общем кластере с включенными политиками гарантированного предоставления ресурсов. Как вы видите, результат существенно ниже, чем на изолированном хосте.
Итоги исследований
На результаты теста наибольшее влияние имеют отключение всех возможных технологий энергосбережения в гостевой операционной системе и базовая частота виртуального процессора
Нагруженность кластера, в котором работает виртуальная машина, может существенно влиять на результат теста Гилева
Совмещённая архитектура даёт более высокие результаты по сравнению с раздельной за счёт использования более быстрого протокола shared memory. Однако, при использовании такой архитектуры нужно внимательно следить за ресурсами, потребляемыми отдельными компонентами системы, чтобы избежать конкуренции
Надеюсь, эта информация будет вам полезна. И помните, что одними лишь синтетическими тестами руководствоваться не стоит. Обращаем ваше внимание на тот факт, что мы проводили тест Гилева по 1С в виртуальной среде на не очень мощных процессорах. В будущем можно будет провести исследование на новом железе. Интересно?
Что ещё интересного есть в блоге Cloud4Y
Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу.
Как вы уже знаете, мы запустили новую услугу 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 на борту — ценнейший раритет, поэтому мы считаем его бесценным и не будем брать во внимание стоимость его эксплуатации. (Мы не нашли в продаже эту же модель диска.)
Цены на железо установленное в эти ящики взяты из яндекс маркета, без учета стоимости кулеров, корпусов и блоков питания. Всегда находилась конкретная модель плашки оперативной памяти, материнской платы, установленный в каждый из компьютеров и из этого всего выбиралось самое дешевое предложение.
Итоговая таблица в баллах и стоимости
| Машина | Баллы | Стоимость |
| VM1 | 75.76 | 1404₽ в месяц |
| VM2 | 60.24 | 1166₽ в месяц |
| PC1 | 33.56 | От 17800₽ до 47800₽ |
| PC2 | 67.57 | 15135,68₽ |
| PC3 | 64.1 | 19999,2₽ |
| PC4 | 45.05 | 18695,75₽ |
| PC5 | 40.65 | 16422,6₽ |
Выводы
Размещение 1С на VDS стало достаточно выгодной опцией, если сравнивать его с приведенным железом.
Нужно понимать, что, сравнивая цены нужно держать в уме, что реальное железо всегда останется вашим хоть и потребляет электроэнергию и амортизируется, но так же вы теряете в отказоустойчивости, избыточности облака, в котором все, что должно быть зарезервировано, было продублировано. Кроме того, вы ощутимо теряете в гибкости, масштабировании, времени на настройку и в деньгах на зарплату инженера, который будет поддерживать железный зоопарк. Нам кажется, 1С на VDS — вполне целевое решение, которое может снять головные боли многих компаний. Поэтому пересматривайте тесты, открывайте эксель, считайте и принимайте решение — у вас будет «не шаткий, не валкий» январь, чтобы безболезненно внести изменения в инфраструктуру и в новом сезоне работать удобнее и проще.
В данной статье расскажем о том, как развернуть у себя на компьютере виртуальный сервер.
О том как установить сервер 1С описано в Установка сервера 1С Предприятие 8.3 на Linux.
Разворачиваем виртуальный сервер VirtualBox для 1С на Linux.
Возможные проблемы с виртуальным сервером VirtualBox и пути исправления.
Установим VirtualBox
2. Выполним его установку запуском файла VirtualBox-X.X.XX-XXXXXX-Win.exe.
3. Запустим VirtualBox от имени администратора.
Создадим виртуальный сервер
1. Добавим новую виртуальную машину, нажатием кнопки «Создать».
2. Заполним: «Имя», «Тип», «Версия», как показано на рисунке. Нажмем «Далее».
3. Укажем объем оперативной памяти. Нажмем «Далее».
Желательно указать около 8Гб, но и 4Гб для тестовых целей нам будет достаточно.
4. Создадим виртуальный жесткий диск, как показано на рисунке. Нажмём «Создать».
и формат хранения виртуального жесткого диска:
6. Выберем необходимый размер жесткого диска. Нажмем «Создать».
В нашем случае мы поставим 50Гб.
Настроим сеть виртуального сервера
2. Создадим сеть хоста.
3. Укажем настройки сети: «DHCP сервер», «Нижняя граница адресов», «Верхняя граница адресов», как показано на рисунке. Нажмем «Применить».
Установим операционную систему linux
1. Откроем настройки, нажав «Настроить».
2. Выберем раздел «Носители».
3. Выберем образ диска с операционной системой. В нашем случае ОС linux (CentOS 7).
4. Сохраним настройки. Нажмем «ОК».
5. После этого запустим виртуальную машину. Нажмем «Запустить».
6. Выполним захват клавиатуры виртуальной машины. Нажмем «Захватить».
О том, как выйти из режима захвата, написано в самом окне. По умолчанию -это нажатие правой клавиши «Ctrl».
7. Далее выполним непосредственно установку и настройку ОС:
- нажмем «Enter» для начала выполнения инсталляции;
- выберем язык, диск и начинаем инсталляцию;
- создадим пользователя, указываем пароль;
- завершим инсталляцию.
8. Выполним перезагрузку виртуального сервера.
9. Установим текстовый редактор vim. Он нам пригодится в дальнейшем для работы с сервером.
О том как работать с сервером linux можно прочитать в Основы работы в Linux.
Обзор основных команд приведен в Основные команды Linux.
Виртуальный сервер не пингуется. Не удается подключиться к виртуальному серверу через putty или другой ssh-клиент.
1. Проверим ip-адрес виртуального сервера.
В случае отсутствия в результате выполнения команды «внешнего ip», указанного в настройках менеджера хоста проверим настройки сети.
Именно эту сеть будем настраивать далее по тексту.
2. Для выполнения настроек используем утилиту nmtui.
3. Проверим есть ли необходимая сеть в списке подключенных.
4. Если данная сеть не подключена – нажмем «Подключить» или «Activate».
В случае успешного подключения окно будет выглядеть так:
5. В случае, если нашей сети в списке к подключению нет, или при повторном подключении сеть снова отсутствует, то вернемся в основное меню утилиты.
6. Нажмем «Изменить соединение» или «Edit a connection», в случае, если соединение есть в списке.
7. Проверим включен ли признак «Автоматическое подключение» или «Automatically connect». Если нет – включаем.
8. Сохраним изменения, нажатием кнопки «OK».
Виртуальный сервер пингуется, но не удается подключиться к виртуальному серверу через putty или другой ssh-клиент.
1. Проверим, не блокируются ли запросы файерволлом или брадмауэром или другими подобными программами. Как на стороне виртуального сервера, так и на стороне ssh-клиента.
Последние несколько лет стала очень широко использоваться виртуализация, администраторы очень быстро увидели плюсы для себя: очень удобно работать с такой машиной, легко переносить её между несколькими физическими серверами, можно настроить отказоустойчивую схему, когда одну виртуальную машину могут обслуживать более одного физического сервера. Кроме того, виртуалка перезагружается на порядок быстрее. Кто не знает, приличный физический сервер может спокойно перезагружаться по 10-15 минут: пока всё потушит, пока сразу после старта неспешно всё у себя проверит, затем даст возможность контроллерам дисковых накопителей потестировать себя и диски всласть, и только после этого начинает грузить операционную систему. Виртуальный же сервер все проверки проскакивает за секунды, с точки зрения железа это всего лишь обычная программа. А для руководства компании мощнейший плюс виртуализации состоит ещё и в том, что можно взять например десять устаревших серверов, и запихнуть их функции на один физический, получается серьёзная экономия что на модернизации оборудования как такового, что на площади серверной комнаты, что на электричестве, нужном для работы и охлаждения сервера. Или можно арендовать в дата-центре вместо десяти слабеньких серверов один сильненький за меньшие суммарно деньги. К тому же, если например раньше вам потребовалось бы увеличить в два раза мощность двух из этих десяти серверов, это могло повлечь за собой необходимость апгрейда этих серверов. А в виртуальной системе достаточно изменить настройки выделения ресурсов. Ну и если вдруг мощности конкретного хост-сервера перестало хватать, можно вынести отдельные виртуалки на другой сервер, причём в некоторых случаях можно их даже не выключать.
Ну то есть замечательная технология. А есть ли у неё минусы? К сожалению, есть.
Во-вторых, свои штрафы накладывает эмуляция сетевых интерфейсов и эмуляция сетевых дисков, которые тоже отнимают каждая свои процентики.
Однако схема такая сразу начинает работать медленней. Причём, например результат нашего теста может упасть сразу в два раза.
Почему? Например, потому что раньше сервер 1С и сервер СУБД внутри одной операционной системы общались между собой по протоколу Shared Memory, и это было очень быстро. А теперь используют сетевой интерфейс, а даже внутри одного сервера виртуализация сети- задача по ресурсам совсем не бесплатная.
А кроме того, есть ещё и неудобные для 1С сочетания факторов, вот как на снимке: использование сетевого интерфейса WMXNET3 практически гарантирует узкое место на передаче данных 1С по сети.
Есть ещё ряд факторов, которые могут ухудшить производительность виртуальной среды относительно выполнения той же программы на физическом железе без виртуализации.
Мы же выделим один наиболее значимый. Теперь кроме всех прочих факторов, добавляется ещё один, совершенно непредсказуемый для виртуальной машины: на этом же железе может исполняться неизвестное количество других виртуальных машин, нагрузка которых может колебаться от условного 0 до 100%. Благодаря этому можно наблюдать например такую картину: сидит один пользователь в базе, на сервере 1С кроме него никого нет, и запускает один и тот же несложный отчёт, например взаиморасчёты по отдельным контрагентам с расшифровкой по документам. Объём данных примерно одинаковый, и время формирования должно быть примерно одинаковым, но нет! То отчёт формируется за секунду, а то приходится ждать целую минуту. Почему? А потому что на этом же физическом сервере в это время например другой бухгалтер в другой базе на другом сервере запустил закрытие месяца, и сервер страшно занят. Изнутри виртуальной машины вот это внешнее влияние отследить совершенно никак невозможно, только с тоской наблюдать, как скачут замеры времени ключевых операций.
Что делать в данном случае? Обеспечить гарантированно высокую производительность системы можно только в том случае, когда ей никто не может помешать. То есть ответ простой: если высокая производительность какой-то конкретной базы 1С является ключевым показателем работы сервера, то всех остальных пассажиров приходится подвинуть. Либо на конкретном примере с объективными замерами показываем админам, что разница в производительности слишком велика, чтобы её игнорировать, и дальше конкретно эта база 1С обслуживается физическим сервером без виртуализации, либо разгружаем виртуальный сервер от всех сторонних виртуальных машин, и эта база 1С обслуживается виртуальным сервером, но её производительность в любом случае становится стабильной.
В книжке 1С эксперта на 22й странице методика считает, что наиболее значимый вклад составляют плохая работа запроса и плохая работа кода. При этом способность среды выполнять действия с необходимой скоростью не рассматривается. Считается, что во-первых скорость среды неизменна, хотя в виртуальной среде это может быть совсем не так. Кроме того, схожая по внешним признакам среда на практике может кардинально отличаться способностью выполнять такой же объём работ за единицу времени. На сервер может быть возложена куча других задач («резиновый сервер»: купили дорогой, надо использовать ) Обычно, когда проводят нагрузочное тестирование – его всегда проводят с имитацией деятельности в базе, но в реальной жизни надо учитывать и имитировать любую другую стороннюю нагрузку (веб-сервер, терминальный сервер, другая ERP), которые могут отнимать непредсказуемую часть ресурсов сервера. В учебнике приводится упрощённый вариант, которого в жизни обычно не бывает. Написанное в учебнике правильно, но этого явно недостаточно для того, чтобы решать задачу по-настоящему. Умение разложить состав нагрузки по составляющим источникам позволяет существенно сократить объём денег и усилий, необходимых для решения проблем.
Кроме того, многие компании, обеспечивающие работу в ЦОД, зачастую не могут сказать – где находится физически виртуальная машина. Таким образом, эксплуатируемое приложение в виртуальной среде, не привязанное к физическому оборудованию, при частой миграции виртуальной среды между узлами, может кардинально менять скорость исполнения в виртуальной среде. Также вы можете встретиться с ситуацией, когда несколько айти-специалистов берут из одного источника один и тот же образ виртуальной машины, запускают на своих компьютерах с максимально похожими характеристиками, и получают совершенно разные результаты тестов производительности. Более того, даже запуская на одном компьютере несколько копий одного образа, неожиданно выясняется необходимость понимания механизма привязки виртуальных ядер к физическим ядрам процессора. Например, когда на четырёхсокетной машине виртуальная система выбирает ядра разных процессоров, скорость отличается от той же самой виртуалки, ядра которой привязаны к одному физическому процессору.
В качестве ещё одного примера: у нас в своё время был неприятный опыт отладки запроса на базе 1С, размещённой в облаке Амазон. Сервер 1С был развёрнут на одной амазоновской виртуалке, сервер СУБД на другой. Сидим на тестовом сервере в одном сеансе, никого больше нет. Запускаем один и тот же довольно несложный запрос и замечаю, что время его выполнения может отличаться на порядок. То есть к примеру он может выполниться за 3 секунды, в следующий раз за 25, потом за 10. Внутри тестовых серверов не происходит ничего, что могло бы объяснить такую разницу. Всё зависит от того, сколько и каких виртуалок ещё развёрнуто на тех же физических серверах, какую они генерируют загрузку процессоров, памяти, дисков и сети.
В жизни бывают ещё более сложные задачи, когда из-за несущественных на первый взгляд факторов может измениться скорость среды.
Запись опубликована автором admin в рубрике Администрирование, производительность, тюнинг с метками виртуализация. Добавьте в закладки постоянную ссылку.
Читайте также: