Виртуализация, 1С и кривые руки
Last updated
Was this helpful?
Last updated
Was this helpful?
Виртуализация применительно к разному ПО, в том числе и к 1С.
Проблемы многопоточности и vCPU scheduler применительно к данному (1с) ПО.
Как следствие - Проблемы с тестом Гилева (1c) в виртуальной среде.
Проблемы криворуких специалистов по настройке и тюнинху(ТМ) его же.
Надо понимать, что современное ПО для виртуализации является достаточно сложным, в том числе по причине необходимости обеспечения очередей задач на процессоре, повышения и понижения приоритета исполнения задач, синхронности их исполнения в случае многопроцессорности (а где вы сейчас одноядерные процессоры видели?), и много чего еще – о чем рассказывают в выше упомянутых Data Center Virtualization Fundamentals [V6]
VMware vSphere: Install, Configure, Manage [V6]
При этом часть ПО просто не умеет параллелиться, и как результат – исполняется в один поток. Наиболее часто проблемы с этим возникают у 1С 8.2, и частично у 1С 8.3. Разрабатываемая 1С 8.4, может быть, не будет иметь таких проблем – но не факт.
С другой стороны проблемы есть так называемый тест Гилева – это фамилие такое. Само наличие этого теста – это хорошо, можно посмотреть относительных попугаев. С другой стороны однопроцессорный однопоточный тест показывает ровно то самое, чего и должен показывать – процессор Core i5 (даже не i7) плюс память без REG/ECC с частотой 2.7 – выигрывает у Xeon 2.3 и памяти Reg+ECC – каковая память работает еще и с меньшей частотой. Причем выигрыш по этому тесту может быть раза в 2-3 – например, можно получить 20 баллов на сервере и 40 на рядовом рабочем ПК.
С третьей стороны есть лютая дичь на самом сайте 1С – например: На многопроцессорных системах на одном сервере должно работать больше одного процесса rphost .. Поэтому при работе на многопроцессорных системах (все современные многопроцессорные системы Intel и AMD имеют NUMA архитектуру), в зависимости от характера нагрузки, может наблюдаться неравномерная загрузка процессоров/ядер. В некоторых случаях может оказаться загружена только какая-то часть доступных ядер CPU, при этом другая часть будет простаивать.
Конечно будет – NUMA не занимается разбросом на «только ядра», хотя о этом надо писать отдельно, а к тому как эта Numa будет выглядеть после Esxi уже в гостевой ОС - надо подступать только после серьезного расширения сознания знакомства с теорией и практикой работы вверенной материальной части.
С четвертой стороны есть рекомендации того же Гилева, которые местами оправданы, местами – такая же лютая дичь, как и у оптимизаторов, которых он ругает. Примеры дичи –
«Снимки» надо выключать — они замедляют.
не надо их "выключать" - на них как бы работает резервное копирование VM. Так что выключить их не выйдет. Другое дело, что в ряде случаев хранить N-цать снимков не нужно.
Использовать только физические диски под данные, а не виртуальные.
Совет потрясающий своей прямизной. Для начала, в нормальной среде (а не домашней машине, на Vmware WS - куда стоит ссылка) - на хосте ВООБЩЕ может не быть своих дисков - все лежит на СХД. Пусть даже пусть есть - предлагается что, тащить с хоста физический диск (без raid) в виртуалку и там собирать RAID средствами винды? RLY? Если с СХД - это как? В Vmware протаскивать диск с хранилки и отдавать его опять же как физику? Так не будет, будет какой-то Raid на СХД, который отдается LUN-ом в ту же Vmmare, откуда уже нарезается на тома VMFS. Другое дело, что конечно лучше бы все это дело мониторить по нагрузке - может там на массив очередь на минуту и все уже давно лежит, и tempdb хранить как-то отдельно.
Конечно, можно сделать VSAN или завести Nutanix, или еще какое data locality, но это и сложно и дорого.
Вендоры виртуальных систем честно указывают примерный процент замедления относительно физических серверов от 9 до 24 % Сильно меньше и когда как. Процент замедления / штраф / накладные расходы на виртуализацию конечно есть, но зависят от процессора "в целом", количества io операций по сети/диску, и прочая прочая. Но может оказаться и больше – На практике я получал падение производительности вплоть до 40% от номинала из-за влияния гиперактивного ввода-вывода виртуальной машины по сети и дисковой системе.
Передача по сети между двумя виртуальными машинами на одной физической машине медленней протокола Shared Memory
Медленней ли ... Тут особо не поспорить – кроме как с терминологией. Shared Memory не «быстрее», а имеет меньшую латентность, да и в случае двух VM на одном хосте данные все равно идут через память. НО 99% 1сников не умеют в 9k/ MTU 9000/Jumbo frame. Дело в размере блока, которым SQL оперирует - он, как ни странно, не равен 1514 байт, поэтому при TCP/IP много чего фрагментится и кадр 9к желателен крайне для SQL и его клиента
И это еще вопрос – а что будет при использовании RDMA или InfiniBand?
Для виртуальных серверов ESXi 6.0 с 1с сервером не используйте сетевые интерфейсы типа WMXNET3, использовать только типа e1000e
На Hyper-V кстати то же самое.
Отключить дедупликацию памяти для EXSi - Transparent Page Sharing на хосте VMware ESXi
На все вышеперечисленное накладываются унаследованные привычки «а давайте возьмем сервер побольше», выражающиеся в заявках от отдела 1С – «дайте в виртуалку больше процессоров». Ок, не жалко – только не поможет, а в некоторых случаях скорее повредит. Конечно, MS SQL отлично работает в многопроцессорной среде – чего нельзя сказать про 8.2 / 8.3 «в общем случае». Опять же, хороший 1С –ник стоит ДОРАГА, хороший варе/гитлеро вед – аналогично ДОРАГА, а в наличии хороших Xen/Openstack – водов в количестве больше 20 (просто двадцати) в РФ я не уверен. Именно хороших – админов локалхоста под линуксом плюс минус половина от всех админов локалхоста с 60% побед. Такие заявки приводят к добавлению в виртуалку 20-40 процессоров, и внезапной просадке производительности «еще больше». Следующим шагом выступает «а отдайте все что есть на хосте», плавно переходящее «ваше * говно тормозящее, только винда, никакой виртуализации». Окей, но результаты тоже не начинают мгновенно поражать воображение – хотя если взять не сервер, а десктоп с Core i7-7700 (3.6) / Core i7-7700K (4.2) или сервер с Intel® Xeon® Processor E5-1630 v4 / Intel® Xeon® Processor E5-1650 v4 и включить Turbo Boost (3.7/4) – то может оказаться и неплохо. Но на них и виртуализированная среда бы работала куда быстрей – особенно если выключить энергосбережение везде, включить Turbo Boost и подстроить NUMA.
Процессоры на момент написания текста -
Intel® Xeon® Processor E5-1630 v4 / E5-1650
На 2020 год можно посмотреть в сторону:
Intel® Xeon® Gold 6226R Processor - 16 ядер, 2.9 гГц
Intel® Xeon® Gold 6234 Processor - 8 ядер, 3.3 гГц
Было бы неплохо перейти от теории к практике, и проверить эти рассуждения на практике, сначала на тестовой среде / нагрузочном тестировании при настройках «искаропки», потом в донастроенном окружении, как физическом, так и виртуальном, и при разном физическом окружении – серверном/десктопном. Но пока что такого тестирования я не видел.
Причина такого совета абсолютно не понятна. WMXNET3 - виртуальная (как и e1000e кстати) сетевая карта 10G, с оптимизацией под работу Vmware. Может кто-то прочитал про проблемы с VM Chimney (TSO - TCP Offload) и RSS (Receive Side Scaling) с точностью до наоборот – там надо бы выкинуть e1000e и провести прочее колдунство.
Poor network performance or high network latency on Windows virtual machines (2008925) TSO (TCP Segmentation Offload) /Receive Side Scaling (RSS)
Understanding TCP Segmentation Offload (TSO) and Large Receive Offload (LRO) in a VMware environment (2055140)
Не надо нагружать хост так, чтобы там включались ухищрения с памятью. И аккуратней с переподпиской. Transparent Page Sharing при этом – не самая большая беда. Вот когда все начинает в своп валиться – это да. Опять же, есть тексты про Understanding Memory Resource Management in VMware ESX Server и про Memory Ballooning
При этом на самом сайте Гилева – ругают Кухара Богдана (хотя, казалось бы – Кумары/Кухаря живут чуть-чуть юго-восточней, в огромном количестве, ЕВПОЧЯ).
Intel® Xeon® Gold 5222 Processor - 4 ядра, 3.8 гГц