Как запустить тест гилева 1с
Основная цель написания статьи — чтобы не повторять очевидные нюансы тем администраторам (и программистам), которые еще не набрали опыта с 1С.
Вторичная цель, если у меня будут какие-то недочеты, — на Инфостарте мне это укажут быстрее всего.
Неким стандартом "де факто" уже стал тест В. Гилева. Автор на своем сайте дал вполне понятные рекомендации, я же просто приведу некоторые результаты, и прокомментирую наиболее вероятные ошибки. Естественно, что результаты тестирования на Вашем оборудовании могут отличаться, это просто для ориентира, что должно быть и к чему можно стремиться. Сразу хочу отметить, что изменения надо делать пошагово, и после каждого шага проверять, какой результат это дало.
На Инфостарте подобные статьи есть, в соответствующих разделх буду ставить на них ссылки (если пропущу что-то - просьба подсказать в комментариях, добавлю). Итак, предположим у вас тормозит 1С. Как диагностировать проблему, и как понять кто виноват, администратор или программист?
Тестируемый компьютер, основной подопытный кролик: HP DL180G6, в комплектации 2*Xeon 5650, 32 Gb, Intel 362i , Win 2008 r2. Для сравнения, сопоставимые результаты в однопоточном тесте показывает Core i3-2100. Оборудование специально взял не самое новое, на современном оборудовании результаты заметно лучше.
Для тестирования разнесенных серверов 1С и SQL, сервер SQL: IBM System 3650 x4, 2*Xeon E5-2630, 32 Gb, Intel 350, Win 2008 r2.
Для проверки 10 Gbit сети использовались Intel 520-DA2 адаптеры.
Файловая версия. (база лежит на сервере в расшаренной папке, клиенты подключаются по сети, протокол CIFS/SMB). Алгоритм по шагам:
0. Добавляем на файловый сервер тестовую базу Гилева в ту же папку, что и основные базы. С клиентского компьютера подключаемся, запускаем тест. Запоминаем получившийся результат.
Подразумевается, что даже для старых компьютеров 10 летней давности (Pentium на 775 socket) время от нажатия на ярлык 1С:Предприятие до появления окна базы должно пройти меньше минуты. (Celeron = медленная работа).
Если у Вас компьютер хуже, чем пентиум на 775 socket с 1 гб оперативной памяти, то я Вам сочувствую, и комфортной работы на 1С 8.2 в файловой версии Вам будет добиться тяжело. Задумайтесь или об апгрейде (давно пора), или о переходе на терминальный (или web, в случае тонких клиентов и управляемых форм) сервер.
Если компьютер не хуже, то можно пинать администратора. Как минимум — проверить работу сети, антивируса и драйвера защиты HASP.
Если тест Гилева на этом этапе показал 30 "попугаев" и выше, но рабочая база 1С все равно работает медленно - вопросы уже к программисту.
1. Для ориентира, сколько же может "выжать" клиентский компьютер, проверяем работу только этого компьютера, без сети. Тестовую базу ставим на локальный компьютер (на очень быстрый диск). Если на клиентском компьютере нет нормального ССД, то создается рамдиск. Пока, самое простое и бесплатное — Ramdisk enterprise.
Для тестирования версии 8.2 вполне достаточно 256 мб рамдиска, и! Самое главное. После перезагрузки компьютера, с работающим рамдиском, на нем должно быть свободно 100-200 мб. Соответственно, без рамдиска, для нормальной работы свободной памяти должно быть 300-400 мб.
Для тестирования версии 8.3 рамдиска 256 мб хватит, но свободной оперативной памяти надо больше.
При тестировании нужно смотреть на загрузку процессора. В случае, близком к идеальному(рамдиск), локальная файловая 1с при работе загружает 1 ядро процессора. Соответственно, если при тестировании у вас ядро процессора загружено не полностью — ищите слабые места. Немного эмоционально, но в целом корректно, влияние процессора на работу 1С описано здесь. Просто для ориентира, даже на современных Core i3 с высокой частотой вполне реальны цифры 70-80.
Наиболее часто встречающиеся ошибки на этом этапе.
- Неправильно настроенный антивирус. Антивирусов много, настройки для каждого свои, скажу лишь то, что при грамотной настройке ни веб, ни касперский 1С не мешают. При настройках "по умолчанию" - может отниматься примерно 3-5 попугаев (10-15%).
- Режим производительности. Почему-то на это мало кто обращает внимания, а эффект - самый весомый. Если нужна скорость - то делать это обязательно, и на клиентских и на серверных компьютерах. (Хорошее описание у Гилева. Единственный нюанс, на некоторых материнских платах если выключить Intel SpeedStep то нельзя включать TurboBoost).
Включать режим производительности можно (и желательно) в двух местах:
- через BIOS. Отключить режимы C1, C1E, Intel С-state (C2, C3,C4). В разных биосах они называтся по разному, но смысл один. Искать долго, требуется перезагрузка, но если сделал один раз - потом можно забыть. Если в BIOS все сделать правильно, то скорости добавится. На некоторых материнских платах настройками BIOS можно сделать так, что режим производительности Windows роли играть не будет. (Примеры настройки BIOS у Гилева). Эти настройки в основном касаются серверных процессоров или "продвинутых" BIOS, если Вы такое у себя не нашли, и у вас НЕ Xeon - ничего страшного.
- Панель управления - Электропитание - Высокая производительность. Минус - если ТО комптютера давно не проводилось, он будет сильнее гудеть вентилятором, будет больше греться и потреблять больше энергии. Это - плата за производительность.
В BIOS C-state включены,
режим энергопотребления сбалансированный
Для Pentium и Core на этом можно остановиться,
из Xeon еще можно выжать немного "попугайчиков"
Если не использовать Turbo boost - именно так должен выглядеть
сервер, настроенный на производительность
А теперь цифры. Напомню: Intel Xeon 5650, ramdisk. В первом случае тест показывает 23.26, в последнем - 49.5. Разница - почти двухкратная. Цифры могут варьироваться, но соотношение остается практически таким же для Intel Core.
в) Turbo Boost. Сначала надо понять, поддерживает ли Ваш процессор эту функцию, например здесь. Если поддерживает, то можно еще вполне легально получить немного производительности. (вопросы разгона по частоте, особенно серверов, касаться не хочу, делайте это на свой страх и риск. Но соглашусь с тем, что повышение Bus speed со 133 до 166 дает очень ощутимый прирост как скорости, так и тепловыделения)
Как включать turbo boost написано, например, здесь. Но! Для 1С есть некоторые нюансы (не самые очевидные). Сложность в том, что максимальный эффект от turbo boost проявляется тогда, когда включены C-state. И получается примерно такая картинка:
Обратите внимание, что множитель - максимальный, частота Core speed - красивейшая, производительность - высокая. Но что же будет в результате с 1с?
Core speed (частота), GHz
CPU-Z Single Thread
Тест Гилева Ramdisk
Тест Гилева Ramdisk
А в итоге получается, что по тестам производительности ЦПУ вариант с множителем 23 впереди, по тестам Гилева в файловой версии - производительность с множителем 22 и 23 одинаковая, а вот в клиент-серверной - вариант с множителем 23 ужас ужас ужас (даже, если C-state выставить на уровень 7, то все равно медленнее, чем с выключенным C-state). Поэтому рекомендация, проверьте оба варианта у себя, и выберите из них лучший. В любом случае, разница 49,5 и 53 попугая - достаточно значительная, тем более это без особых усилий.
Вывод - turbo boost включать обязательно. Напомню, что недостаточно включить пункт Turbo boost в биосе, надо еще посмотреть и другие настройки (BIOS: QPI L0s, L1 - disable, demand scrubbing - disable, Intel SpeedStep - enable, Turbo boost - enable. Панель управления - Электропитание - Высокая производительность). И я бы все-таки (даже для файловой версии) остановился на варианте, где c-state выключен, хоть там множитель и меньше. Получится как-то так.
Достаточно спорным моментом является частота памяти. Например вот тут частота памяти показывается как очень сильно влияющая. Мои же тесты - такой зависимости не выявили. Я не буду сравнивать DDR 2/3/4, я покажу результаты изменения частоты в пределах одной линейки. Память одна и та же, но в биосе принудительно ставим меньшие частоты.
И результаты тестирования. 1С 8.2.19.83, для файлового варианта локальный рамдиск, для клиент-серверного 1С и SQL на одном компьютере, Shared memory. Turbo boost в обоих вариантах выключен. 8.3 показывает сопоставимые результаты.
800 | 1066 | 1333 | |
48,54 | 49,50 | 50,51 | |
1с 8.2 файловый вариант | 49,50 | 49,50 | 49,02 |
49,02 | 49,02 | 49,50 | |
36,76 | 36,76 | 37,04 | |
1с 8.2 клиент-сервер | 37,04 | 37,04 | 36,50 |
36,23 | 36,76 | 36,76 |
Разница - в пределах погрешности измерений. Я специально вытащил скрины CPU-Z чтобы показать, что со сменой частоты меняются и другие параметры, те же CAS Latency и RAS to CAS Delay, что нивелирует изменение частоты. Разница будет тогда, когда физически будут меняться модули памяти, с более медленных на более быстрые, но и там цифры не особо значительные.
2. Когда с процессором и памятью клиентского компьютера разобрались, переходим к следующему очень важному месту - сети. Про тюнинг сети написаны многие тома книг, есть статьи на Инфостарте (1, 2 и другие), здесь я на эту тему заострять внимание не буду. Перед началом тестирования 1С просьба убедиться, что iperf между двумя компьютерами показывает всю полосу (для 1 гбит карточек - ну хотя бы 850 мбит, а лучше 950-980), что выполнены советы Гилева. Потом - самой простой проверкой работы будет, как это ни странно, копирование одного большого файла (5-10 гигабайт) по сети. Косвенным признаком нормальной работы на сети в 1 гбит будет средняя скорость копирования 100 мб/сек, хорошей работы — 120 мб/сек. Хочу обратить внимание, что слабым местом (в том числе) может быть и загруженность процессора. SMB протокол на Linux достаточно плохо параллелится, и во время работы он вполне спокойно может «скушать» одно ядро процессора, и больше не потреблять.
И еще. С настройками по умолчанию windows клиент лучше всего работает с windows server (или даже windows рабочая станция) и протоколом SMB/CIFS, linux клиент (debian, ubuntu остальные не смотрел) лучше работает с linux и NFS (с SMB тоже работает, но на NFS попугаи выше). То, что при линейном копировании вин-линукс сервер на нфс копируется в один поток быстрее, еще ни о чем не говорит. Тюнинг debian для 1С - тема отдельной статьи, я к ней еще не готов, хотя могу сказать, что в файловой версии получал даже немного бОльшую производительность, чем Win вариант на этом же оборудовании, но с postgres при пользователях свыше 50 у меня пока еще все очень плохо.
Самое главное, о чем знают "обжегшиеся" администраторы, но не учитывают начинающие. Есть очень много способов задать путь к базе 1с. Можно сделать servershare, можно 192.168.0.1share, можно net use z: 192.168.0.1share (и в некоторых случаях такой способ тоже сработает, но далеко не всегда) и потом указывать диск Z. Вроде бы все эти пути указывают на одно и то же место, но для 1С есть только один способ, достаточно стабильно дающий нормальную производительность. Так вот, правильно делать надо так:
В командной строке (или в политиках, или как Вам удобно) - делаете net use DriveLetter: servershare. Пример: net use m: serverbases. Я специально подчеркиваю, НЕ IP адрес, а именно имя сервера. Если сервер по имени не виден - добавьте его в dns на сервере, или локально в файл hosts. Но обращение должно быть по имени. Соответственно - в пути к базе обращаться к этому диску (см картинку).
А теперь я на цифрах покажу, почему именно такой совет. Исходные данные: Карты Intel X520-DA2, Intel 362, Intel 350, Realtek 8169. ОС Win 2008 R2, Win 7, Debian 8. Драйвера последние, обновления применены. Перед тестированием я убедился, что Iperf дает полную полосу (кроме 10 гбит карточек, там получилось только 7.2 Gbit выжать, позже посмотрю почему, тестовый сервер еще не настроен как надо). Диски разные, но везде SSD(специально вставил одиночный диск для тестирования, больше ничем не нагружен) или рейд из SSD. Скорость 100 Mbit получена путем ограничения в настройках адаптера Intel 362. Разницы между 1 Gbit медь Intel 350 и 1 Gbit оптика Intel X520-DA2 (полученной путем ограничения скорости адаптера) не обнаружено. Максимальная производительность, турбобуст выключен (просто для сопоставимости результатов, турбобуст для хороших результатов добавляет чуть меньше 10%, для плохих - вообще может никак не сказаться). Версии 1С 8.2.19.86, 8.3.6.2076. Цифры привожу не все, а только самые интересные, чтобы было с чем сравнивать.
Тестируем производительность файлового режима 1С:Предприятие в Windows и Linux
Несмотря на то, что клиент 1С для Linux существует уже достаточно много времени мифов и заблуждений по этому вопросу меньше не становится. Один из них: платформа 1С под Linux работает медленнее. В качестве аргументов обычно приводится либо субъективный опыт, либо отсылка к субъективному опыту коллег. Понятно, что такие "доказательства" никуда не годятся, но какого-либо сравнительного материала нам найти так и не удалось, пришлось браться за дело самим. Мы протестировали наиболее популярные платформы и получили достаточно интересные результаты, которыми решили поделиться в этой статье.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Первоначально мы не собирались затевать большого исследования, нас интересовали вполне конкретные версии современных ОС, но коллеги попросили добавить в тестирование Windows 7, как до сих пор популярную платформу, Ubuntu Mate, в качестве "нестареющей классики" и альтернативы современным рабочим окружениям (Mate - форк Gnome 2). Раз уж пошло такое дело, то мы добавили всю основную линейку дистрибутивов Ubuntu 18.04 и Ubuntu 16.04 с Unity, как все еще достаточно популярную ОС.
Методика тестирования
Для тестирования на чистую ОС со всеми последними обновлениями была установлена платформа 8.3.13.1513 и был запущен тест Гилева, в качестве результата бралось среднее от трех прогонов, также после этого фиксировалось количество занятой оперативной памяти. Все ОС устанавливались в 64-разрядном варианте, платформа x64 на Linux и x32 + x64 на Windows, но ввиду одинаковых результатов с x32 приведено среднее значение всех запусков. Разбивка диска одним разделом, файловые системы NTFS и ext4, все расположения файлов стандартные.
В качестве аппаратной части мы использовали виртуальные машины в одинаковой конфигурации: 2 ядра Core i5-4670, 4 ГБ RAM и размещали виртуальный диск на RAID 0 из двух Seagate 2 Тб (ST2000DM006). При выборе аппаратной части не стоял вопрос оценить производительность какой-либо существующей конфигурации, а требовалось провести сравнительный тест в равных условиях. Что касается вычислительной мощности, то два ядра Core i5-4670 приблизительно эквивалентны Core i3 того же поколения, что соответствует достаточно неплохой рабочей станции.
Результаты теста
Результаты оказались достаточно неожиданными и заставили нас несколько раз их перепроверить, но во всех случаях были получены аналогичные результаты.
Следующим в нашем тестировании участвовала Ubuntu 16.04, довольно старая, но все еще популярная ОС со своей армией поклонников (примерно, как Windows 7), но результат откровенно порадовал. Несмотря на то, что Ubuntu опережает "десятку" где-то на 6%, мы склонны поставить эти системы на одну ступень, разница не столь велика, чтобы говорить о превосходстве одной ОС над другой.
А вот дальше пошло интереснее, Ubuntu и Kubuntu 18.04 - две ведущие современные системы с мощными графическими оболочками (Gnome3 и KDE Plasma 5) показали просто отличный результат, опережая Windows 10 и Ubuntu 16.04 в среднем на 25%, это серьезная заявка на победу и развенчание мифа про то, что 1С под Linux тормозит.
Но Xubuntu решительно вырвался в лидеры, причем полученные результаты заставили нас создать еще одну виртуалку с нуля и в ней повторить тест, повторно получив такой-же результат. Разница составила около 10% по сравнению с Ubuntu и Kubuntu и совсем уж неприличные 40% относительно Windows 10.
Несмотря на то, что XFCE (рабочая среда Xubuntu) считается достаточно легковесной, мы протестировали совсем "легкий" дистрибутив Lubuntu c LXDE, результат несколько уступил лидеру, но несколько опередил основные "тяжелые" дистрибутивы.
Ubuntu Mate никаких особых результатов не принесла, показав результат чуть ниже среднего для основных Linux дистрибутивов.
Другим важным результатом тестов является потребность в оперативной памяти, так как мы уже выясняли, что современные конфигурации имеют в ее отношении неплохие аппетиты и достаточно плохо реагируют на ее недостаток.
Долгое время типовые офисные ПК имели конфигурацию типа "два ядра - два гига", т.е. какой-нибудь недорогой процессор и 2 ГБ оперативной памяти. Сейчас ситуация улучшилась и меньше 4 ГБ в связку к такому же недорогому процессору не ставят, также наметилась тенденция к переходу с HDD на SSD, что тоже не может не радовать.
Windows 7, согласно реалиям того времени, показывает относительную неприхотливость и здесь мы даже согласимся с таким аргументом ее поклонников, что "на старых ПК Windows 7 работает лучше". В один ряд с ней можно поставить и такие "легковесные" дистрибутивы как Ubuntu Mate и Xubuntu, хотя последняя будет даже "потяжелее". Действительно легким сегодня является только Lubuntu, которой с запущенной 1С хватило 1 ГБ памяти.
Что касается Windows 10 и Ubuntu 18.04 с Gnome3, то для нормальной работы им требуется не менее 4 ГБ памяти, попытка использовать их на старых ПК ни к чему хорошему не приведет. Ubuntu 16.04 и Kubuntu заняли промежуточное положение, но на системах с 2 ГБ памяти работать с ними также будет некомфортно. Хотя Kubuntu нас приятно удивила, по расхожему мнению, KDE Plasma 5 не менее ресурсоемка, чем Gnome3, хотя на практике аппетиты этого рабочего окружения оказались более чем умеренны.
Так почему же тормозит 1С?
Как мы уже выяснили, при прочих равных 1С в среде Linux работает даже быстрее, но откуда тогда жалобы на то, что тормозит? Разберем два реальных случая.
Одним из клиентов был куплен новый моноблок HP 20-c000ur, на базе не сильно мощного процессора AMD E2 7110 и 4 ГБ памяти на борту, на него поставили Ubuntu 18.04 и отправили в работу. Вроде бы 4 ГБ должно хватать. Но кроме 1С на самом обычном офисном ПК будет запущен как минимум браузер и табличный/текстовый редактор, а если учесть что тест Гилева не самая требовательная к памяти конфигурация, то на практике оказалось, что этих 4 ГБ системе "впритык". И тормозила не только 1С, но и вообще всё.
Решение простое - поставили Xubuntu, после этого вопросы к производительности отпали.
Выводы
По результатам тестов может показаться, что Linux - панацея от всех бед с производительностью 1С и всем надо срочно на него переходить. Но не все так просто. На достаточно мощном железе вы просто не заметите на повседневных задачах разницы между 42 и 52 по Гилеву. Также справедливо и то, что если файловый режим выдает вам всего 20 баллов, то на этом ПК тормозить будет не только 1С, а вообще все. Поэтому при выборе ОС нужно исходить из реальных потребностей, трезво оценивая список необходимого ПО и его совместимость с выбранной системой.
Если вам нужен Windows - берите Windows 10, только не забудьте обеспечить ее необходимыми ресурсами. А вот что касается Linux, то тут не все так просто, использование на рабочих ПК таких окружений как Gnome3, на наш взгляд просто расточительство. XFCE выглядит вполне привлекательно, но гораздо экономнее к ресурсам, если же вам хочется чего-то большего - то посмотрите в сторону KDE, это, весьма продвинутое в графическом плане окружение, гораздо более оптимизировано и не так требовательно к ресурсам.
Что касается старых ПК, то здесь следует понимать, что старые ОС, это касается как Windows 7, так и Ubuntu 16.04, при всей их нетребовательности с современным ПО работают хуже, чем современные системы.
Отдельное слово следует сказать о "легковесных" дистрибутивах, в среде Linux долгое время ходил миф, что эти системы показывают чудеса производительности там, где Windows тормозит. Но чудес нет, и современный пользователь имеет определенную нижнюю планку комфорта, которую должно обеспечивать рабочее окружение, в том числе и по визуальным эффектам. Поэтому "легковесность" таких окружений как XFCE относительная и обозначает требования как минимум на уровне Windows 7.
Но в остальном свежая Xubuntu выглядит более привлекательно, чем ветеран Windows 7, и, при отсутствии противопоказаний, является лучшим вариантом для работы.
Из "легких" дистрибутивов действительно таким пока остается Lubuntu с требованиями примерно на уровне Windows XP, что позволяет в ряде случаев дать вторую жизнь старой технике. Что касается "нестареющей классики" Mate, он же Gnome 2, то на наш взгляд - это сугубо на любителя. Обладая производительностью на уровне основных дистрибутивов это окружение выглядит сегодня достаточно устаревшим, да и непривычно обычному пользователю, тот же XFCE выглядит на наш взгляд гораздо лучше.
Что остается в сухом остатке? Миф, что 1С под Linux тормозит не выдерживает никакой критики. В остальном следует руководствоваться здравым смыслом и выбирать ОС под конкретные задачи с учетом необходимых системных требований.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Тест Гилева – нагрузочный тест, с помощью которого можно сделать выводы о быстродействии платформы «1С:Предприятие». Многие ИТ-специалисты уделяют много внимания итогам данного теста. Причём в большей степени однопоточному тесту, так как считают его более наглядным и простым. Однако это не до конца верно.
Однако тест Гилева на деле не показывает быстродействие настоящей конфигурации с настоящей базой данных. Обычно его запускают на пустой платформе, так как изначально его придумали для проверки дискретных серверов. Однако тест можно запустить на настоящей рабочей системе.
В статье расскажем о том, как влияют те или иные варианты оптимизации виртуальной машины, гостевой ОС и различное ПО на показатели теста Гилева.
Начальные данные
Тест Гилева обычно применяется для того, чтобы сделать выводы о производительности при хранении баз данных 1С с использованием СУБД, но подойдёт и для файлового варианта хранения. Он идёт в формате файла конфигурации (*.cf), который можно загрузить в конфигураторе «1С:Предприятие».
Тест можно разделить на две части. Каждую из них можно запускать отдельно.
Часть 1 – однопоточный тест, который позволяет оценить производительность операций в один поток. Это характерная черта платформы «1С:Предприятие». По итогам теста выстраивается график в форме столбчатой диаграммы. Читать его следует слева направо. На графике показаны результаты настоящего теста, а также результаты, которые соответствуют условным оценкам «плохо» (10), «удовлетворительно» (15), «хорошо» (35) и «отлично» (60).
Часть 2 – многопоточный тест, который позволит оценить скорость, с которой осуществляется запись на диски при параллельном отправлении запросов к базе данных. Выходной результат представляет собой наибольшие скорости одного потока, наибольшую скорость записи и количества юзеров, рекомендованное для одновременной работы. Вторая часть теста недоступна, если используется файловая архитектура хранения баз.
Результаты можно также сохранить в облако, где их можно сравнить с результатами тестов, сделанных другими пользователями.
Среда тестирования
Чтобы провести тест в «стандартном» облаке Cloud4Y мы развернули ВМ с гостевой операционкой Windows Server 2019 из базового шаблона с паравиртуальным драйвером дисков.
В роли СУБД выступил Microsoft SQL Server 2019 версии Standard. Версия Express приведёт к аналогичным результатам тестирования, но её нельзя применять на реальных базах, так как в ней есть ограничения.
На ВМ инсталлировали сервер «1С:Предприятие» и выполнили настройку кластера серверов 1С. Инсталлировали добавочные средства администрирования серверов 1С. Конфигурация была только одна – сам тест Гилева.
Чтобы протестировать раздельную конфигурацию, при которой сервер 1С и СУБД помещены на различные ВМ, мы выполнили клонирование начальной виртуальной машины, а потом в гостевой операционной системе каждой из ВМ удалили ненужные компоненты и выполнили дополнительную настройку.
Сделанные оптимизации
Запуск теста
Теперь можно оценить, какое влияние оказывают разные настройки инфраструктуры
Виртуальные процессоры и сокеты
Изображение 1. Влияние количества сокетов
Изображение 2. Влияние количества сокетов
Изображение 3. Влияние количества сокетов
Изображения 1-3 показывают, как сильно влияют сокеты в случае совмещённой конфигурации. Наибольшие значения получаются, когда сокет всего один. Чем их больше, тем результаты теста ниже.
Изображение 4. Влияние виртуальных процессоров
Изображение 5. Влияние виртуальных процессоров
Изображения 4 и 5 показывают, как влияет увеличение числа виртуальных процессоров. Особого подъёма результатов от увеличения количества процессоров не наблюдается.
Примечание: однако важно учитывать, что в работе с настоящей базой данных, а также при подключении более одного юзера увеличение числа виртуальных процессоров ощутимо повлияет на производительность.
Объём RAM
Следующим шагом разберём влияние RAM
Изображение 6. Влияние RAM
Тест показывает, что увеличение объёма памяти не даёт заметного прироста.
Примечание: нужно учесть, что с настоящей базой данных и в случае, когда подключается более, чем один юзер, объём RAM ощутимо скажется на производительности.
Объём кластера файловой системы тома с базой данных
Изображение 7. Влияние объёма кластера файловой системы
Изображение 8. Влияние объёма кластера файловой системы
Изображение 9. Влияние объёма кластера файловой системы
На изображениях 7-9 видно, какое оказывает влияние на производительность размер кластера файловой системы тома, где расположена база данных. Это влияние настолько мало, что им можно пренебречь.
Примечание: Для настоящей базы данных размер кластера файловой системы заметно влияет на производительность. Так что стоит брать размер кластера, который рекомендуется для соответствующего размера тома.
Совместная или раздельная архитектура
Изображение 10. Раздельная архитектура
Изображение 10 отражает итоги тестирования для раздельной архитектуры (то есть используется отдельный сервер СУБД). Конфигурация СУБД в этом случае в расчёт не берётся, важна лишь конфигурация сервера, в рамках которого развёрнута платформа «1С:Предприятие». По итогам теста видно, что производительность у раздельной архитектуры ощутимо ниже, чем в случае совместной. Это обосновано тем, что применяется протокол tcp вместо shared memory, который является более быстрым.
Нагруженность кластера и выделение ресурсов
Изображение 11. Нагруженность кластера
Изображение 11 демонстрирует результаты теста на ВМ, которая находится на хосте, изолированном от основного кластера. Результаты ощутимо выше предыдущих, так как все ресурсы хоста гарантированно идут на нужды единственной ВМ.
Изображение 12. Выделение ресурсов
Изображение 12 демонстрирует итоговые значения теста в общем кластере, где активны политики гарантированного выделения ресурсов. Показатели ощутимо ниже, чем на изолированном хосте.
Выводы
Напоминаем, что не стоит принимать решения только на основе синтетических тестов. Cloud4Y проводил тест Гилева по 1С в виртуальной среде на не очень мощных процессорах. Возможно в будущем появится тест на новом «железе».
Америку не откроем, если скажем, что виртуальные машины на новых процессорах всегда производительнее оборудования на процессорах старого поколения. Интереснее другое: при анализе возможностей систем, казалось бы, очень близких по своим техническим характеристикам, результат может быть совершенно различным. Мы в этом убедились, когда протестировали процессоры Intel в нашем облаке, чтобы проверить, какие из них дают наибольшую отдачу при работе систем на 1С.
Спойлер: как показал наш тест, всё зависит от поставленной задачи. Нам удалось из всей линейки новых процессоров Intel выбрать тот продукт, который дал кратный прирост производительности благодаря тому, что в Intel Xeon Gold 6244 меньшее количество ядер, на каждое ядро приходится большее количество L3 кэш-памяти и назначена большая тактовая частота — как базовая, так и в режиме Turbo Boost. Иными словами, именно эти процессоры лучше справляются с ресурсоёмкими задачами в пересчёте на единицу производительности/рубль. Для 1С это подходит как нельзя лучше: с новыми процессорами приложения на 1С в нашем облаке начали буквально «дышать».
А теперь расскажем, как мы проводили тестирование. Ниже — результаты синтетических тестов Гилёва. На них можно ориентироваться, но в любом случае нужно проверять реальную утилизацию самостоятельно на своих задачах.
Условия теста
Важное замечание: мы делали сравнение без каких-либо дополнительных оптимизаций, а не бенчмарк. При дополнительной настройке систем в облаке результаты будут гарантированно лучше.
Дано: две виртуальные машины с 8 vCPU и 64 GB RAM с дисками FLASH 10.000 IOPS.
База данных Postgresql — неслучайно, поскольку её эксплуатация наиболее приближена к реальным условиям использования 1С нашими заказчиками. Да-да, мы делали синтетические тесты, похожие на типовые инсталляции, то есть это не универсальный ответ на все вопросы Вселенной, а именно ориентир для вашего собственного анализа.
Важно то, что в случае использования файловой архитектуры вместо базы данных результаты тестов обычно бывают выше. Но в реальности такой тип архитектуры используется только для совсем маленьких инсталляций. Вот здесь RuVDS тестировал на файловой архитектуре. И вот что по этому поводу в комментарии сказал сам Вячеслав Гилёв:
Если речь идёт об аренде 1С в файловом режиме, то да, но то, что мне на глаза попадается, работает исключительно в клиент-серверном варианте. Есть смысл: 1) или в статью это уточнение внести; 2) или протестировать клиент-серверный вариант, потому что разница в архитектуре значительна, и файловый вариант не обладает полным функционалом.
Никаких дополнительных настроек операционной системы и продукта 1С не производили.
Процессоры
- В левом углу ринга — процессор Intel Xeon E5-2690 v2, 3,00 ГГц.
- В правом углу ринга — Intel Xeon Gold 6254, 3,10 ГГц.
- По центру ринга — Intel Xeon Gold 6244, 3,60 ГГц.
Результаты
Intel Xeon E5-2690 v2, 3,00 ГГц:
«Хорошо» для нас — минимальная отметка, которая гарантирует комфортный уровень работы заказчика с системами 1С.
Intel Xeon Gold 6254, 3,10 ГГц:
Процессор Intel Xeon Gold 6244, 3,60 ГГц:
Итого: даже если виртуальная машина на Intel Xeon Gold 6244 на 3,6 ГГц будет стоить на 60 % дороже по сравнению с E5-2690 v2 на 3 ГГц, то стоит выбирать именно её. При меньшей разнице в цене выгоды становится ещё больше. Но у нас разрыв в цене сильно меньше, поэтому такие ВМ заметно выгоднее.
Ядра процессоров Cascade Lake демонстрируют прирост производительности не только за счёт увеличенной частоты, но и более современной архитектуры. При этом разные модели процессоров из этой линейки дают разные результаты, что нужно обязательно учитывать при решении своей задачи.
В облаке мы планируем использовать эти процессоры в режиме Turbo Boost, при котором тактовая частота процессора достигает 4,40 ГГц, что увеличит его отрыв по производительности и сделает выбор в пользу этого продукта ещё более очевидным.
Что это значит для нас
Мы долгое время жили в старой парадигме, когда у одного процессора было не очень много ядер, и поэтому на один сервер помещалось не очень много виртуальных машин. Приходилось много приседать, чтобы добиться хоть какой-то оптимальности по плотной укладке ВМ в эти серверы. Теперь, когда на один сокет получаем по 28 или даже 56 ядер, проблема с плотностью укладки решается почти сама собой. И у нас появляются ресурсы, чтобы подумать о других плюшках для заказчиков нашего Облака КРОК. Например, мы запилили отдельный пул с процессорами 6244 под СУБД.
Дополнительный бонус — всё это оказалось очень подходящей архитектурой для 1С. Смысл в том, что если переходить от процессора частоты 3 ГГц к процессору 4 ГГц, то почти все тесты дают тебе не +30 %, а +15–20 %… А эта штука даёт тебе +45 %. То есть частота увеличивается на 30 %, а прирост растёт нелинейно к частоте. А процессоры дороже процентов на 40. В итоге новые процессоры дороже, но наконец 1С начинает работать нормально. Можно идти в облако, не беспокоясь, что там не те процессоры. Для многих наших клиентов сейчас это очень важно.
А давайте поговорим про синтетические тесты? Мы заметили, что часть клиентов использует их, оценивая «профпригодность» любого облачного решения. Иногда нас просят предоставить результаты какого-либо теста или сами проверяют систему во время бесплатного пробного периода. Причём то же нагрузочное тестирование проводят редко. В фаворитах — тест Гилева. Про него-то мы и расскажем. Ведь если и делать подобный тест, то делать его нужно правильно.
Введение
Стоит понимать, что тест Гилева никак не отражает быстродействие реальной конфигурации с реальной базой данных. Он запускается на пустой платформе без установки каких-либо конфигураций и тем более загрузки реальных баз 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
На рис.10 представлены результаты теста Гилева для раздельной архитектуры (отдельный сервер СУБД). Обратите внимание, тест никак не учитывает в однопоточном тесте конфигурацию сервера СУБД, учитывается только конфигурация сервера, где развёрнута платформа «1С:Предприятие». В целом, производительность в тесте Гилева у раздельной архитектуры несколько ниже, чем у совместной, поскольку используется протокол tcp вместо более быстрого протокола shared memory.
Влияние нагруженности кластера и выделения ресурсов
Рис. 11
На рис. 11 представлены результаты теста Гилева на виртуальной машине, расположенной на изолированном от основного кластера хосте. Результаты существенно выше предыдущих, поскольку все ресурсы хоста гарантированно предоставляются единственной виртуальной машине.
Рис. 12
На рис. 12 представлены результаты теста в общем кластере с включенными политиками гарантированного предоставления ресурсов. Как вы видите, результат существенно ниже, чем на изолированном хосте.
Итоги исследований
На результаты теста наибольшее влияние имеют отключение всех возможных технологий энергосбережения в гостевой операционной системе и базовая частота виртуального процессора
Нагруженность кластера, в котором работает виртуальная машина, может существенно влиять на результат теста Гилева
Совмещённая архитектура даёт более высокие результаты по сравнению с раздельной за счёт использования более быстрого протокола shared memory. Однако, при использовании такой архитектуры нужно внимательно следить за ресурсами, потребляемыми отдельными компонентами системы, чтобы избежать конкуренции
Надеюсь, эта информация будет вам полезна. И помните, что одними лишь синтетическими тестами руководствоваться не стоит. Обращаем ваше внимание на тот факт, что мы проводили тест Гилева по 1С в виртуальной среде на не очень мощных процессорах. В будущем можно будет провести исследование на новом железе. Интересно?
Что ещё интересного есть в блоге Cloud4Y
Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу.
Читайте также: