Главная » Файлы » Программируем в 1С » 1С Разное

Скачивать материалы с сайта, могут только зарегистрированные пользователи.
Для регистрации заполните два поля ниже!

Через минуту Вы получите "Гостевой доступ"




Дисковая подсистема узкое место 1С Предприятия.
2014 Сентябрь 06, 10:10

Дисковая подсистема узкое место 1С Предприятия.

Часто «узким» местом  в работе с 1С Предприятием  является дисковая подсистема.

Конечно, это не открытие и многие знают или, по крайней мере, догадываются о существовании такой проблемы, а самые шустрые даже пытаются решить  ее  покупкой нового HDD или SSD.

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

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

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

Именно эти блокировки возникают, когда стоят очереди на чтение – запись.

Это и есть проблема №1  дисковой подсистемы в 1С.

В этой статье хочу разложить по полочкам дисковую подсистему, постараюсь  объяснить как можно проще, как это работает.

Уверен, что после прочтения этой статьи Вы будете совсем по-другому смотреть на HDD и SSD.

 

 

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

Количество этих операций измеряются в IOPS.

(количество операций ввода-вывода в секунду).

Основными измеряемыми величинами являются операции линейного (последовательного) и произвольного (случайного) доступа.

Линейными операциями -  называют операции, когда части файлов считываются последовательно, одна за другой, здесь подразумевается передача больших файлов (более 128 К).

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

 

Обычно линейные IOPS проще показать в Мбайт/с  и  Гбит/с, собственно так нам их и показывают.

Вот простая формула:

IOPS * Размер_блока_в_байтах = Байт_в_секунду.

(обычно преобразуется в Мбайт/с – для чего нужно поделить на 1000000, обычно просто убрав последние 6 нулей)

Существуют программы способные измерить IOPS.

LOmeter – одна из таких программ. (от Intel).

Проводить лично тесты я не стал, так как это успешно сделали авторитетные ресурсы еще до меня.

Моя задача в доступной форме объяснить и показать Вам как это работает, используя эти примеры.

 

Приблизительные значения IOPS для жестких дисков:

Таблица №1.

Обычные HDD

Таблица №2.

Приблизительные значения IOPS для SSD (в идеальных условиях и непродолжительное время - при продолжительной случайной нагрузке на запись скорость падает в 2-10 раз по сравнению с заявленными характеристиками)

И так исходя из того что мы видим в таблице №1 и  таблице №2  можно сделать вывод

Вывод №1

IOPS для всех HDD почти одинаковы, небольшой отрыв видно только у дисков под интерфейсом SAS.

Простыми словами гнаться за новыми HDD пока  нет особого смысла.

 

Вывод №2

Существенно  эффективны SSD  только в «Произвольном доступе»

 

В остальном эти показатели можно делить на 10, но и в этом случаи SSD остаются быстрее обычных HDD.

Почему так SSD быстрее HDD объяснить не сложно.

Для жёстких дисков и других электромеханических устройств при произвольном доступе происходит поиск (перемещение головок), на что собственно и идут затраты  IOPS.

В то время как в SSD и системах хранения, сделанных на их основе, количество IOPS в основном зависит от работы внутреннего микроконтроллера и скорости интерфейса памяти.

Что ж мы разобрались в «скоростях» знаем как их рассчитывают.

 

Теперь посмотрим на таблицы 1С.

Материал ниже предоставлен сайтом:

http://ko.com.ua/proektirovanie_servera_pod_1s_66779

 

База объемом 200-300 MB с 3-5 пользователями может генерировать в пиках до 400-600 IOPS. 

База на 10-15 пользователей и объёмом в 400-800 MB способна выдать 1500-2500 IOPS, 

База на  40-50  пользователей и объёмом 2-4 GB выдает 5000-7500 IOPS,

 а базы под 80-100 пользователей легко достигают 12000-18000 IOPS.

На таблице показаны пиковые данные, собственно они нам и интересны, а в обычной работе цифры IOPS  будут на 90% меньше.

Современные диски в операциях чтения и записи со случайным доступом чтение / запись в одиночку справляются с такими нагрузками:

Хорошо видно, что:

  • узким местом и для HDD, и для SSD является запись;
  • традиционные HDD — не конкуренты SSD по скорости чтения в IOPS даже теоретически, разница превышает два порядка;
  • даже не самый современный десктопный SSD в 3-40 раз (в зависимости от конфигурирования) превосходит по скорости записи в IOPS любой HDD, серверный SSD — в 12-40 раз быстрее HDD;
  • максимальную производительность в IOPS дают PCIe SSD класса Intel 910 или LSI WarpDrive.

 

Одиночные диски в серверах БД как правило не используются, только RAID-массивы. Для дальнейшего расчета реальной производительности дисковой подсистемы нужно учесть затраты на запись «штраф». в IOPS, которые несет RAID- массив.

Если собрать 6 дисков в RAID 10, то на каждую запись в 1 IOPS данных будет потрачено 2 IOPS физических дисков, а если в RAID 6 — то 6 IOPS дисков. Таким образом, при расчете нагрузочных возможностей дисковой группы на запись нужно вначале сложить IOPS всех дисков RAID-группы, а затем разделить их на «штраф».

Пример 1: 2 HDD SATA 7200 в RAID 1 обеспечат на запись: (100 IOPS *2) / 2 = 100 IOPS.

Пример 2: 4 SATA 7200 в RAID 5 обеспечат на запись: (100 IOPS *4) / 4 = 100 IOPS.

Пример 3: 4 SATA 7200 в RAID 10 обеспечат на запись: (100 IOPS *4) / 2 = 200 IOPS.

Примеры 2 и 3 наглядно демонстрируют, почему для хранения баз данных, у которых типовое распределение чтение/запись составляет 68/32, предпочтителен RAID 10.

Из данных трех таблиц понятно, по какой причине производительности типового «джентльменского набора» 2 HDD SATA 7200 в RAID 1 серверу недостаточно: при пиковых нагрузках растет очередь обращений к диску, пользователи ожидают ответа системы, иногда по многу часов.

Как увеличить производительность дисковой подсистемы на запись? Наращивают количество дисков в RAID-группе, переходят к дискам с большей скоростью вращения, выбирают уровень RAID c меньшим штрафом на запись. Хорошо помогает кеширование RAID-контроллером с включенным режимом отложенной записи Write back. Данные пишутся не напрямую на диски (как в режиме Write Through), а в кеш контроллера, и только затем, в пакетном режиме и упорядоченном виде — на диски. В зависимости от специфики задачи, производительность записи удается поднять на 30-100%.

Под слабо нагруженные или относительно небольшие БД (до 20GB) подойдет недорогой способ «добычи IOPS» — гибридный RAID из SSD/HDD. Большего и не нужно филиальной БД на 3-15 пользователей в распределённой структуре вроде сети кафе или СТО.

Для объемных (200GB и более) БД с длинным историческим шлейфом данных, либо для обслуживания нескольких объемных БД эффективным может оказаться SSD-кеширование (технологии LSI CacheCade 2.0 или Adaptec MaxCache 3.0). По опыту эксплуатации таких систем, именно в задачах 1С с их помощью можно относительно недорого и без существенных изменений в инфраструктуре хранения ускорить дисковые операции на 20-50%.

Чемпионом по быстродействию в IOPS предсказуемо являются RAID-массивы на серверных SSD — как традиционные, с использованием SAS RAID-контроллера, так и PCIe SSD. Мешают их популярности два ограничителя: технологический (производительность RAID- контроллеров или необходимость радикально ломать структуру хранения) и цена реализации.

Отдельно следует сказать о хранении индексных файлов и TempDB. Индексные файлы обновляются очень редко (обычно 1 раз в сутки), зато читаются очень и очень часто (IOPS). Таким данным просто необходимо храниться на SSD, c их показателями по чтению! TempDB, используемые для хранения временных данных, как правило, невелики по объему (1-4-12GB), зато очень требовательны к скорости записи.

Индексные и временные файлы объединяет то, что их потеря не приводит к потере реальных данных. А значит, они могут размещаться на отдельном (еще лучше — на двух отдельных томах) SSD. Хотя бы и на бортовом контроллере SATA материнской платы.

 С точки зрения надежности и быстродействия, под TempDB желательно отдать зеркало (RAID1) из SSD, можно на бортовом контроллере, но с обязательным выключением всех кешей на запись. С этой ролью справятся и десктопные SSD — вроде Intel 520-серии, где аппаратная компрессия данных при записи в TempDB будет как раз уместной. Вынос этих задач с общей системы хранения на выделенную скоростную подсистему положительно сказывается на производительности системы в целом, особенно в моменты пиковых нагрузок.

В случаях, когда есть возможность обеспечить максимально быструю реакцию администраторов при сбоях, и когда имеются сложные расчетные задачи (складская или транспортная логистика, производство в УПП, объемные обмены в УРБД), TempDB выносят на RAMDrive.

Такое решение позволяет выиграть иногда до 4-12%общей производительности системы. Некоторое неудобство возникает только в случае рестарта сервера: если автоматически RAMDrive не запустится, потребуется вмешательство администратора для ручного старта — иначе станет вся система.

Еще один важный компонент — log-файлы. Они имеют неприятную для любой дисковой подсистемы особенность — генерировать почти постоянный поток мелких обращений на запись. Это незаметно при средних нагрузках, но сильно ухудшает быстродействие сервера 1С при пиковых нагрузках.

Разумно выносить log-файл (в особенности, log-файл SQL) на отдельный физический том, к которому нет высоких требований по IOPS, и на который будет идти практически линейная запись. Для спокойствия можно создать зеркало из недорогих и объемных SATA/NL SAS (для Full log), либо недорогих десктопных SSD все той же Intel 520-й серии (Simple log, или Full log, с ежедневным его Backup и очисткой).

В целом можно сказать, что приход SSD в серверы открыл новые возможности увеличения производительности массовых серверов — за счет многоуровневого хранения данных и разумного конфигурирования дискового ввода/вывода.

Дисковая подсистема «идеального сервера под 1С» выглядит так:

1. Таблицы базы данных размещены на RAID 10 (или RAID 1 для малых БД) из надежных серверных SSD с обязательным аппаратным RAID-контроллером. При высоких требованиях по IOPS можно рассмотреть вариант PCIe SSD. Для БД большого объема эффективно SSD-кеширование массивов HDD. Если используемая конфигурация 1С и структура данных не слишком требовательны к IOPS, а количество пользователей невелико — хватит традиционного массива из HDD SAS 15K rpm.

2. Индексные файлы вынесены на быстрый и недорогой одиночный SSD, TempDB — на 1-2 (RAID 1) SSD или RAMDrive.

3. Под log-файлы SQL (а желательно и 1С) отведен выделенный том (одиночный физический диск или RAID-1) на SATA/NL SAS HDD или недорогих SSD, либо логический диск на RAID-массиве, на котором расположена операционная система сервера и пользовательские файлы/папки.

4. Операционная система и пользовательские данные хранятся на RAID 1 из HDD или SSD.

Если IT-инфраструктура виртуализирована, крайне желательно, чтобы SQL Server был установлен не как виртуальная машина, а непосредственно на физический сервер, на «голое железо». Цена вопроса — от 15 до 35% производительности дисковой подсистемы (в зависимости от оборудования, драйверов, средств виртуализации и способов подключения тома). В виртуализированной среде SQL-сервера подключение томов с таблицами БД, индексными файлами и TempDB к VM обязательно в монопольном режиме по Direct Access.

Теперь как говорится коротко о главном:

SSD быстрее HDD  особенно в операциях произвольного доступа.


Все сегодняшние HDD  имеют примерно одинаковую скорость чтения/записи.


Узким местом и для HDD, и для SSD является запись.


Максимальную производительность в скорости дают SSD с интерфейсом PCIe.


RAID – массив снижает производительность HDD. (штраф).


В расчете производительности RAID – массивов нужно учесть затраты на запись «штраф» в IOPS.


RAID 10 быстрее RAID 5.


Производительность дисковой подсистемы можно увеличить путем:

А) Нарастить количество дисков в RAID-группе.

Б) Переход к дискам с большей скоростью вращения.

С) Выбрать уровень RAID c меньшим штрафом на запись.

Помогает увеличить производительность кеширование RAID-контроллером с включенным режимом отложенной записи Write back.


 Индексные файлы следует размещать на отдельных томах.


 log-файл SQL стоит вынести на отдельный физический том.


Малые базы данных хорошо работают в  RAID 1.


SQL server лучше устанавливать на физический сервер.


Если статья Вам понравилась, комментируйте.

С уважением, Богдан.

 

Категория: 1С Разное | Добавил: c1
Просмотров: 8191 | Загрузок: 0 | Рейтинг: 5.0/1

Выразить благодарность - Поделиться с друзьями!

 

Здесь все о технической стороне 1С!

 

Узнай, как правильно администрировать 1С Предприятие
Регистрируйся на бесплатный 7-ми дневный курс сейчас:

Ваш E-Mail в безопасности



Всего комментариев: 0
avatar