Предисловие
Постоянно сталкивался с высказываниями ИТ специалистов «сеть нагружена на 20%… процессоры на 50%… очередей к дискам мало… Значит сеть и сервера справляются… смотрите код в 1С проблемы исключительно там».
На самом деле происходило следующее ( сервер 1С и SQL разнесены на разные компьютеры): сеть практически использовалась по максимуму, почему описано ниже в статье. И соответственно из-за малой ширины канала обмена «полезными» данными — SQL сервер с «Сервером 1С» постоянно ожидали друг друга, что вело к малой утилизации ресурсов CPU и дисковой системы.
Ведение: Сначала хочу заострить внимание на том что же такое 1С платформа?.
Итак начнем с главного 1С — построенная на ORM (объектно-реляционном отображении)-система и программист в ней работает не напрямую с реляционным представлением, а с объектами.
Программист в среде 1С — пишет объектную логику, а за сборку/разборку и запись объектов в таблицах базы данных отвечает сама платформа.
Основные "+" и "-" с точки зрения ORM:
"+" Программист в среде ORM получает преимущество в скорости разработки приложения из-за уменьшения количества кода и его простоты по сравнению с исключительно реляционным программным кодом (пример SQL запросы). А также освобождается от написания кода работающего непосредтсвенно с записями в таблицах Реляционной СУБД.* 1
"-" Сложности для создателей «платформ» ORM и проблемы производительности:
Использование реляционной базы данных для хранения объектно-ориентированных данных приводит к «семантическому разрыву», заставляя программистов писать программное обеспечение, которое должно уметь как обрабатывать данные в объектно-ориентированном виде, так и уметь сохранить эти данные в реляционной форме. Эта постоянная необходимость в преобразовании между двумя разными формами данных не только сильно снижает производительность, но и создает трудности для программистов, так как обе формы данных накладывают ограничения друг на друга.
*1«Уточнение». Несмотря на то, что 1С 8.х позволяет работать с реляционно-подобным кодом (только чтение) в объекте 1С «Запрос» — это все-таки не напрямую один-в-один транслируемый в реляционную СУБД запрос к таблицам хранения данных, а прежде всего «Объектный запрос» — также не минующий стадию сборки разборки объектов. Поэтому зачастую вместо много-тысяче строчных «Объектных запросов» — наиболее оптимально по быстродействию кода и скорости разработки — написать объектный не ряляционно-подобный код.
Глава 1: Расмотрим модель клиент-серверной 1С 8.х
Отмечу основные «узкие» места влияющие на производительность:
1) Первое узкое место — это коммуникационная среда передачи данных.
На рисунке стрелками показаны потоки обмена данными, где «красные» — это Реляционная СУБД<->Объектная СУБ, «оранжевые» — синхронизация между Объектными СУБД.
Т.к. при использовании отдельных серверов для СУБД и кластеров 1С – коммуникационная среда это сетевые соединения – то существуют существенные задержки в передаче данных многочисленными мелкими порциями – как из-за латентности самой физической реализации интерфейсов, так и из-за латентности узлов в этой сети.
Рассмотрим на примере сетевого стандарта Ethernet Gigabit на примере работы Сервера 1С с MS SQL (по умолчанию размер коммуникационных пакетов 4 кб):
На графике видно, что при использовании пакетов TCP =4 кб пропускная способность рассмотренной сети всего 250 Мегабит/с. Это возникает из-за латентности сети и превышения размера «служебных» данных заголовков пакетов над размером «полезных» передаваемых данных.
Из практики: такое разнесение на Два отдельных сервера
MS SQL (сервер №1)< — Ethernet Gigabit ---> «Сервер 1С»(сервер №1)
проигрывало по скорости работы платформы
на 50% варианту MS SQL (сервер №1) < — Shared Memory (без сети через участок памяти) ---> «Сервер 1С»(сервер №1)… и это уже «на одном высоконагруженном пользовательском сеансе»
2) Узкое место — это количество отдельных компьютеров «кластеров 1С», чем их больше тем больше затраты на синхронизацию и как следствие уменьшение производительности системы.
3) Узкое место — количество отдельных процессов сервера 1с, чем их больше тем больше затрат на их синхронизацию… Но тут скорей всего необходимо найти «золотую середину» — для обеспечения стабильности. 2*
2* «Уточнение» — для MS Windows существует такое правило:
Процессы дороже чем потоки, что означает применительно к данному случаю на практике следующее: скорость обмена между двумя потоками внутри одного процесса значительно превышает, скорость обмена между потоками находящихся в разных процессах.
Поэтому например «Файловая 1С 8.х» всегда превышает по скорости однопользовательской работы платформы в клиент-серверном варианте. Все просто т.к. в случае «Файловой 1С 8.х» поток «Реляционной СУБД» общается с потоком «Объектной СУБД» внутри одного единого процесса.
4)Узкое место – одно-поточность пользовательского сеанса, т.к. каждый отдельно взятый — пользовательский сеанс не распараллеливается платформой на несколько, то его работа ограничивается использованием ресурсов одного ядра CPU => следовательно желательна максимальная скорость каждого ядра, в этом случае быстродействие платформы 1C например на 10-ядерном CPU по 1 ггц — будет значительно уступать быстродействию платформы на 4-ех ядерном CPU по 3 Ггц – естественно до определенного количества потоков.
Глава 2(Итог): Рассмотрим не масштабируемый и масштабируемый варианты — наиболее эффективных схем для платформы 1с 8.х. для OS Windows (пологаю для Linux ситуация аналогична)
1-Вариант(не масштабируемый). В расчете на 100 «высоконагруженных пользовательских сеанса»
1) эффективен обычный 2-ух сокетный сервер с 4-ех ядерными CPU по 3 Ггц.
2) быстрая дисковая система на SSD
3) MS SQL < — Shared memory --> «Сервер 1С»
2-Вариант(масштабируемый). начиная со 100 «высоконагруженных пользовательских сеанса» и далее….
Тут логичней всего пойти по пути немецкой 1с-ки «Sap Navision»))
Собирать модульный «Супер-компьютер» от фирмы SGI – состоящий из «лезвий» на 2-х сокетных материнских платах, каждое лезвие соединяется друг с другом сложной топологией сверх-быстрого интерконнекта на основе NUMA-чипов, и все находится под управлением единой OS. Т.е. программы внутри такого сервера по определению имеют доступ к ресурсам любого «лезвия».
1) добавляем «лезвия» по необходимой нагрузке… из расчета примерно одно «лезвие» на 100 пользователей.
2) быстрая дисковая система на SSD
3) MS SQL < — Shared memory --> «Сервер 1С»
Автор: sanfoto
