# Виртуализация, 1С и кривые руки * **Виртуализация применительно к разному ПО, в том числе и к 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* Причина такого совета абсолютно не понятна. 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) На Hyper-V кстати то же самое. *Отключить дедупликацию памяти для EXSi - Transparent Page Sharing на хосте VMware ESXi* Не надо нагружать хост так, чтобы там включались ухищрения с памятью. И аккуратней с переподпиской. Transparent Page Sharing при этом – не самая большая беда. Вот когда все начинает в своп валиться – это да. Опять же, есть тексты про Understanding Memory Resource Management in VMware ESX Server и про Memory Ballooning При этом на самом сайте Гилева – ругают Кухара Богдана (хотя, казалось бы – Кумары/Кухаря живут чуть-чуть юго-восточней, в огромном количестве, ЕВПОЧЯ). На все вышеперечисленное накладываются унаследованные привычки «а давайте возьмем сервер побольше», выражающиеся в заявках от отдела 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 гГц Intel® Xeon® Gold 5222 Processor - 4 ядра, 3.8 гГц Было бы неплохо перейти от теории к практике, и проверить эти рассуждения на практике, сначала на тестовой среде / нагрузочном тестировании при настройках «искаропки», потом в донастроенном окружении, как физическом, так и виртуальном, и при разном физическом окружении – серверном/десктопном. Но пока что такого тестирования я не видел. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://krw.gitbook.io/cb19/virtualizaciya/obshie-problemy-krivykh-ruk.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.