1С + MS SQL против Матрицы виртуализации

30.06.22

Интеграция - Облачные сервисы, хостинг

–

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

Скачать исходный код

	Наименование	Файл	Версия	Размер
	Скрипт для сбора статистики .sql 10,18Kb 17	.sql		10,18Kb	17	Скачать бесплатно
	Скрипт статистики по spin lock .sql 2,36Kb 15	.sql		2,36Kb	15	Скачать бесплатно

1С + MS SQL против Матрицы виртуализации.

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

Нассим Талеб

«Время всегда против нас».

Весна 2020 года была очень активной на фондовых рынках, количество сделок в некоторые дни вырастало в 2 раза от нормы, закрытие дня в финансовом учете было близко к предельным срокам. Клиенты боролись с Черным Лебедем Covid-19 по всем фронтам. К этому моменту конфигурация уже 7 лет работала на одном и том же оборудовании, которое было заложено с запасом под горизонтальное маштабирование. Даже то горизонтальное масштабирование, которое можно сделать в 1С (см статью //infostart.ru/1c/articles/1683197/ ) позволяет решать проблемы роста объемов оборудованием, и вот настал тот момент когда уже пора расширять оборудование. Случайное совпадение - наши системные администраторы предложили попробовать новый виртуальный кластер, который недавно развернули в компании. Кластер на основе VMWare. Перспективы были заманчивые, вместо покупки новых серверов, отдельных дисковых хранилищ, обоснований бюджета – создаются виртуальные машины с нужными параметрами, а в бюджет аллоцируются расходы из общего пула. Будущее рисует нам картины, когда системный администратор скоро не сможет потрогать сервер рукой, и будет видеть только операционную систему и прайс лист за использование J от провайдера. Однако виртуальная реальность оказалась не такой радужной.

Мне выделили контур с примерно таким же числом ядер, памяти как на рабочем. Версии программ и операционной системы поставили идентичные, настройки тоже. Параметры оборудования по виртуализацию были лучше, но не сильно ведь гонка тактовых частот заканчивается по физическим ограничениям. Запустил перерасчет за месяц с распараллеливанием… и ушел спать.

«Что есть реальность?» В виртуальной среде

Утром первым делом посмотрел на результаты, они были странные – замедление 60% на виртуальном кластере. Даже ФИФО который параллелится только по бумагам и не создает большой нагрузки, посчитался медленней на 30%

Хорошо, что мне есть с чем сравнивать, и я могу просто сказать «А вот на железном кластере с той же конфигурацией гораздо быстрее» или сравнить счетчики MS SQL на быстром и медленном кластере. Но допустим, кому то дали облако под проект с якобы заявленными параметрами, как ему понять что кластер (1С MSSQL Hardware) работает на полную мощность?

Тут можно обратится к принципу непротиворечивости логичной системы аксиом. В логике предикатов http://mathhelpplanet.com/static.php?p=svoystva-aksiomaticheskikh-teoriy это изложено детально, но по простому можно сказать: Вы можете построить любую систему аксиом для своей алгебры, геометрии, теории множеств – важно чтобы она была непротиворечивой при выводе теорем и утверждений. Там, где есть противоречие 2 варианта либо система аксиом плоха, либо вы что-то не знаете и не учитываете и именно там истина. Математика, физические постоянные существуют в мире не просто так любые противоречия разрушили бы вселенную. Напр путешествие во времени назад вызывает кучу противоречий, значит оно невозможно, а вот в будущее без возврата в прошлое вполне возможно.

Значит решено - снимаем показатели и ищем противоречия. ИТ технологии сложны, но это гораздо проще тензорного исчисления J . Производительность какого-то компонента кластера снижается по одной из трех причин.

Ресурс перегружен, это сразу видно на счетчиках производительности
Ресурс частично свободен, но ждет снятия какой-то блокировки (Это может быть блокировка строк в СУБД, ресурсов памяти Latch, и т.д.)
Ресурс частично свободен, но у него скопилась очередь (Это может быть очередь к дисковой системе, минимально необходимые задержки на передачу пакета по сети)

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

Настроил счетчики, я не будут описывать нужные - так как в разных ситуациях нужно искать разные. Принцип простой – из всех счетчиков ищите счетчики очередей, ожиданий, миллисекунд на трансфер. Счетчики на % загрузки как правило не дают сделать выводы напр. Передача по сети множества мелких пакетов не создает 100% траффика, но за счет задержек сети упирается в потолок производительности (см мою старую статью на эту тему http://selis76.narod.ru/matnetw1.html#bookmark1 )

Для оборудования настроил Perfomance Monitor с записью, то что называется Data collection set. Странно, но оно работало только после перезагрузки сервера.

Для SQL Server сбросил счетчики статистики и кэши

DBCC SQLPERF("sys.dm_os_wait_stats",CLEAR);

DBCC FREEPROCCACHE ;

DBCC DROPCLEANBUFFERS;

Анализ перегруженности ресурсов не показал ничего критичного

На кластере 1С за счет горизонтального масштабирования загрузка плотная, больше 50% (что считается с точки зрения Microsoft значительной нагрузкой)

Небольшая странность, бывают очереди на процессор (Processor queue length).

На сервере базы данных нагрузка небольшая, значит можно увеличить еще, но видны противоречия

Видны всплески очередей на диск (Current disk queue length больше 100), когда активность превышает 10 тыс IOPS . Причем видно что очередь держится по несколько секунд. Это странно, ведь SSD должен переваривать такой траффик легко.

Попросил администраторов проверить со стороны гипервизора, получил ответ

«В данной конфигурации Ваш виртуальный сервер может спокойно потреблять до 50k iops при минимальном latency. Разумеется, если от него этого требуют.

На Ваших графиках видно, что нагрузка почти нулевая с периодическими кратковременными скачками. Я посмотрел - в эти пиковые моменты сервер потреблял всего до 20k iops. Latency в эти моменты достигала 15-20 мс, что безусловно не мало, но и не катастрофично, учитывая, что эти всплески длятся доли секунды.

Latency растет, т.к. Вы периодически упираетесь в одно единственно ограничение - одновременное количество потоков данных от виртуального сервера к дисковой системе (максимум 64) в текущей конфигурации.

Параметр queue lentgh и все его производные имеет смысл рассматривать только на однодисковых десктопах. На серверах и в виртуализации он не показывает абсолютно ничего. »

Вот первый звоночек оказывается VMWare ограничивает одновременное количество потоков данных от сервера к дисковой подсистеме, неужели придется еще VWWare изучать J чтобы знать ее узкие места. Про очереди не согласен, если они возникают значит что-то не так. А так «Все хорошо прекрасная маркиза, все хорошо, все хорошо»

«Если бы ты не мог проснуться, как бы ты узнал, что сон, а что действительность?»

Очень просто – надо так пошалить в системе, что бы агент Смит мигом прибежал успокаивать прозревающего Нео и попытаться уложить его в кроватку. В ИТ это называется стресс тест , у водопроводчиков опрессовка. Если хотите проверить качество работы сантехника, пригласите опрессовщика, он создаст избыточное давление и все недоработки потоком польются вам на пол.

Горизонтальное масштабирование позволяет легко увеличить количество параллельных процессов обработки и тем самым увеличить нагрузку. Поэтому свой тест я запускал увеличив количество параллельных процессов обработки с 40 до 60, если % загрузки не дают внятного ответа, смотрим анализ ожиданий

Результаты интересные, ожидание на логгирование Transaction log вылезло в топ, да еще Memory waits https://www.sqlskills.com/help/waits/resource_semaphore/ появились .

Еще сетевые задержки между кластером 1С и СУБД великоваты https://www.sqlskills.com/help/waits/async_network_io/ они действительно отличались от продуктивного контура, если применить анализ задержек через hrping. Это исправили, результат улучшился, но не существенно для текущей проблемы

На продуктивном сервере топ ожиданий совсем другой, скажем так логичный – больше ждешь записи\чтения в базу нежели transaction log и памяти

Далее смотрим детально ожидания на Transaction log он находится на отдельном SSD диске, но там нет проблем с производительностью дисковой системы.

Администраторы мне это подтвердили

«На графике ниже 3 параметра: lock wait, log write wait, disk latency.

Хорошо видно, что несмотря на высокий уровень Log write waits, запись данных на диск происходит с приемлемой latency. Следовательно, проблема тут не в дисках.

Решение проблем с задержками сети улучшило результат до 1233 мин против 1492, но это не 937 мин на рабочем.

Анонс. Анализ сетевых задержек это отдельная тема. В устаревшем варианте есть моя статья http://selis76.narod.ru/matnetw1.html#bookmark1 , но ее можно уже обновить, учитывая новые кейсы.

«Часть меня чувствует, будто я всю жизнь ждала тебя.» Ожидания наше все.

Если отбросить диск, то анализ задержек на уровне процессор память наиболее сложная тема, поскольку это уже нужно лезть в анализ процессов операционной системы и с пониманием использовать ProcessExplorer https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer . Многоядерность, Numa nodes усложняют задачу. Я уже подошел к моменту, когда анализ счетчиков увеличивает глубину НЕ знания, поскольку даже внутри кластера видно, что для tempdb при сопоставимых объемах записи, таких проблем нет, а для базы СУБД есть. Интуитивно было понятно что, что-то не так с виртуальными ядрами, Numa nodes, а не с реальным железом

Если есть теория, значит, нужно искать ей подтверждение! Ок Google?

Не помню, какой правильно был сформулированный вопрос, который содержит половину ответа, но я нашел эту статью про spinlock в MS SQL

https://chrisadkin.io/2015/09/09/tuning-the-logcache_access-spinlock-on-a-big-box/

Тема сложная, поскольку это уже системная архитектура СУБД, до которой не каждый SQL администратор доберется, а Эксперт по технологическим вопросам 1С вообще не должен столкнуться с подобным, учитывая проблемы 1С горизонтальным масштабированием, см. тут //infostart.ru/1c/articles/1683197/ . Приведу лишь несколько цитат для понимания

«Spinlocks are lightweight synchronization primitives which are used to protect access to data structures. Spinlocks are not unique to SQL Server. They are generally used when it is expected that access to a given data structure will need to be held for a very short period of time. When a thread attempting to acquire a spinlock is unable to obtain access it executes in a loop periodically checking to determine if the resource is available instead of immediately yielding. After some period of time a thread waiting on a spinlock will yield before it is able to acquire the resource in order to allow other threads running on the same CPU to execute. This is known as a backoff and will be discussed in more depth later in this paper.

SQL Server utilizes spinlocks to protect access to some of its internal data structures. These are used within the engine to serialize access to certain data structures in a similar fashion to latches. The main difference between a latch and a spinlock is the fact that spinlocks will spin (execute a loop) for a period of time checking for availability of a data structure while a thread attempting to acquire access to a structure protected by a latch will immediately yield if the resource is not available. Yielding requires context switching of a thread off the CPU so that another thread can execute. This is a relatively expensive operation and for resources that are held for a very short duration it is more efficient overall to allow a thread to execute in a loop periodically checking for availability of the resource.»

Проще говоря это блокировки для структур памяти, которые работают по принципу циклического ожидания.

«Ты всю жизнь ощущал, что мир не в порядке. Странная мысль, но её не отогнать. Она — как заноза в мозгу. Она сводит с ума, не даёт покоя. Это и привело тебя ко мне...» Морфеус

Предположил, что проблема в физическом распределении по Numa Node потоков MS SQL, которое влечет задержки при доступе к памяти (ведь spinlock это структуры памяти) , видимо на физическом уровне WriteLog висит на тех же ядрах что и другие потоки MS SQL и Numa Nodes фактически не работают. С приходом многоядерности требуется внимательно смотреть на загрузку отдельных ядер, ведь там может висеть процесс или поток, который становится узким местом для всей системы.

Классический пример из 1С – rmanager со всеми сервисами висит на одном ядре, если он управляет 40 рабочими процессами, загрузка этого ядра на 100% уже влияет на всю систему самым отрицательным образом. Поэтому в 8.3 есть флажок «Менеджер под каждый сервис», а в 8.2 нужно сделать несколько менеджеров кластера и распределить по ним сервисы.

Ложки не существует. Что не так с ядрами виртуальной машины?

— Не пытайся согнуть ложку. Это невозможно. Для начала нужно понять главное.

— Что главное?

— Ложки не существует.

— Не существует?

— Знаешь, это не ложка гнётся. Всё — обман. Дело в тебе.

С какими ядрами работает SQL Server можно увидеть в Affinity mask логе SQL Server

Вот что было на виртуальном кластере

А это на рабочем

Почувствовали разницу? SQL сервер по другому видит и Numa node и количество ядер. Хотя там все одинаково с точки зрения количества

Что такое Numa node, хорошо объяснено тут

https://docs.microsoft.com/en-us/previous-versions/sql/sql-server-2008-r2/ms178144(v=sql.105)

«Each group of processors has its own memory and possibly its own I/O channels. However, each CPU can access memory associated with the other groups in a coherent way. Each group is called a NUMA node. The number of CPUs within a NUMA node depends on the hardware vendor. It is faster to access local memory than the memory associated with other NUMA nodes»

Дальше все становится понятным - SQL Server не будет есть виртуальную … . Любая виртуальная … приведет к самым экзотическим эффектам в производительности. Выход один – выровнять виртуальную машину с физической. В VMWare такое возможно, с другой стороны, а зачем она нам вообще тогда нужна J . Все варианты например: дадим половину реальной машины или 2 реальных машины объединенных в одну приведут к непредсказуемым эффектам в производительности

Проверка через CoreInfo показала такое распределение ядер на виртуальном сервере

Logical to Physical Processor Map:

*----------------------- Physical Processor 0

-*---------------------- Physical Processor 1

--*--------------------- Physical Processor 2

---*-------------------- Physical Processor 3

----*------------------- Physical Processor 4

-----*------------------ Physical Processor 5

------*----------------- Physical Processor 6

-------*---------------- Physical Processor 7

--------*--------------- Physical Processor 8

---------*-------------- Physical Processor 9

----------*------------- Physical Processor 10

-----------*------------ Physical Processor 11

------------*----------- Physical Processor 12

-------------*---------- Physical Processor 13

--------------*--------- Physical Processor 14

---------------*-------- Physical Processor 15

----------------*------- Physical Processor 16

-----------------*------ Physical Processor 17

------------------*----- Physical Processor 18

-------------------*---- Physical Processor 19

--------------------*--- Physical Processor 20

---------------------*-- Physical Processor 21

----------------------*- Physical Processor 22

-----------------------* Physical Processor 23

Logical Processor to Socket Map:

*----------------------- Socket 0

-*---------------------- Socket 1

--*--------------------- Socket 2

---*-------------------- Socket 3

----*------------------- Socket 4

-----*------------------ Socket 5

------*----------------- Socket 6

-------*---------------- Socket 7

--------*--------------- Socket 8

---------*-------------- Socket 9

----------*------------- Socket 10

-----------*------------ Socket 11

------------*----------- Socket 12

-------------*---------- Socket 13

--------------*--------- Socket 14

---------------*-------- Socket 15

----------------*------- Socket 16

-----------------*------ Socket 17

------------------*----- Socket 18

-------------------*---- Socket 19

--------------------*--- Socket 20

---------------------*-- Socket 21

----------------------*- Socket 22

-----------------------* Socket 23

Logical Processor to NUMA Node Map:

************------------ NUMA Node 0

------------************ NUMA Node 1

Approximate Cross-NUMA Node Access Cost (relative to fastest):

00 01

00: 1.0 1.2

01: 1.2 1.1

На рабочем сервере

Logical to Physical Processor Map:

**------------------------------ Physical Processor 0 (Hyperthreaded)

--**---------------------------- Physical Processor 1 (Hyperthreaded)

----**-------------------------- Physical Processor 2 (Hyperthreaded)

------**------------------------ Physical Processor 3 (Hyperthreaded)

--------**---------------------- Physical Processor 4 (Hyperthreaded)

----------**-------------------- Physical Processor 5 (Hyperthreaded)

------------**------------------ Physical Processor 6 (Hyperthreaded)

--------------**---------------- Physical Processor 7 (Hyperthreaded)

----------------**-------------- Physical Processor 8 (Hyperthreaded)

------------------**------------ Physical Processor 9 (Hyperthreaded)

--------------------**---------- Physical Processor 10 (Hyperthreaded)

----------------------**-------- Physical Processor 11 (Hyperthreaded)

------------------------**------ Physical Processor 12 (Hyperthreaded)

--------------------------**---- Physical Processor 13 (Hyperthreaded)

----------------------------**-- Physical Processor 14 (Hyperthreaded)

------------------------------** Physical Processor 15 (Hyperthreaded)

Logical Processor to Socket Map:

****************---------------- Socket 0

----------------**************** Socket 1

Logical Processor to NUMA Node Map:

****************---------------- NUMA Node 0

----------------**************** NUMA Node 1

Approximate Cross-NUMA Node Access Cost (relative to fastest):

00 01

00: 1.0 1.3

01: 1.5 1.0

Разница понятна. На виртуальном якобы физические сокеты 24 шт, а на рабочем сервере 2 сокета и 32 ядра Hyperthread

Прошу администраторов выровнять виртуальные машины по физическим на SQL сервере и кластере 1С, запускаю тест повторно. Урааа 1162 минуты против 937 это еще не победа, вообще результат должен быть лучше все-таки оборудование более новое. Но направление борьбы с Матрицей понятно – нужно везде разоблачать виртуальные ресурсы и отображать их на реальные физические один к одному. Зачем на тогда Матрица? Для белых воротничков, которые сидят в браузере и Word, для малого бизнеса которому лишние железки только лишняя нагрузка, а в браузере он выглядит даже средним бизнесом, менеджерам для экономии - кому угодно только не тем кому нужна реальная производительность.

Кто-то скажет: Вы не умеете готовить виртуальную среду?

Я отвечу: Я что - шеф повару должен объяснять как ему готовить? Да ну такой ресторан, лучше сделать свой.

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

Забегая вперед могу сказать, что равной производительности (и даже большей) на виртуальном кластере мы достигли, в следующей серии Матрицы

Как изменились счетчики после выравнивания виртуальной машины можно посмотреть ниже.

Скрипты для запросов с источниками происхождения я прилагаю.

На тестовом кластере зафиксировано до оптимизаций

После выравнивания виртуальных машин с физическими сокетами и ядрами картина резко улучшилась

Задержка по Writelog сократилась в два раза.

Как работает spinlock описано выше, но нам сейчас важно понимать, что при коллизии доступа к logbuffer значение spin увеличивается циклически пока другой поток не отпустит ресурс. Т.е чем выше значение spins_per_collision тем хуже работает связка процессор

У нас – они уменьшились на logflushq, но увеличились на logcashe_access – последнее считается признаком более интенсивной работой writelog . Замечу что на рабочем кластере статистика еще лучше, но там повышенную нагрузку не давали при измерениях. О том, что еще влияло на производительность виртуального кластера – в следующей статье. Первыми статьи появляются на нашем канале t.me/Chat1CUnlimited + дополнительная информация

«Я не сказал, что будет легко. Я лишь обещал открыть правду.» Морфеус

Виртуализация Облака VMWare Производительность

–

См. также

Интеграция 1С с облаком S3 (Amazon, Yandex Object Storage, Ceph Object Gateway S3, MinIO и др.)

Облачные сервисы, хостинг 8.3.14 Конфигурации 1cv8 Россия Платные (руб)

Готовое решение по интеграции 1С с облаком S3 (Amazon, Yandex Object Storage, Ceph Object Gateway S3, MinIO и любое совместимое объектное хранилище). Решение даёт возможность осуществлять как основные операции (получить список, закачать, скачать, удалить и т.д.), так и расширенные (работа с бакетами, генерация ссылок, работа с правами и т.д.) с объектным хранилищем S3 прямо из 1С.

31200 руб.

27.04.2021 18537 24 70

Облачная АТС Билайн - интеграция с 1С

Управление взаимоотношениями с клиентами (CRM) Телефония, SIP Облачные сервисы, хостинг Платформа 1С v8.3 Конфигурации 1cv8 Управленческий учет Платные (руб)

Продукт интеграции возможностей Облачной АТС Билайн в систему 1С Предприятие 8. Звонки прямо из программы 1С, уведомления о текущих звонках, регистрация пропущенных и завершенных вызовов, ведение журнала, анализ данных об использовании мобильной связи.

12000 руб.

20.03.2019 22372 52 0

В облако на работу: Все варианты авторизации ОС сервером 1С на базе РЕД ОС 8 в домене windows. Рецепты от Капитана

Облачные сервисы, хостинг Linux Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

В публикации рассматриваются все варианты авторизации ОС сервером 1С на базе РЕД ОС 8 в домене windows. Как случаи, когда сервер 1С авторизирует веб и обычных клиентов 1С в active directory, так и когда сам сервер является клиентом, например при HTTP запросах выполняемых сервером 1С.

18.03.2024 526 capitan 0

Готовое облако или выделенный сервер? Экономика владения 1С

Облачные сервисы, хостинг Бесплатно (free)

Если вы работаете с 1С, то, скорее всего, используете для этого собственный сервер. Это решение дает больше гибкости: железо всегда под рукой, в любой момент можно поменять конфигурацию или установить дополнительное ПО. Например, чтобы организовать бухгалтеру удаленный рабочий стол. Но насколько этот вариант экономически выгоден для компании? Мы сравнили три варианта развертывания 1С: на собственном сервере, на арендованном в Selectel и в готовом облаке. Какие есть преимущества и недостатки у каждого варианта и что выгоднее — разбираем в статье.

13.03.2024 596 doctor_it 6

Три пингвина под окном… Точки над Ё. Обзор рабочих мест пользователя 1С, собранных на отечественных дистрибутивах linux

Облачные сервисы, хостинг Linux Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Прошлая публикация "Три пингвина под окном… Обзор рабочих мест пользователя 1С, собранных на отечественных дистрибутивах linux" набрала более 20К просмотров. В моем случае это абсолютный рекорд. Как и обещал в ней, рассказываю, как установить неподдерживаемый дистрибутив ОС у облачного провайдера.

25.02.2024 2231 capitan 0

Бесплатный митап “1С в облаке: возможности и риски, решения и кейсы”

Облачные сервисы, хостинг Мероприятия Бесплатно (free)

На митапе говорили о переносе 1С в облако: какие решения есть на рынке, их достоинства и недостатки. На примере реальных кейсов узнали особенности перехода, сроки, бюджеты, риски и возможности. В программе митапа 5 докладов и круглый стол.

06.02.2024 2872 0 Infostart 0

Из 1С в S3 и обратно. Работа с объектным хранилищем

Облачные сервисы, хостинг Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

В данной статье демонстрируется работа с объектным хранилищем 1С с использованием подписанных (pre-signed) ссылок. Загрузка, скачивание и удаление реализованы на "чистом" языке 1С без внешних компонент и сервисов. В качестве провайдера хранилища S3 будем использовать Яндекс.Облако

06.02.2024 4279 Sedaiko 13

В облаке, как дома: Устраиваемся поудобнее. Рабочее место пользователя 1С на базе РЕД ОС (HTTPS и архивирование)

Linux Облачные сервисы, хостинг Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

На прошедшем вебинаре "В облаке, как дома: Как настроить рабочее место пользователя 1С на базе РЕД ОС" мы договорились, что продолжением будет установка соединения по HTTPS и архивирование. Это финальные штрихи в настройке рабочего места. Вот и оно (продолжение) или они (штрихи), прошу под кат...

29.01.2024 773 capitan 5

Комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. starik-2005 3036 30.06.22 11:56 Сейчас в теме

Статья норм, но кое-где кое-что автор недогоняет. Например:

ведь spinlock это структуры памяти

Умные существа об этом пишут как-то так:

Спин-блокировки не задействуют планировщик и используют цикл активного ожидания без изменения состояния потока, что приводит к трате процессорного времени на ожидание освобождения блокировки другим потоком. Типовой реализацией спин-блокировки является простая циклическая проверка переменной спин-блокировки на доступность[1].

Т.е. спинлок-блокировка - это просто цикл по типу:

Пока Заблокировано Цикл
КонецЦикла;

Я об этих спин-блокировках писал лет пять (блин, уже семь) назад, когда предлагал реализацию мьютекса на 1С: https://infostart.ru/1c/articles/384485/ - там как раз файловая блокировка ожидается с помощью того самого спин-лока:

Функция СоздатьБлокировку(ИмяБлокировки, файлБлокировки)

  Попытка

    файлБлокировки = Новый ЗаписьТекста(КаталогВременныхФайлов() + ИмяБлокировки);
    Возврат Истина;

  Исключение

    Возврат Ложь

  КонецПопытки;

КонецФункции

Показать

Ну и дальше:

  файлБлокировки = Неопределено;
  Пока НЕ СоздатьБлокировку("ПечатьШтрихКода", файлБлокировки) Цикл
    // пустой цикл
  КонецЦикла;

  ПодключениеВыполнено = ПодключитьВнешнююКомпоненту("ОбщийМакет.КомпонентаПечатиШтрихкодов", "КартинкаШтрихкода", ТипВнешнейКомпоненты.Native);

  // убираем блокировку
  файлБлокировки.Закрыть();

Показать

2. 1CUnlimited 307 30.06.22 12:24 Сейчас в теме

Из системного программирования помню только семафоры https://en.wikipedia.org/wiki/Semaphore_(programming)
mutex как понимаю это частный случай. Я честно не углублялся в MS SQL на эту тему, поскольку тюнить spinlock SQL в планы не входило, а нужно было найти истинную причину проблемы. Вашу статью прочитал, проблема мне знакома и конечно хотелось бы иметь нетранзакционный объект для реализации mutex в 1С, но ихмо лучше написать внешнюю компоненту с идеальной реализацией, чем костыли с файлами.

3. starik-2005 3036 30.06.22 13:31 Сейчас в теме

(2)

но ихмо лучше написать внешнюю компоненту с идеальной реализацией, чем костыли с файлами

Файлы как раз реализуют быстрый спинлок, а мьютекс - я семь лет назад об этом был достаточно средне осведомлен - это блокировки процесса менеджером задач, т.е. они хоть и не потребляют ресурсы, но накладные расходы на разблокировку там достаточно большие. Ну и если в двух разных потоках вызвать две разные компоненты, реализующие мьютекс, то из-за отсутствия у них общего пространства памяти, сам по себе мьютекс будет не реализовать. Ну на мой взгляд, т.к. мьютекс - это тоже блокировка некоторой переменной (ячейки памяти).

4. triviumfan 93 04.07.22 15:59 Сейчас в теме

Читать жестоко - глаза сломаешь. Вроде 22 год на дворе, а такое оформление сводит весь труд на нет.

5. 1CUnlimited 307 06.07.22 00:13 Сейчас в теме

(4) Уточните - проблема с маштабированием картинок, или текста? Приведите ссылку на статью инфостарт где стиль оформления супер, я на нее сориентируюсь

6. triviumfan 93 06.07.22 10:08 Сейчас в теме

(5) Да и с текстом, и стилями, и картинками.. шрифт ужасный, заголовки, табуляция, картинки не центрированы...где-то вставка кода нужна, можно со спойлерами.
Откройте любую статью из топ100. Ну, для примера, статья Владимира Крючкова (ivanov660). Глазу приятно.

7. Gilev.Vyacheslav 1911 22.07.22 16:12 Сейчас в теме

" Перспективы были заманчивые, вместо покупки новых серверов, отдельных дисковых хранилищ, обоснований бюджета – создаются виртуальные машины с нужными параметрами, а в бюджет аллоцируются расходы из общего пула."
Это классическая ошибка всех дилетантов - думать что можно нарезать виртуальных ресурсов больше чем физических и от этого вдруг в природе добавиться больше мощностей.
https://www.youtube.com/watch?v=YaDch8h58E0

12. 1CUnlimited 307 22.07.22 20:38 Сейчас в теме

(7) Ну если поглядеть окончание https://infostart.ru/1c/articles/1695286/ истории
на самом деле можно было достичь эквивалентной производительности в нашем решении. И облако использовалось какое то время как резервный \ тестовый контур. Новый кластер купили через 1.5 года по одной причине - облако не позволяло маштабироваться увеличивать нагрузку. Т.е в принципе компромис возможен, а некоторые могут даже сэкономить на собственном ЦОД но это уже тема другой статьи

14. Gilev.Vyacheslav 1911 23.07.22 09:57 Сейчас в теме

(12)

облако не позволяло маштабироваться увеличивать нагрузку

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

8. Gilev.Vyacheslav 1911 22.07.22 16:15 Сейчас в теме

" как ему понять что кластер (1С MSSQL Hardware) работает на полную мощность "
" Даже ФИФО который параллелится только по бумагам и не создает большой нагрузки, посчитался медленней на 30%" - ещё одна фантазия, ибо производительность сервера определяется не загруженностью сервера, а способностью выполнить количество операций в единицу времени

10. 1CUnlimited 307 22.07.22 20:14 Сейчас в теме

(8)
Вячеслав, приятно видеть в обсуждении .
Я вроде эту фантазию не озвучивал, нагрузка с помощью горизонтального маштабирования это способ выявления мест где эти самые проблемы.
Ну для сравнения использовал рабочий кластер сходной архитектуры. Просто если эталона для сравнения нет или он сильно отличается как понять что виртуальная среда работает без явных Bottleneck? Наверняка встречались клиенты только облаком

15. Gilev.Vyacheslav 1911 23.07.22 10:02 Сейчас в теме

(10) про Амдала, если упростить, то до бесконечности увеличивать потоки вредит общему результату, собирание результатов становится слишком дорогим
искать узкие места в публичном облаке также нет смысла, потому что например ни кто вам не даст посмотреть как физически размещены планки памяти (извините но опять будет ссылка http://www.gilev.ru/ram/ ) , а если вы "всего не видите" как в примере, то в любом случае ваш максимум это констатировать наличие проблем, а не решить их
опять таки, в облаке клиенты-соседи мешают друг другу (вещь док смотреть с 12 минуты https://vk.com/video-132543994_456239017 )

9. Gilev.Vyacheslav 1911 22.07.22 16:21 Сейчас в теме

" я запускал увеличив количество параллельных процессов обработки с 40 до 60"
сразу две ошибки, во-первых есть Закон Амдала (да-да, учите матчасть), во-вторых чтобы нарезать потоки еще должны быть данные, которые в этих потоках будут могуть быть а) расчитаны параллельно б) время расчетов быть не сильно разным

даже перечисленных трех "ложных ориенторов" достаточно понять, что в по ним можно блуждать до бесконечности...

а можно было просто прочитать http://www.gilev.ru/virtual/#error

11. 1CUnlimited 307 22.07.22 20:30 Сейчас в теме

(9) А в чем мой конфликт с законом Амдаля , если я гонял закрытие периода на одних и тех же данных, но в разных условиях? Причем я знаю объемы и как они нарезаются алгоритмом.И даже есть с чем сравнивать. Моя задача была выявить узкие места в данной мне виртуальной среде.
Я понимаю что те кто анализирует проблемы с производительностью клиентов, почти никогда не могут жонглировать нагрузкой клиентского приложения так как для этого нужно иметь среду нагрузочного тестирования, которой нет у 99%. Единственный выход тащить свой нагрузочный тест на 1С. А если нагрузку не создать как увидеть места с Botteneck в виртуальной среде? Задержки не вылезут а будут размазаны по статистике
P S Ссылки сайта gilev сам иногда цитирую - полезная копилка кейсов.

13. Gilev.Vyacheslav 1911 23.07.22 09:55 Сейчас в теме

(11) понятно "ссылки не воспринимаются"

тогда вытащу оттуда сюда:

Ошибки выбора облаков
Выбор публичного облака вместо приватного

Любой провайдер не будет делать настройки под Вас в публичном облаке. Вы не сможете настроить BIOS под себя или отдать полную производительность сервера под свою виртуальную машину. Более того, ни один провайдер не признается, что соседняя виртуалка другого клиента оказывает негативное влияние на вашу виртуалку.
Для возможности настройки виртуальной среды выбирайте приватное облако и выполняйте настойку среды под себя, не расчитывайте на оптимальность дефолтовых настроек.

Недооценка значимости физического оборудования

В больших ЦОДах в том числе благодаря таким таким технологиям как HA или DRS (перемещающим виртуалку по разным физическим хостам) некоторые провайдеры даже не знают на каком физическом сервере с какими характеристиками находится виртальная машина. Физические сервера с разными характеристиками например частот процессоров будут выдавать разную общесистемную скорость внутри виртуальной машины.
При аренде виртуальной машины очень важно зафиксировать в договоренности конкретный сервер (или сервера включая резервный в случае мер отказоустойчивости).

Выбор того что есть в списке у провайдера вместо того что вам надо

Многие провайдеры предлагают в аренду неликвидные остатки, которые некуда приткнуть. Если к примеру для 1С:Предприятия важна в том числе частота процессора, а провайдер предлагает ТОЛЬКО многоядерный но слабочастотный процессор, то лучше вообще отказаться от такого провайдера и выбирайте клиентоориентированного провайдера, который сможет предоставить указанное вами железо под хост. Тоже самое касается провайдеров, которые не предоставляют NVMe диски, а только внешние системы хранения с sas|sata ssd — лучше отказаться от такого провайдера в пользу более клиентоориентированного. Если вы испытываете затруднение с формированием требований к железу, то используйте проверенный подбор оборудования.

Использование клиента 1С удаленно

Учитывайте, что запуск веб-клиента 1С или тонкого клиента 1С через интернет может быть эффективен только если вы специально сами адаптировали и протестировали код к скорости вашего интернет-канала. Типовые конфигурациии 1С на больших объемах данных (сотни гигабайт) не приспособлены к этому. Для комфортной работы используйте терминальный сервер, размещенный в том же сегменте сети где и сервер 1С у провайдера.

Использование виртуальной памяти больше чем физической или больше виртуальных ядер процессоров чем физически доступных

Многим админам кажется хорошей идеей экономить на оперативной памяти, указывая объем ОЗУ в виртуалке больше чем реально существующей на сервере. Или аналогично указывают в виртуалке количество ядер больше чем есть у физического процессора. Или суммарное количество виртуальных ядер больше количества физических ядеро процессора.
Привязывайте 1 к 1 виртуальные ядра к физическим с максимальным приоритетом без квотирования. Указывайте оперативную памяти не превышая физическую.

Использование динамически перераспределяемых ресурсов.

Платформа 1С:Предприятия на текущий момент не умеет эффективно работать с динамически выделяемыми ресурсами и будет обладать низкой стабильностью в таком режиме.
Не используйте динамических ресурсов.

Использование ресурсов одновременно нескольких NUMA-узлов

Платформа 1С:Предприятия чувствительна к нарушениям распределения по NUMA-узлам. Если вы на 4х сокетном сервере например для 4х процессоров по 16 ядер нарежете виртуалку на 18 ядер, то из-за двух ядер упадет скорость. Тоже самое касается оперативки, которая привязана к сокетам. Если вы укажите памяти больше, чем на одном сокете, то это тоже скажется негативно.
Избегайте нарушения распределения по NUMA-узлам

Разнесение на две виртуалки роли сервера 1С и MS SQL Server 2019

Старайтесь не разносить просто так роли по виртуалкам. Взаимодействие по виртуальным сетевым картам медленней чем через оперативную память Shared Memory. Только если вам не хватает физических ресурсов и у вас две виртуалки на разных физических машинах разнесение ролей будет оправдано. В остальных случаях арендуйте один хост и одну виртуальную машину на нем совмещая роли.

-----

Маркетологи убедили людей, что те же самые сервера у других людей, где вы будете их арендовать с какого то перепугу лучше, чем нежили всё тоже самое но проделаете вы лично. Идёт такое массовое отупление. Бростье, это сложно, зачем Вам это, просто арендуйте и тогда все ваши проблемы магическим образом решаться.