TRIM

Что такое TRIM

У электронных (SSD) дисков есть отличие от магнитно-механических (HDD) которое влияет на скорость записи. В HDD дисках запись выполняется «поверх» старых данных. Блоки диска, которые ранее содержали данные, а затем эти данные были удалены, просто помечаются как свободные. И когда нужно выполнять запись,  контроллер HDD сразу записывает новые данные в эти свободные блоки.

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

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

Поэтому при использовании SSD дисков возникает эффект «деградации производительности». Когда диск новый и все блоки флэш-памяти чистые тогда скорость записи очень высокая, паспортная. Но после того как диск будет полностью заполнен и после этого часть файлов будет удалена, повторная запись будет происходить на более низкой скорости. Из-за того, что контроллеру диска придется очищать ранее использованные блоки флэш-памяти, перед записью туда новых данных.

Падение скорости записи в повторно используемые блоки флэш-памяти может быть очень высоким. До значений близких к скорости записи HDD дисков. При тестировании SSD дисков часто даже проводят отдельную проверку на снижение скорости записи в повторно используемые блоки.

Для борьбы с этим явлением, в новые ОС добавлена дисковая команда ATA TRIM. Драйвер файловой системы при удалении файла отправляет контроллеру SSD диска команду TRIM. По этой команде контроллер SSD диска очищает освобожденные блоки флэш-памяти, но делает это в фоновом режиме, в перерывах между операциями чтения и записи.

Использование этой команды позволяет вернуть полную скорость записи для повторно используемых блоков флэш-памяти. Однако не все ОС поддерживают эту команду. А только относительно свежие версии:

  • Ядро Linux начиная с версии 2.6.33.
  • Windows 7, 8 и 10
  • Mac OS X начиная с версии с 10.6.6 (но для этой версии нужно устанавливать обновление).

До сих пор популярная WIndows XP (как и Vista) не поддерживают эту команду.

Обходной вариант для старых ОС, заключается в использовании, сторонних программ. Например это может быть программа hdparm (версии 9.17 и выше) или фирменные программы производителя SSD диска, например Intel SSD Toolbox.

 

Есть модели дисков, которые даже после выполнения команды TRIM не возвращаются к полной паспортной скорости записи.

Команда TRIM может не работать если SATA контроллер материнской платы был установлен в режим IDE (для совместимости со старой ОС или программой).

Команда TRIM чаще всего отключается при использовании RAID массива.

Как работает TRIM

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

Когда вы удаляете файл на SSD диске, операционная система отправляет контроллеру SSD диска команду TRIM и вместе с ней список секторов которые можно очистить. Контроллер записывает эти сектора в очередь своей подпрограммы, «сборщика мусора». А эта подпрограмма обрабатывает все сектора из списка.

Сборщик мусора работает в те моменты, когда диск простаивает. То есть, когда операционная система не присылает запросы на чтение или запись данных. Поэтому с момента получения команды TRIM, до фактического удаления этих секторов проходит некоторое время.

Если в очереди на тримеризацию много секторов, их очистка может занять продолжительное время. Например, если выполнить быстрое форматирование целого раздела, то TRIM такого объема может быть длительным.

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

Как проверить ваш SSD диск на поддержку команды TRIM

Использование ATA команды TRIM, не во всех случаях происходит автоматически, в некоторых ситуациях выполнение этой команды со стороны ОС необходимо включать явным образом.

Для начала нужно убедиться в том, что ваш SSD диск поддерживает эту команду. Впрочем, все новые диски ее поддерживают. Сделать такую проверку можно любой современной программой по работе с дисками. Например в Linux это можно сделать при помощи консольной команды:

hdparm -I /dev/sda | grep -i trim

Где sda ваш SSD диск. Вывод команды должен содержать строку «TRIM supported».

В Windows это можно сделать при помощи программы производителя вашего SSD диска, обычно такие служебные программы есть у всех производителей. Или через тестовую программу для дисков, например HD Tune или SSD Life.

Когда TRIM не работает!

  • Функция TRIM не работает если SSD диск подключен через USB.
  • Функция TRIM не работает для разделов c файловой системой FAT32.
  • Функция TRIM не работает еще для большого количества файловых систем (например Ext2).

Когда TRIM должен работать

  • Linux с ядром начиная от 2.6.33 и файловая система Ext4.
  • Windows 7, 8 и 10 и файловая система NTFS.
  • Mac OS X начиная с версии с 10.6.6 (но для этой версии нужно устанавливать обновление).
  • FreeBSD начиная с версии 8.3 — для файловых систем UFS и ZFS.

Важно понимать, что функционал TRIM связан не только с версией ОС, но и с файловой системой. Например Windows 7, 8 и 10 поддерживают TRIM, но только для файловой системы NTFS, а на разделах FAT32 эта функция недоступна.

Включение TRIM в Linux

Примечание. В Ubuntu, начиная с версии 14.04, TRIM включать вручную уже не нужно!

Во-первых для использования TRIM, необходимо, чтобы файловая система была ext4.

Во-вторых включение команды TRIM указывается в опции монтирования для раздела ext4 в файле fstab. Конкретно это опция discard.

Кроме этого, для раздела на SSD диске можно добавить опции noatime (или realtime) и nodiratime — это снижение нагрузки  по записи, не будут обновляться даты доступа к файлам и папкам.

Также можно добавить опцию commit и указать значение допустим 60 секунд — отложенные операции записи будут выполняться на раздел раз в 60 секунд. Но эту опцию можно добавлять только в том случае если у вас есть UPS (ИБП), или на ноутбуке!

Таким образом примерная строка fstab может выглядеть таким образом:

UUID=aeade6fd-2b24-4e59-bc8c / ext4 noatime,discard,errors=remount-ro,commit=60 0 1

В Linux можно выполнить команду TRIM и вручную:

sudo fstrim / -v

В этом примере команда применяется к корневой файловой системе.

Проверка и включение TRIM на Windows 7, 8 или 10

Сначала нужно открыть консоль («Командная строка») с правами администратора. Меню Пуск — Программы — Стандартные — Командная строка. Правая кнопка мыши — Запустить от имени Администратора.

Далее в консоли выполнить команду:

fsutil behavior query disabledeletenotify

Если вывод команды будет — disabledeletenotify=1, значит команда TRIM отключена. Включить ее можно командой:

fsutil behavior set disabledeletenotify 0

Не перепутайте! Ноль — команда включена, единица — команда выключена.

Как выполнить TRIM на разделе NTFS

Если у вас операционная система Windows 7, 8 или 10, тогда можно ничего не делать. Достаточно проверить включена для функция TRIM. Далее Windows будет автоматически отправлять команду TRIM при следующих операциях с диском:

  • Удаление файла(ов).
  • Быстрое форматирование раздела (диска) NTFS.
  • Удаление раздела NTFS.

В Windows 8 и 10 можно вручную дать команду TRIM для целого раздела (диска) NTFS. В свойствах диска, на вкладке «Сервис» нужно открыть Оптимизатор дисков. Это новое название дефрагментатора Windows.

В Оптимизаторе дисков для разделов NTFS на SSD диске будет доступна команда «Оптимизировать диск». Выполнение этой команды приводит к тому, что Windows отправляет SSD диску команду TRIM для всех свободных блоков на этом диске. То есть выполняется «тримизация» всего свободного пространства на разделе (диске) NTFS.

В Windows 7, 8 и 10 можно сделать «тримизацию» всего раздела (диска) NTFS. Для этого нужно выполнить быстрое форматирование этого раздела (диска). Однако важно понимать, что это уничтожит все данные на разделе.

В последних (2015, 2016 годы) версиях драйвера ntfs-3g (драйвер ntfs для линукс) добавлена функция TRIM. Теперь можно «тримизировать» раздел NTFS из Linux. Команда в терминале:

fstrim -v /media/ntfs/

где /media/ntfs/ примонтированный раздел NTFS.

Как выполнить TRIM на Windows XP и Vista

Ни Windows XP, ни Vista не поддерживают функцию TRIM. Если нужно «тримизировать» SSD диск, который используется в этих ОС, тогда есть следующие варианты:

  • Программа производителя SSD диска. Если такая есть.
  • Подключить этот диск на другой компьютер, где установлена Windows 8 или 10. И через Оптимизатор дисков выполнить оптимизацию NTFS разделов на этом диске. Важно! Диск нужно подключать через SATA, а не через USB. Подробно об этом в разделе «TRIM на NTFS».
  • Загрузить компьютер с флешки со свежим дистрибутивом Linux (2015 или 2016 года). Примонтировать разделы NTFS и выполнить команду fstrim. Подробно об этом в разделе «TRIM на NTFS».

Но можно и вообще не «заморачиваться» по поводу TRIM на этих ОС. Можно оставить неразмеченой 20-30% от емкости диска и этого будет достаточно для поддержания нормальной скорости записи. Неразмеченой это значит не присвоенной ни одному разделу.

Восстановление удаленных данных

Если вы используете TRIM, о восстановлении удаленных файлов можно забыть. Если вы удалите файл, то его данные на SSD диске будут уничтожены.

Влияние TRIM на скорость записи

Важно понимать, что использование или не использование функции TRIM прямо не влияет на скорость записи SSD диска. Влияет на эту скорость только один фактор — наличие достаточного количества свободных блоков флеш-памяти. То есть таких блоков, которые очищены контроллером диска и готовы к записи в них новых данных.

Иначе говоря, скорость записи зависит от количества свободного места на диске. Если у вас диск почти полностью заполнен, то скорость записи упадет даже если вы используете TRIM. И наоборот, если у вас 20-30% емкости диска оставлены без разметки (unallocated disk space), тогда можно обойтись и без использования TRIM. Контроллер диска будет использовать неиспользуемую под разделы емкость для выравнивания скорости записи.

Функция TRIM действительно даст возможность поддерживать высокую скорость записи только при двух условиях:

  1. Под разделы выделена вся емкость SSD диска.
  2. Радел(ы) с файловой системой не заполнены более чем на 70-80% от своего размера.

Особенности 8.3.19

Расширены возможности динамического списка.
Для динамического списка реализованы возможности, аналогичные возможностям которые имеются в системе компоновки данных:

  • Настройка полей запроса (заголовок, тип, оформление, ограничение использования и т.д.).
  • Работа с вычисляемыми полями.
  • Использование параметров в настройках пользователя.
  • Настройка свойств параметров (заголовок, тип и т.д.).
  • Для полей типа Дата реализована возможность работы с дочерними полями (начало дня, месяца и т.д.) в сортировке и группировке.

Изменен редактор настроек динамического списка.

Для динамического списка реализованы свойства ПоляВычисляемыеПоляПараметрыДанных.

 Ускорено исполнение запросов, в том числе при использовании ограничения доступа к данным.Ускорена работа функции выражения ограничения доступа к данным СтрСодержит().

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

Для команды пакетного запуска конфигуратора /RestoreIB реализован параметр -JobsCount, позволяющий управлять количеством используемых фоновых заданий.

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

Повышена скорость работы файлового варианта информационной базы.

Повышена производительность запросов к виртуальной таблице остатков и оборотов регистра бухгалтерии.

Ускорены операции получения представлений ссылочных объектов и, как следствие, связанные операции. Например, ускорится упорядочивание таблицы значений по ссылочной колонке.

Улучшена поддержка протокола OpenID Connect.

Расширен набор информации, выводимой утилитой лицензирования (команда ring license info):

  • В раздел с информацией о лицензии добавлена информация о типе лицензии и типе привязке лицензии.
  • Реализован новый раздел TechnicalInfo, содержащий машиночитаемую информацию. Данные в этом разделе всегда выводятся на английском языке.
Повышена скорость выполнения методов ЗарегистрироватьИзменения() и УдалитьРегистрациюИзменений() в том случае, когда эти методы необходимо применить для большого количества объектов данных.

Для методов ЗарегистрироватьИзменения() и УдалитьРегистрациюИзменений() реализована возможность выполнять регистрацию и удаления регистрации изменений для произвольного набора объектов данных, которые передаются в качестве массива в параметре Данные этих методов.Действие для всех объектов, находящихся в переданном массиве, будут выполнены в рамках одной транзакции с минимальным количеством используемых запросов.

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

Реализована возможность использовать частичное делегирование Kerberos для выполнения аутентификации ОС в том случае, если кластер серверов работает под управлением ОС Windows, а веб-сервер и клиентское приложение расположены каждый на своем компьютере и этот компьютер отличается от компьютера, на котором работает кластер серверов.Для средств администрирования кластера серверов реализована возможность указания имени участника-службы (SPN):

  • В консоли администрирования кластера, в свойствах рабочего сервера, реализовано свойство Имя службы (SPN) сервера 1С:Предприятия.
  • Свойство объекта АдминистрированиеРабочийСервер.ИмяСлужбыСервера.
  • Свойство объекта IWorkingServerInfo.ServicePrincipalName для средств администрирования с использованием COM-соединения.
  • Методы getServicePrincipalName()setServicePrincipalName() интерфейса IWorkingServerInfo для средств администрирования из языка Java.
  • Параметр service-principal-name для команд rac server insertrac server update.

 Значение свойства рабочего сервера кластера Временно допустимый объем памяти процессов используется и для перезапуска рабочих процессов по памяти и для управления прерыванием объемных вызовов. Данное свойство допускается использовать с лицензией уровня ПРОФ.

Подключение NVMe SSD в VMWare

Предисловие. В этой статье речь пойдет про подключение NVMe дисков к VMware (внутреннего подключения к физическому серверу) . Понятно, что маркетологи убедили многих провайдеров и ИТ крупных компаний, что удобство администраторов важнее результата работы дисковой подсистемы для конечных пользователей. Поэтому статья может вызывать неприятие типа «а у нас корпоративная политика», «это не вписывается в нашу концепцию» и т.п.
Однако наша задача поделиться практическим опытом по решению конкретных проблем с конкретным оборудованием и для конкретной системы виртуализации, а пользоваться ли плодами статьи это личное дело каждого.

Также обращаю внимание, что проблема разбирается на конкретной модели Samsung 970 pro и VMWare 6.7. Не надо думать, что все виртуалки и все диски NVMe ведут себя одинаково и бездумно тиражировать текущий подход статьи  ко всему. В каждом конкретном случае надо проходить полный путь расследования, как в статье.

Проблема с дисковой производительностью

Ситуация: сервер 1С/СУБД, на котором наблюдаются существенные проблемы с производительностью дисковой подсистемы: время обслуживания дисковых операций исчисляется не единицами миллисекунд (как хотелось бы), не десятками (как ещё допустимо), а несколькими сотнями, причём это же видно и средствами операционной системы.

Выглядит это например вот так:

Открываем в Windows монитор ресурсов — наблюдаем аналогичную ситуацию и там (обратите внимание на колонку “время ответа”, значение в миллисекундах):

Первая реакция: такие показатели характерны для загруженного механического (дефакто медленного) диска.

 

Первые тесты

Дожидаемся технологического окна, когда службы 1С и СУБД можно полностью остановить, нагрузку с диска снимаем, и прогоняем тест CrystalDiskMark

Результаты выглядят вполне прилично для недорогого NVMe SSD (отклик должен быть около 10 мс, а не сотнями мс как у нас). Идём выяснять, что же там “под капотом”. Выясняем, что данные расположены на неплохом (для десктопа, не для сервера) NVMe SSD Samsung 970 Pro, который хоть и не “энтерпрайз класса”, но и вот настолько проседать под такой нагрузкой вроде как не должен.

Вот нормальный результат диска на физическом сервере для сравнения.
Идём разбираться дальше: сервер развёрнут на виртуальной машине на базе VMWare ESXi 6.7, SSD используется в “виртуализованном” виде:

Из диспетчера устройств виртуальной Windows устройство видно например так:

В данном виде гостевая операционная система видит SSD как некий сетевой массив, и управлять этим SSD не может (например, не передаётся команда TRIM). И явно для данного SSD это не является “комфортным” режимом работы. Попробуем это изменить.

 

Вносим изменения в конфигурацию

И вот здесь наступает пора внести изменения!

Первым делом бэкапим целиком содержимое используемого диска на какой-либо другой носитель, потому что следующий шаг включает в себя форматирование диска!

Затем идём в консоль ESXi хост-машины, где развёрнута наша система, и делаем следующее:

в консоли заходим в пункт Manage — Hardware, выбираем в списке нужное нам устройство, в данном случае Samsung NVMe SSD, и на его строчке жмём кнопку Toggle passthrough, чтобы в поле Passthrough надпись Disabled сменилась на Active. Это будет означать, что с текущего момента хост-система перестаёт отвечать за обслуживание данного устройства, это устройство можно будет передать внутрь виртуальной системе в его исходном виде, и дальше уже виртуальная система будет с ним работать напрямую. 

После этого изменения система вас предупредит, что потребуется рестарт хост-машины. Если на хост-машине работают и другие виртуалки — учитывайте это!

После рестарта хоста — снова заходим в консоль ESXi, заглянем в пункт Storage — Devices и убедимся, что наше устройство из списка пропало.

Далее идём в настройки конкретной виртуальной машины, нажимаем Edit settings — Add other device — PCI Device, и здесь выбираем нужный NVMe SSD Controller, жмём Save:

причём если попытаться добавлять путём Add other device — NVMe controller, то ничего не получится.

 

Что же изменилось?

Далее загружаем виртуальную ОС, и внутри наблюдаем вместо устройства с добавлением VMWare “родное” название устройства, рядом с двумя устройствами, для которых проброс не включен и которые продолжают обслуживаться средствами VMWare.

Теперь этот SSD надо заново отформатировать (мы использовали размер кластера 8 килобайт, так как именно таков размер страницы данных в MS SQL, а именно базы СУБД на этом диске и будут расположен).

И настала пора сравнить результаты тестов CrystalDiskMark:

Как видно из снимка — результаты заметно подросли по всем пунктам. Но главное — заметно выросли показатели в нижней строчке, чтение-запись блоками по 4 килобайта при глубине очереди в 32 операции, по сути именно она и похожа на характер многопоточной нагрузки на сервере СУБД.

Но теперь самое важное — как себя поведёт СУБД, будучи развёрнутой на этом диске. 

 

Итоговый результат

Разница оказалась весьма существенной, хороший десктопный (хоть и не серверный) SSD начал работать заметно лучше.

Результаты снимков монитора ресурсов “до и после” для удобства свели в одну картинку.

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

 

Вывод

Как минимум в данном сценарии, использование десктопного NVMe SSD в VMWare ESXi 6.7 в виртуализованном варианте приводило к существенному ухудшению производительности SSD, при этом “формальный” тест CrystalDiskMark мог выглядеть “вполне прилично” (если не сравнивать “в лоб” с показателями ровно такого же устройства, подключенного напрямую). Подключение же NVMe SSD напрямую в виртуализованную операционную систему привело к тому, что ОС смогла управлять диском напрямую (например, подавать команды TRIM), и производительность диска увеличилась и стала больше соответствовать  данной модели NVMe SSD.

смотрите также Про диски для 1С

Почему для NVMe дисков под 1С не нужны RAID-массивы

Подбираем хороший сервер

 

 

Почему для NVMe дисков под 1С не нужны RAID-массивы

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

 

Нужен ли RAID-массив

Яркий пример неудачного массива

В каких случаях RAID-массивы на сервере 1С/СУБД можно использовать:

В каких случаях RAID-массивы на сервере 1С/СУБД не нужны

Почему RAID не является панацеей для отказоустойчивости

Нужен ли RAID-массив

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

Затем появились SSD, или твердотельные накопители (сокращённо они до сих пор называются “диски”, хотя там уже круглого ничего не осталось 🙂), скорость которых поначалу той же была хоть и выше, чем у механики, но всё равно “не радующей”, а надёжность вызывала сомнения (до сих пор большое количество айтишников уверены, что “SSD ненадёжные”), и эти SSD тоже по привычке запихивались в RAID-массивы. Однако “внезапно” стало проявляться, что далеко не всегда скорость итогового массива из SSD так же хорошо масштабируется, как если бы это был массив механических дисков, и тому есть ряд причин. Наиболее важные для нас минусы:

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

— если в состав массива включены SSD, не предназначенные для использования в составе массива, или не обладающие достаточной производительностью на запись (подробней о расчёте “нужной” производительности SSD можно почитать здесь: http://www.gilev.ru/dwpdssd/).

Для NVMe SSD даже если вы захотите собрать RAID-массив, то вам нужны такой контроллер и такая версия массива, чтобы они учитывали особенности архитектуры NVMe дисков, и позволяли не потерять, а как минимум сохранить скорость на уровне отдельно подключенного диска. Например, таковым является intel VROC (ссылка на https://www.intel.ru/content/www/ru/ru/support/products/122484/memory-and-storage/ssd-software/intel-virtual-raid-on-cpu-intel-vroc.html), опирающийся в свою очередь на intel VMD инструкции процессоров. 

Яркий пример неудачного массива

На снимке ниже: пример такого массива, собранного “неправильно”, формата RAID50, в котором 10 (десять) SSD. Причём в этом массиве “хорошо” себя показывает только чтение, и только крупными порциями (верхняя строчка Seq в колонке Read каждого из двух результатов). Запись даже крупными порциями (верхняя строчка Seq в колонке Write) показывает нам всего 142 мегабайта в секунду, а многопоточная запись пакетами по 4 килобайта (нижняя строчка 4K QD32 в колонке Write) даёт нам всего около 16 мегабайт в секунду. 

Исключительно для понимания: одиночный диск из состава этого массива имеет показатели записи минимум вдвое выше тех, что показал массив из десяти таких дисков. А поскольку этот массив был предназначен для высокопроизводительной смешанной (чтение+запись) нагрузки сервера 1С/СУБД — очевидно, данный массив для этих целей можно считать непригодным.

В каких случаях RAID-массивы на сервере 1С/СУБД можно использовать:

Для загрузочного носителя как зеркало.
Но не потому что вы получаете реальную отказоустойчивость, а потому что цена такой “игрушки” невысока. Предполагаем, что это будут два недорогих SATA SSD класса read intensive или даже boot (подробней о классах SSD и их предназначении можно почитать здесь: http://www.gilev.ru/dwpdssd/), объединённых в RAID1 (“зеркало”). Если исходить из рисков выхода из строя, то вы скорее износите диск, чем он сломается. Некоторые современные SSD также подвержены перегреву, но рядом расположенные два ssd в рейд маловероятно сработают как надо, так как будут нагреваться примерно одинаково и перегреются почти одновременно. Кроме того надо помнить, что ssd “изнашиваются примерно одинаково”. Поэтому RAID в данном случае будет “для успокоения любителей делать рейд” без тяжелых финансовых последствий. Если вы будете подключать LUN для старта ОС с внешнего хранилища, то с высокой вероятностью там будет RAID “потому что так исторически сложилось”, т.е. нарезают массивы заранее, когда еще точно не знают характер использования и требования к отказоустойчивости 🙂

 

Для локальных бэкапов для увеличения емкости массива “страйп”.
Для бэкапов часто бывает необходимость места больше, чем есть на одиночном диске и поэтому увеличить общую емкость через рейд может быть полезно. Но хранить бэкапы в одном экземпляре только на зеркале прямо на том же сервере, что и исходная база этих бэкапов — мероприятие малоосмысленное, только зазря себя успокаивать. Если с сервером что-то случится — такой бэкап будет недоступен точно так же, как и исходная база. Гораздо полезней для повышения отказоустойчивости хранения локальных бэкапов сохранять сначала локально, затем тут же копировать (только копировать, не переносить!) полученные файлы бэкапа куда-то наружу сервера на сетевой ресурс. Подробней про бэкапы можно почитать например здесь: http://www.gilev.ru/31march/). 

 

Для базы данных 1С или данных кластера 1С “страйп” в отдельных случаях когда очередей к диску больше порога возможностей. Тут есть одно очень важное уточнение. Порог определяется не чьим-то мнением, а фактическими числовыми показателями времени отклика диска и числа очередей к диску, записанными за длительный период, который можно считать показательным для оценки. Т.е. решение принимается не потому, что вы заранее думаете “надо сделать рейд потому, что это так кажется правильным”, а потому что обладаете собранными с тестового стенда или даже лучше с продуктива данными, подтверждающими что с текущей нагрузкой диск не справляется именно из-за слишком большого числа одновременных операций чтения/записи. Если вы видите, что ваш диск выдерживает условно 128 одновременных активных транзакций (ну или пропорциональное им количество очередей) без потерь по времени отклика, а далее начинает выходить за рамки (ну пусть условно для примера порог будет 30 мс), то при росте числа активных транзакций ну скажем до 180, можно говорить об обоснованности наращивания дисковой подсистемы (например, добавления в RAID 0 второго диска). Ну и так далее. Также надо помнить, что в случае MS SQL Server и наличия квалифицированного админа — есть смысл не RAID 0 собирать под базу данных, а подключить те же два диска из примера отдельно, поместив на каждый по файлу базы данных (поровну распределив размер базы данных на каждый файл). В этом случае MS SQL Server на отдельных операциях может выдавать большую производительность, чем RAID 0.
Большинству админов лень что-либо замерять, и оборудование заказывается “на глаз”. Разумней в этом случае брать минимум дисков, и только по фактической нехватки мощности докупать диски. Если админ “отмазывается” тем, что у него бюджет на год и надо покупать сразу всё, тогда гораздо полезней всё равно сначала закупить один “нужный” диск, замерить практическим экспериментом “сколько он выдержит”, и только после этого составлять калькуляцию на год.

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

В каких случаях RAID-массивы на сервере 1С/СУБД не нужны

Временные данные 1С или СУБД, а также вторичные данные, потеря которых не остановит работу компании.

Сюда могут включаются например:
— папка кластера 1С, где лежат логи журналов регистрации и файлы полнотекстового поиска 1С (если он используется);
— папка temp профиля пользователя, под которым запущена служба сервера 1С;
— файлы и логи служебной базы tempdb сервера MS SQL (а если у вас PostgreSQL — то это например папки логов pg_clog/pg_xlog/pg_wal/pg_xact, в зависимости от версии постгреса).

 

Для всех вышеперечисленных целей наиболее рациональным мы видим использование независимых NVMe SSD (не SATA!), подключаемых либо в слоты PCIe, либо по U.2 (если серверная платформа или контроллер предполагают такую возможность). Производительность лидирующих по производительности одиночных NVMe SSD на потоковую запись исчисляется несколькими гигабайтами в секунду, а на случайную запись — многими сотнями мегабайт в секунду, или многими сотнями тысяч так любимых админами и вендорами IOPS. Объём таких одиночных накопителей может достигать например для разных моделей от 6 до 16 терабайт, при этом их же можно подключать несколько (если ваш сервер позволяет, конечно). Ряд серверных платформ позволяет подключить до 8-24 NVMe SSD. 

При этом, например, если у вас база 1С почему-то достигла объёма в несколько терабайт, а вы не хотите или не можете предпринимать никаких мер по уменьшению её размера (например http://www.gilev.ru/basereduction/), но при этом знаете, что на дисках сервера СУБД хорошо бы держать про запас свободного места ещё хотя бы на 50% объёма продуктивной базы (например, на случай реструктуризации или вообще внезапного роста), то например для базы в 4 терабайта не обязательно искать SSD на 8 терабайт, можно “размазать” базу средствами СУБД на 2-3 SSD меньшей ёмкости. 

Как именно разносить нагрузку tempdb, базы и логов — лучше всего не гадать, не слушать “чужих советов”, а просто “сфотографировать” со своей работающей системы фактические объёмы записи в СУБД например за неделю (подробнее: http://www.gilev.ru/dwpdssd/), и на их основании уже принимать решение вида “нам нужно вот столько SSD такой ёмкости, распределять нагрузку между дисками будем вот таким образом” (конкретный пример разнесения приводить не будем из принципа, чтобы он случайно не отложился в памяти как рекомендация).

Вышедшие NVMe PCIe 4.0 диски типа intel D7-P5600 настолько быстры, что современные сервера на RAM-дисках не дадут сколько-то значимого преимущества, но при этом обладают недостатками надежности  при отключении питания. Для малого бизнеса есть бюджетные диски типа Samsung 980 Pro.

Основные данные и файлы лицензирования ключей 1С.
Надежность дисков серии intel p3700, p4800 проверена временем. На таких дисках можно смело размещать основные данные. Вероятность выхода из строя таких дисков меньше чем блока питания к примеру. На некоторых проектах такие диски успешно работают более 5 лет.

Усилия по повышению надежности надо предпринимать на программном уровне (СУБД и т.п.)  оперативно передавая  данные на резервный сервер. Так как риски словить вирус или испортить данные руками пользователей будут гораздо выше. Оперативно выполняемые бэкапы на отдельный физический локальный диск будут первым шагом, более эффективным чем зеркалирующий рейд. Для бэкапов на физических серверах можно использовать например https://acronis-infoprotect.ru/backup . Если у вас будет резервный сервер для поднятия бэкапа, а также удаленно лежащая копия, то это снимает вопрос по необходимости зеркалирования дисков рейдом.

Почему RAID не является панацеей для отказоустойчивости

Что же касается надёжности — тут наша позиция такая: массив RAID даёт шанс пережить выход из строя условно 1-2 носителей из его состава. Это конечно замечательно, но если мы начинаем изучать, что же на самом деле может “сломаться” (не в порядке параноидального бреда, а по наблюдениям нас и наших клиентов) — выясняется, что это лишь малая часть айсберга! Выходят из строя разные комплектующие внутри сервера, выходят из строя компоненты сети, может “приехать” неудачное обновление Windows или 1С, может “упасть” сервер 1С, может “сломаться” база 1С, может “прилететь шифровальщик”. Будет ли откровением то, что ни от какого из этих факторов риска RAID-массив нас не спасёт? Здесь уже надо говорить о сценариях резервирования, отказоустойчивости и катастрофоустойчивости (но об этом в другой раз).

 

Почему SSD не “настолько же ненадёжны, как механические диски”: в механическом диске были вращающиеся с бешеной скоростью пластины, были яростно летающие над ними на микронной высоте головки, всё это жужжало, вибрировало, грелось, сильно боялось тряски или сторонних вибраций, внезапных отключений электричества и вообще было нежным и хрупким даже в довольно крепком серверном исполнении. Современные серверные SSD — скучная плата без движущихся деталей, возможно (и даже крайне желательно) с увесистым радиатором (а кто-нибудь может и вентилятор сверху “приколхозить”), по сути там внутри есть флэш-память и контроллер. Внутри SSD есть расходуемый ресурс, а именно флэш-память, которая при записи неизбежно изнашивается, и этот параметр крайне желательно контролировать хотя бы раз в месяц, но если к подбору SSD подошли правильно и вдумчиво — SSD как минимум переживёт период продуктивной эксплуатации, а с очень большой вероятностью доживёт и до полного морального устаревания сервера. Вся остальная электроника внутри — условно такая же, в остальном сервере, и выход из строя хоть и может произойти, но примерно с такой же вероятностью, как у любой другой компоненты серверного оборудования.

 

В итоге: для сервера 1С/СУБД RAID-массив из NVMe SSD в большинстве случаев не является необходимым ни для ускорения, ни для повышения надёжности.

 

Смотрите также Зачем аппаратному RAID-контроллеру нужна батарейка?

Подключение дисков с разъемом U.2

Влияние HDD на быстродействие 1С:Предприятие 8

31 марта — Международный день резервного копирования
Про диски для 1С

Подбираем хороший сервер

FREEPROCCACHE

Очистка процедурного КЭШа DBCC FREEPROCCACHE

http://technet.microsoft.com/ru-ru/library/ms174283.aspx

Удаляет все элементы из кэша планов, удаляет заданный план из кэша планов с помощью указания дескриптора плана или дескриптора SQL либо удаляет все записи кэша, связанные с указанным пулом ресурсов.

Инструкция DBCC FREEPROCCACHE используется для аккуратной очистки кэша планов. Освобождение кэша планов приводит, например, к тому, что хранимая процедура повторно компилируется, а не используется из кэша. Это может стать причиной внезапного временного снижения производительности обработки запросов. В SQL Server для каждого очищенного хранилища кэша в кэше планов журнал ошибок содержит следующее информационное сообщение: «SQL Server обнаружил %d экземпляров, записанных на диск хранилищ кэша для хранилища кэша %s (части кэша планов) в результате операций DBCC FREEPROCCACHE или DBCC FREESYSTEMCACHE». Это сообщение добавляется в журнал каждые пять минут при сбросе кэша в течение этого интервала времени.

Частота очистки процедурного КЭШа (буфер плана запроса) должна совпадать с частотой обновления статистики. Так как MS SQL кэширует планы запроса для их повторного выполнения, это делается для экономии времени. И вполне возможна такая ситуация, когда после обновление статистики в КЭШе останется устаревшая информация о плане запроса, что приведет, к неоптимальном его выполнении.

Иногда возникает необходимость очистить кэш для определенной БД. Когда полностью очиненный кэш сделанный по необходимости для одной БД, может повлиять на производительность остальных работающий в одном экземпляре SQL. Есть недокументированная команда по очистки КЭШа БД. Насколько она безопасна, решать каждому ее использовавшему:

1. select name, database_id from sys.databases
// получаем идентификатор нужной БД.

2. DBCC FLUSHPROCINDB(<database_id>)
// очищаем кэш по id БД.

 

 

О возрастной «разнице»…

Есть одно не хитрое житейское наблюдение:

Дата выхода (технологическая, а не продажи вам лично) платформы 1С:Предприятия, операционной системы, субд, сопровождающего ПО и ВНИМАНИЕ! железа
должны различаться не больше чем на несколько лет!

Когда у Вас железо десятилетней давности, а платформы только только вышла редко это бывает хорошо. Точно также плохи и другие сочетания, например очень старая ОС и новое железо и т.п.

Это не означает что совсем не будет работать, но вы сами со временем поймете о чём эта мысль….

16 слотовые материнки для голдов и 1С

Наша статистика обращений клиентов показала, что материнские платы для процессоров intel gold ( т.е. шестиканальных ) в случае размещения количества слотов памяти 16 штук на плате ОЧЕНЬ ЧАСТО не дают той общесистемной скорости, характерной для правильно спроектированных, т.е. там где количество планок кратно числу 6.
Сначала неудачные материнки нам попадались только у супермикров, но недавно и HPE на лезвиях тоже не удачно засветилась.
Т.е. даже если вы в такую материнку для двух процессоров поставите 12 планок из 16, то всё равно полноценной производительности как на других платах Вы с высокой вероятностью не сможете получить. Рекомендуем избегать покупки серверов с такой конфигурацией слотов памяти. Падение производительности может быть в 2-3 раза. На нашем тесте Гилёва, вместо 55 баллов может быть только 12-30 баллов.
Нормальное количество слотов под память на материнке для для двухсокетных голдов — 12, 24, 48 и т.д.

 

Количество слотов можно посмотреть через ipmi в некоторых биос

BIOS: Processor C-states / All C-states

Cisco рекомендует для профиля электропитания High-Performance Computing для параметра All C-states установить значение enabled (и в этом профиле так и установлено), но для максимальной производительности параметр нужно не включать, а выключать disabled, а для этого настраивать свой план электропитания Custom.

BIOS: Collaborative Power Control

для биоса HPE параметр Collaborative Power Control отвечает за тем кто будет управлять понижением частот, биос или операционная система. Если этот параметр доступен для выбора, значит у вас стоит не лучшее значение другого параметра HP Power Regulator и необходимо исправить его , а здесь выключить.

 

BIOS: Minimum Processor Idle Power Package State

У BIOS HPE параметру Minimum Processor Idle Power Package State установите значение No Package State. Смысл настройки похож на http://www.gilev.ru/bios-minimum-processor-idle-power-core-state/ лишь с тем отличием что здесь идет настройка не для отдельных ядер процессора а целиком для процессора.

BIOS: Minimum Processor Idle Power Core State

У BIOS HPE параметру Minimum Processor Idle Power Core State установите значение No C-states . Это выключает энергосберегающие состояния, понижающие частоту процессора.

 

BIOS: Intel QPI Link Power Management

Для биос HPE у параметра Intel QPI Link Power Management ставьте значение Disabled для максимальной производительности 1С-систем.
QPI , он же Intel QuickPath Interconnect  —  последовательная кэш-когерентная шина типа точка-точка разработанная фирмой Intel для соединения процессоров в многопроцессорных системах и для передачи данных между процессором и чипсетом. Например внутри процессора LGA 1156 связь между ядрами и встроенным контроллером PCIe осуществляется через данную встроенную шину. Параметр биоса управляет управляет понижением электроснабжения шины. Если верить документации https://techlibrary.hpe.com/docs/iss/proliant_uefi/UEFI_Gen9_121417/s_Intel_QPI_LP.html то данный параметр хоть влияет на скорость, но не сильно.

BIOS: Override OS Energy Performance

Override OS Energy Performance — отмена влияние настроек ОС на энергосбережние

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

BIOS: Software Controlled T-States

Параметру “Software Controlled T-States” присвоить значение “Disable” чтобы выключить управляемый программно тротлинг (пропуск тактов) для производительности 1С-систем

 

BIOS: Energy Efficient Turbo

Energy Efficient Turbo во включенном состоянии означает, что электричество будет экономиться.

Для производительности 1С-систем выключайте этот параметр (Disable)

BIOS: ENERGY_PERF_BIAS_CFG

Параметру “ENERGY_PERF_BIAS_CFG” присвоить значение “Maximum Performance” для максимальной производительности 1С-систем

в более ранних версиях также может встречаться параметр Energy Performance

укажите значение Perfomance для производительности 1С-систем

BIOS: Intel SpeedStep (IST)

Старый режим энергосбережения процессора, предшествовавший Enhanced Intel SpeedStep Technology.

Intel SpeedStep

Для максимальной производительности 1С-систем выключайте этот режим, выберите значение Disable, а если его нет, то  Maximum.

В отключенном режиме частота меняться не будет.

BIOS: Turbo Boost

Turbo Boost — это технология компании Intel для автоматического увеличения тактовой частоты процессора свыше номинальной, если при этом не превышаются ограничения мощности, температуры и тока в составе расчётной мощности (TDP). Это приводит к увеличению производительности однопоточных и многопоточных приложений. Фактически, это технология «саморазгона» процессора. Есть турбобуст 2 и 3й версии.

Параметр может называть также Turbo Mode (одно и тоже).

или Turbo Boost Tehnology.

Для производительной работы 1С-систем его надо включать обязательно (Enabled).

В биосе для HPE для параметра Intel(R) Turbo Boost Technology выбирайте значение Optimized for Performance

BIOS: Package C State

Может также встречаться Package C State Limit или Package C State Support

Возможные варианты значений:
Auto — Значение выбрано автоматически.
Enabled — Параметр включен.
C0/C1 — Поддержка C0/C1 состояний пакета.
C2 — Поддержка C2 состояния пакета.
C3 — Поддержка C3 состояния пакета.
C6 — Поддержка C6 состояния пакета.

Для производительной работы 1С-систем выбирайте режим C0/C1 .

Таким образом для всех ядер процессора вы задаете общий режим работы (парковки ядер). В выбранном режим падения частоты процессора не происходит.

BIOS: CPU C6 Report

CPU CReport — позволяет запретить (параметр [Disabled]) / разрешить (параметр [Enabled]) переход процессора в энергосберегающее состояние C6 (когда в состоянии C3 значения регистров записываются в постоянную память). В таком режиме CPU функционирует при очень незначительном напряжении питания, достаточном лишь для выхода его из этого состояния. При этом минимальная нагрузка на линию +12В может опускаться до 0,5 А, поэтому блок питания должен поддерживать такую возможность (определено в спецификации ATX12V 2.3).

Важно отметить, что некоторые производители не отделяют этот режим от С3.

Для повышения производительности 1С-систем рекомендуем выключать данный параметр.

BIOS: CPU C3 Report

Состояние процессора С3 сбрасывает кэш и понижает частоту (и питание) процессора.

Тут надо пояснить, что ядра процессора могут иметь различные состояния.

позволяет запретить (параметр [Disabled]) / разрешить (параметр [Enabled]) переход процессора в энергосберегающее состояние C3 (когда частота опускается до 0 МГц, отключается кэш-память L1 и L2, но при этом сохраняются значения всех регистров). В таком режиме CPU функционирует при очень незначительном напряжении питания, которое требуется лишь для хранения данных из регистров.

Для повышения производительности 1С-систем рекомендуем выключать данный параметр (Disable).

BIOS: Enhanced Halt State (C1E) «Улучшенное состояние простоя»

C1E — одна из функций энергосбережения процессоров (называемого также Enhanced Halt State). Состояние C1E позволяет снизить напряжение при переводе процессора в состояние HALT, применяемое при низком уровне загрузки системы. При этом снижается уровень энергопотребления системы при низкой загрузке процессора. При этом снижается частота процессора (и вольтаж). Это в свою очередь негативно сказывается на скорости работы 1С-систем.

Рекомендуется выключать данный режим (в англоязычных настройках Disable).

Другие варианты обозначения данного параметра:

C1E

Особенности 8.3.17

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

Реализована возможность заимствования подписок на события и создания собственных подписок в расширении.

Реализована возможность определения IP-адреса компьютера, который начал сеанс работы с информационной базой. IP-адрес может быть определен не всегда и не для всех режимов работы.
Реализовано свойство IPАдресКлиента для объектов АдминистрированиеСеанс и СеансИнформационнойБазы.Реализована возможность отображения IP-адреса клиентского приложения в консоли управления кластером и стандартной обработке управления серверами.

Реализована возможность передачи в механизм системы компоновки данных менеджера временных таблиц. В механизмах компоновки данных разрешается использовать таблицы, которые не существуют в информационной базе, по аналогии с тем, как используются временные таблицы в языке запросов.
Для метода ПроцессорКомпоновкиДанных.Инициализировать() реализован параметр МенеджерВременныхТаблиц.

Реализовано индексирование файлов журнала регистрации. Индексация выполняется в фоновом режиме. Индексы хранятся в файлах с расширением .lgx в каталоге 1Cv8Log. Оптимизированы алгоритмы последовательного чтения файлов журнала регистрации.
Никаких дополнительных настроек для включения индексации не требуется. За счет индексации существенно ускорен отбор записей журнала регистрации по индексируемым полям.При открытии в конфигураторе файла журнала регистрации другой информационной базы, индексирование данного файла выполняется в фоновом режиме и индексный файл стирается после завершения работы с просматриваемого журнала регистрации.Для новой информационной базы значение параметра Разделять хранение журнала по периодам устанавливается в значение Неделя. Для существующих информационных баз рекомендуется установить разделение таким образом, чтобы размер одного файла журнала не превышал 100 Мбайт. Прекращена поддержка журналов регистрации, сформированных в системе «1С:Предприятие» версий 8.0 и 8.1.

При работе в клиент-серверном варианте ускорен запуск первого сеанса для доступа к информационной базе. Ускорение особенно заметно для конфигураций, содержащих большой объем метаданных.

Реализована более тонкая настройка поведения механизма решения системы линейных алгебраических уравнений.

Оптимизировано сравнение составных типов с не составными, если не составной тип может принимать значение NULL и в запросе используются временные таблицы.
Оптимизированы следующие операции:Сравнение вида A = B, где A – составной тип, а B – простой тип и может принимать значение NULL.
Сравнение вида ЕСТЬNULL(A, B) = C, где A – простой тип и может принимать значение NULL, а C – составной тип.
Сравнение вида Выражение1 В (ВЫБРАТЬ ….) и сравнение вида Выражение1 В (Список значений), где Выражение1 – поле ссылочного типа на несколько таблиц. При этом в списке выборки подзапроса или в списке значений должны находиться ссылки на разные таблицы и отсутствовать значение Неопределено.
Оптимизация применяется только в тех случаях, когда это не влияет на результат запроса. Оптимизация может привести к улучшению плана запроса и уменьшению времени компиляции запроса.

Если в запросе используется сравнение с пустой ссылкой, переданной в качестве параметра, то в СУБД передается запрос, в котором параметр заменен на константу. Оптимизация применяется в том случае, если кластер серверов использует СУБД IBM DB2, Microsoft SQL Server или Oracle Database.

В режиме совместимости Версия 8.3.10 и последующих, функция ПолучитьСтруктуруХраненияБазыДанных() возвращает таблицу значений, в которой колонка Индексы содержит короткие названия индексов. При этом имена индексов отображаются одинаково для любых СУБД.

При использовании файлового или клиент-серверного варианта (при использовании СУБД Microsoft SQL Server) оператор языка запросов В, который отвечает всем следующим критериям, всегда возвращает значение типа Булево:
Оператор В содержит подзапрос.
Подзапрос оператора В содержит операции ПЕРВЫЕ или УПОРЯДОЧИТЬ ПО.
В левой части оператора В и подзапросе содержатся значения разных типов или тип ЛюбаяСсылка.
Рекомендуется проанализировать подобные запросы и выполнить их рефакторинг, при необходимости. В режиме совместимости с версией 8.3.16 поведение не изменилось.

Библиотека OpenSSL обновлена до версии 1.1.0k.

Реализована возможность работы с СУБД Microsoft SQL Server 2019.

 

Подробнее:

https://dl03.1c.ru/content/Platform/8_3_17_1386/1cv8upd_8_3_17_1386.htm#19110485-11e0-11ea-8371-0050569f678a

 

Зачем аппаратному RAID-контроллеру нужна батарейка?

Зачем аппаратному RAID-контроллеру нужна батарейка?

Многим достаточно информации, что батарейка RAID контроллера ( от англ. Battery Back-Up Unit или BBU) нужна для того, чтобы при аварийном отключении электроэнергии данные из кэша контроллера не были утеряны, а были записаны на RAID-массив.

Обращаем ваше внимание, что наличие батарейки позволяет RAID-массиву работать в режиме Write Back (отложенная запись). Этот режим является оптимальным при записи информации на диск в случае наличия BBU на RAID контроллере.

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

Контроллер принудительно выключит режим WriteBack и включит режим Write Through (сквозная запись) при любом из следующих событий:
— отсутствие BBU;
— низкий уровень заряда BBU («батарейка села»);
— для некоторых контроллеров, у которых режим WriteBack платный и истек срок trial лицензии.

В том случае, когда выбран режим Write Through, подтверждение о записи информации поступит только после того, как данные будут записаны. Таким образом, режим Write Through замедляет работу системы, но гарантирует запись данных. Если же в сервере установлен контроллер с Battery Back-Up модулем и кэш-памятью, то оптимально использовать режима Write Back.

Пример разницы производительности RAID-массива (RAID5 из шести дисков Intel S3610, контроллер LSI MegaRAID SAS 9361-8i) при использовании режима WriteBack.
Примечание. Важно понимать, попадают ли используемые данные в кэш, или нет, от этого сильно зависит результат теста.

Результат теста RAID массива с выключенным режимом WriteBack (работает Write Through):

Результат теста того же RAID массива с включенным режимом WriteBack:

Подробно о тесте — http://www.gilev.ru/crystaldiskmark/ .

К слову, RAID10 для многопользовательской работы в 1С из тех же дисков оказался гораздо удачней (с включенным WriteBack):

P.S. Мы не рекомендуем размещать базы данных 1С на дисках Intel S3610.

 

 

 

Обновление статистики базы данных

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

Для того, чтобы гарантировать максимально правильную работу оптимизатора MS SQL Server рекомендуется регулярно обновлять статистики базы данных MS SQL.

Для обновления статистик по всем таблицам базы данных необходимо выполнить следующий SQL запрос:

exec sp_msforeachtable N’UPDATE STATISTICS ? WITH FULLSCAN’
Обновление статистик не приводит к блокировке таблиц, и не будет мешать работе других пользователей. Статистика может обновляться настолько часто, насколько это необходимо. Следует учитывать, что нагрузка на сервер СУБД во время обновления статистик возрастет, что может негативно сказаться на общей производительности системы.

Оптимальная частота обновления статистик зависит от величины и характера нагрузки на систему и определяется экспериментальным путем. Рекомендуется обновлять статистики не реже одного раза в день.

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

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

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

Например, в период минимальной нагрузки на систему — в ночные часы.

Можно сделать, например, так: В MS SQL:

1) Создайте новый план обслуживания

2) Создайте субплан (Add Subplan) и назовите его «Обновление статистик».

3) Добавьте в него задачу Update Statistics Task из панели задач:

4) Настройте расписание обновления статистик (рекомендация не реже 1 раза в день).

5) Настройте саму задачу:

5.1) Базу данных для который выполняется обновление статистики

5.2) Список таблиц установите «All» — это означает что будет обновлена статистика по всем таблицам БД

5.3) Укажите опцию Full scan

(Примечание. Такой режим будет эквивалентен скрипту

exec sp_msforeachtable N'UPDATE STATISTICS ? WITH FULLSCAN'
DBCC UPDATEUSAGE (dbname)

где dname имя вашей базы)

Также после обновлении статистики имеет смысл очистить процедурный кэш (иначе запросы будут выполнятся по планам из кэш, которые могли быть сформированы на основании устаревшей статистики.

Поэтому в субплан:

6) Добавьте задачу Execute T-SQL Statement Task.

7) Соедините задачу Update Statistics Task стрелочкой с новой задачей

8) В тексте созданной задачи Execute T-SQL Statement Task следует указать запрос «DBCC FREEPROCCACHE»

9) если у вас значительная нагрузка на базу в пиковые моменты (сотни пользователей, роботы-фоновики и т.п.) то наряду с параметром «Автоматическое создание статистики (AUTO_CREATE_STATISTICS)» будет полезно также для базы данных включить параметр «Автоматическое асинхронное обновление статистики (AUTO_UPDATE_STATISTICS_ASYNC)»

Важно знать:
Если включен параметр AUTO_UPDATE_STATISTICS (автоматическое обновление статистики), оптимизатор запросов определяет, устарела ли статистика, и при необходимости обновляет ее, если она используется в запросе. Статистика становится устаревшей, после того как операции вставки, обновления, удаления или слияния изменяют распределение данных в таблице или индексированном представлении. Оптимизатор запросов определяет, устарела ли статистика, подсчитывая операции изменения данных с момента последнего обновления статистики и сравнивая число изменений с пороговым значением. Пороговое значение основано на количестве строк в таблице или индексированном представлении.

Если используется версия до SQL Server 2014 (12.x), SQL Server применяет пороговое значение в зависимости от процента измененных строк. Это значение не зависит от числа строк в таблице. Пороговое значение:
Если на момент оценки статистических данных кратность в таблице не превышала 500, обновление выполняется для каждых 500 модификаций.
Если на момент оценки статистических данных кратность в таблице превышала 500, обновление выполняется для каждых 500 + 20 % модификаций

Начиная с версии SQL Server 2016 (13.x) и при уровне совместимости базы данных 130 SQL Server используется пороговое значение для динамического обновления статистических данных по убыванию. Значение изменяется в зависимости от числа строк в таблице. Оно вычисляется как квадратный корень из произведения текущего значения кратности в таблице и 1000. Например, если таблица содержит 2 миллиона строк, значение вычисляется как квадратный корень из (1000 * 2000000) = 44721,359. Благодаря этому изменению статистика для больших таблиц будет обновляться чаще. Но если уровень совместимости для базы данных ниже 130, применяется пороговое значение SQL Server 2014 (12.x).

Оптимизатор запросов проверяет наличие устаревшей статистики перед компиляцией запроса и до выполнения кэшированного плана запроса.
Параметр AUTO_UPDATE_STATISTICS_ASYNC (асинхронное обновление статистики) определяет, какой режим обновления статистики использует оптимизатор запросов: синхронный или асинхронный. По умолчанию параметр асинхронного обновления статистики отключен, и оптимизатор запросов обновляет статистику синхронно.
При синхронном обновлении статистики запросы всегда компилируются и выполняются с актуальной статистикой. Если статистика оказывается устаревшей, оптимизатор запросов ожидает появления обновленной статистики, прежде чем начать компиляцию и выполнение запроса. При асинхронном обновлении статистики запросы компилируются с существующей статистикой, даже если она устарела. Если на момент компиляции запроса статистика оказывается устаревшей, оптимизатор запросов может выбрать неоптимальный план запроса. Запросы, которые компилируются после выполнения асинхронного обновления, будут усовершенствованы благодаря использованию обновленной статистики.

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

Особенности 8.3.14

Добавлен встроенный веб-сервер (только для одной базы, из командной строки управление).

Реализован упрощенный OLAP . Теперь можно работать на чтение с копией таблицы с ведомой СУБД.
Реализовано событие технологического журнала <DBCOPIES>.Механизм копий базы данных требует лицензию КОРП.

При чтении помещеной копии таблицы в таблицу Inmemory используется новый механизм Дата акселератор. Добавлен в виде отдельной функции менеджера кластера.

Добавлен альтернативный механизм управления сервером 1С программно и кроссплатформенно, реализован объект АдминистрированиеСервера . Дополнительно смотрите https://wonderland.v8.1c.ru/blog/razvitie-klastera-serverov/

Улучшен механизм счетчиков  потребления ресурсов — реализована возможность отбора по признаку использования безопасного режима работы и профиля безопасности (добавлены новые типы фильтров).Для выражений отбора счетчика потребления ресурсов реализована возможность сравнения на неравенство. Для выражений отбора счетчика потребления ресурсов реализована возможность объединять «по И» несколько условий на один тип фильтра.

Реализован пакетный режим работы тонкого и толстого клиентских приложений. Пакетный режим распространяется от начала запуска клиентского приложения до окончания работы обработчика ПередНачаломРаботыСистемы модуля приложения. После окончания работы обработчика пакетный режим автоматически отключается. В пакетном режиме запуска подавляется вывод любых диалогов системы. Признаком пакетного режима работы клиентского приложения является команда командной строки запуска /DisableStartupDialogs.

Больше не поддерживается интерфейс 8.2

Уменьшено время полного пересчета итогов для регистров бухгалтерии и накопления в следующих случаях:

  • пересчет итогов во время операции Тестирование и исправление из конфигуратора;
  • использование метода ПересчитатьИтоги() при выполнении следующих условий:
    • монопольный доступ к информационной базе;
    • наличие административных прав у пользователя, от имени которого выполняется пересчет итогов;
    • метод исполняется в сеансе, в котором не используется ни одного разделителя.

Ускорено выполнение реструктуризации информационной базы при использовании СУБД Microsoft SQL Server и IBM DB2.

Уменьшилась вероятность одновременного закрытия множества соединений с Microsoft SQL Server, что положительно влияет на производительность работы с TempDB.

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

Для динамического списка реализована возможность указания полей, которые будут использоваться в качестве ключевых полей выборки. Повышена производительность при использовании динамических списков с отсутствующей основной таблицей. Например, для динамического списка без основной таблицы, стало возможно использование группировки. Дополнительно смотрите https://wonderland.v8.1c.ru/blog/razvitie-dinamicheskikh-spiskov-s-proizvolnymi-zaprosami/

 Больше не поддерживается IE. У поля, имеющего вид ПолеHTMLДокумента, изменится с COMОбъект на ВнешнийОбъект. Ухудшится Windows-совместимость. Дополнительно смотрите https://wonderland.v8.1c.ru/blog/perevod-klientskikh-prilozheniy-dlya-windows-na-ispolzovanie-webkit-optimizatsiya-otobrazheniya-html/

В тонком, толстом и веб-клиентах, форма снимает блокировку объекта через 1 минуту после снятия признака модифицированности.(раньше снималась при закрытии формы)При работе под управлением СУБД PostgreSQL, в технологический журнал (событие <plansql>) помещаются планы запросов для запросов UPDATEDELETE и INSERT. (Раньше был только SELECT)

 Реализовано отображение критических ошибок оптимизированного механизма обновления конфигурации базы данных в конфигураторе и в событии <EXCP> технологического журнала.

В технологическом журнале реализованы свойства DbmsDatabaseDBCopy для событий обращения к СУБД (DB2DBMSSQLDBPOSTGRSDBORACLE), событий EXCP и SDBL.

 Добавлен Механизм решения систем линейных алгебраических уравнений

смотрите https://wonderland.v8.1c.ru/blog/mekhanizm-resheniya-sistem-lineynykh-algebraicheskikh-uravneniy/

Подробнее http://downloads.v8.1c.ru/content//Platform/8_3_14_1565/1cv8upd_8_3_14_1565.htm

Особенности 8.3.13

Реализована поддержка СУБД PostgreSQL версии 10. (смотрите также https://postgrespro.ru/blog/news/3876555?fbclid=IwAR0ivfJaOBWJ7p7IDK4-nAdS3cBmHmtgV6aEcdsA9fB_T8_CkDkWPhdwK1w)

Оптимизация работы с PostgreSQL
Оптимизирована работа виртуальных таблиц оборотов регистров накопления и бухгалтерии в случае использования группировок по дню, месяцу или году, а также при использовании функции языка запросов НачалоПериода(). Оптимизация используется для любых версий поддерживаемых СУБД, кроме Microsoft SQL Server, где оптимизация действует, начиная с версии 2012.

 

Добавлен механизм контроля потребления ресурсов. Смотрите https://wonderland.v8.1c.ru/blog/mekhanizm-upravleniya-potrebleniem-resursov/

факты превышения счетчика фиксируются в технологическом журнале (событие <ATTN>)

Реализована возможность оценивать использование процессора за время работы сеанса:

  • за текущий серверный вызов;
  • за последние 5 минут;
  • за все время работы сеанса.

Для события <CALL> реализовано свойство CpuTime, которое содержит длительность завершившегося серверного вызова, в микросекундах.

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

Новые конструкции запросов. Реализована возможность создания поля с уникальными (в рамках одной таблицы), последовательно возрастающими значениями. Реализована функция языка запросов АВТОНОМЕРЗАПИСИ(), которая может быть использована только при создании временной таблицы.Не поддерживается использование функции АВТОНОМЕРЗАПИСИ():
  • в запросах, содержащих ОБЪЕДИНИТЬ на верхнем уровне;
  • в запросах, не формирующих временную таблицу;
  • вне списка выборки;
  • в выражениях.

Реализован объект КонстантаКлючЗначения.Для менеджера константы реализованы методы СоздатьКлючЗначения()Новый формат временных файлов будет использоваться после отключения режима совместимости. В режиме совместимости с версией 8.3.12 поведение не изменилось.

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

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

Фоновики.
Реализована возможность ожидать завершение работы одного или нескольких фоновых заданий в течение заданного промежутка времени. Реализован метод 
ОжидатьЗавершенияВыполнения() для объектов ФоновоеЗадание и МенеджерФоновыхЗаданийМетод ОжидатьЗавершения() считается устаревшим и не рекомендуется к использованию. Рекомендуется выполнить анализ прикладного решения и изменить алгоритмы работы с фоновыми заданиями.
Оптимизирован запуск и ожидание завершения фоновых заданий

 

Старт клиента.
Реализована возможность отключать отображение заставки при старте клиентского приложения. Реализован параметр командной строки запуска клиентского приложения DisableSplash. Параметр доступен для тонкого клиента, толстого клиента и веб-клиента.

Оптимизирована и ускорена отрисовка заголовков страниц (закладок) при работе в веб-клиенте.

Обновление используемых библиотек

  • Библиотека LibEtPan обновлена до версии 1.8.
  • Библиотека WebSocket обновлена до версии 0.7.0.
  • Драйвер Micosoft JDBC Driver for SQL Server обновлен до версии 6.2.
Маки.
Реализовано событие технологического журнала <MACCERT>.


Про диски для 1С

Поговорим про загрузку оборудования.
Замеры загруженности оборудования также очень важны. У для этой цели реализован сервис hardware, дающий отчёт о превышениях нормативов.
В настольной книге эксперта происходит отсылка к штатным механизмам в рамках операционной системы. Кроме того, вы самостоятельно можете использовать коммерческие утилиты, собирающие загруженность оборудования. Мы сосредоточились не на сборе данных, а на дальнейшей интерпретации собранных значений. Как показала наша практика, имея конкретные цифры, например о загруженности дисковой подсистемы, разные специалисты делают разные выводы. Мы посчитали правильным оттолкнуться не от того, что написано у вендоров в описании счётчиков, а от оценки того, насколько в реальности апгрейд исследуемого компонента сервера может помочь в решении задачи. Например, мы знаем, что решаемая задача – это ускорение оборотно-сальдовой ведомости для бухгалтера. Мало кто может вручную, посмотрев на график любой из характеристик дисков, чётко сказать – коррелируют ли цифры с событиями построения ОСВ и насколько быстрее ОСВ будет работать при замене исследуемых дисков.
Многие администраторы при апгрейде думают, что главная задача – на новом оборудовании получить более быстрое выполнение операции в одном потоке. По нашему опыту, при эксплуатации высоконагруженных информационных систем бОльшим приоритетом является обеспечение неснижения текущей скорости работы в пиковые моменты нагрузки. Зачастую маркетинговые описания вендорами характеристик продаваемого оборудования, не помогают при принятии решения.
Сложилась популярная практика: сравнивать диски по иопсам. Сделаем небольшое отступление и поясним, что иопс – это количество операций ввода-вывода за секунду.
Давайте поставим себя на место продавца, который хочет продать диски. Понятно, что нам нужно всякими правдами и неправдами показать наиболее выгодную информацию. Если при этом часть правды выгоднее не говорить, то кто-то может посчитать, что это не обман. Ярким примером некорректного сравнения иопсов могут быть дисковые подсистемы, построенные на SSD дисках и на SAS дисках. Сравнивая только по иопсам, можно не заметить легко, что время отклика у этого оборудования будет разным. Или например, максимально допустимая глубина очереди к диску, после которой начнётся резкая деградация производительности.
Вот как раз настал момент, когда на словах есть что рассказать, а картинок с обоснованием никаких показать не могу, потому что неразглашение. Как говорят — джентльменам у нас верят на слово.
В качестве примера вспоминается случай на одном из наших проектов, когда в целом у клиента на довольно насыщенной системе в много сот пользователей дисковая подсистема вполне адекватно справлялась с нагрузкой в большинстве случаев, но иногда необъяснимо что называется становилась колом, работать было невозможно. Мы поставили замеры, дождались очередной затык, и побежали смотреть в сервисы. Нашли, что затык начался с образования гигантской очереди к дискам, что-то порядка нескольких сот тысяч операций. Ну а так как всё это время продолжают поступать и новые заказы на операции, дисковая подсистема потихоньку разгружала очередь (условно по доле процента в секунду, то есть совершенно недостаточно). Ну а в качестве меры пожаротушения применялась перезагрузка сервера СУБД. Каждый такой инцидент выливался в простой всей учётной системы компании минимум на полчаса, а то и больше — сначала минут 10-15 все лицезреют собственно затык, попутно вздыхая “ну вот опять”, затем согласовывали очередной рестарт системы, ну и плюс сам рестарт занимает существенное время. Руководство компании это категорически не устраивало, поэтому дали добро на срочный подбор с нашей помощью более быстродействующей дисковой подсистемы. Старая СХД была на обычных SAS дисках, которых было много, новую подобрали на твердотельных. Поставили новую систему, время обслуживания операций в обычное время сократилось условно с пары десятков миллисекунд до пары миллисекунд.
Как вы понимаете, никто из пользователей этой разницы не ощутил. Зато когда в очередной раз возник тот самый затык — он возник в стиле “что-то у нас интерфейс 1С затормозился на полминуты”, а по счётчикам было видно, что изначальная очередь была примерно такая же, но очень быстрые диски очень быстро её раскидали, секунд за 30-40. Ну а потом мы и источник такого затыка нашли, очередная гигантская избыточная выборка в аналитический отчёт. И как обычно в таких случаях и оказывается, анализ показал, что подавляющее большинство выбираемых данных для целей отчёта просто не нужны, можно сделать, чтобы работало значительно быстрее, и значительно дешевле по ресурсам.
Есть и другие факторы, характеризующие диски, которые мы (как уже и было сказано во введении) можем посчитать несущественными и откинуть. Особо популярной является ситуация, когда происходят тендеры и покупается более дешёвое оборудование, а решение о том, что два различных компонента являются аналогами, принимает человек без достаточного опыта и знаний данного оборудования.
Далее про тесты и замеры, переходим к дисковой подсистеме. Есть много различных методик, порой очень сложных, с кучей вариантов тестирования, где один прогон теста может загружать систему на целые часы.
А мы используем Crystal Diskmark, пусть и не исчерпывающий тест, но очень быстро дающий неплохое представление о производительности дисковой подсистемы.

Надо сказать, что выясняя скорость компонентов оборудования, мало слов сказано про то, как это надо делать. Очень значимыми условиями тестов являются: 1) возможность проведения теста эксплуатируемого оборудования без остановки работы предприятия с получением достоверной исчерпывающей информации; для того, чтобы оценить линейную скорость записи или чтения одного потока, вовсе не обязательно каким-либо тестом многопоточно «класть» всю дисковую подсистему. Даже копирование файла размером больше кэша контроллера и дисков позволяет получить частичное представление о характеристиках системы. В реальной жизни проведение теста, оценивающего скорость работы только одного узла – необходимо, но не достаточно. Сумма скоростей тестов по компонентам может быть не равна суммарной реальной скорости системы. Надо помнить о том, что часто возможности оборудования могут использоваться программным обеспечением лишь частично, или не использоваться вовсе. Например, вы купили новое оборудование (процессор), а ваше текущее программное обеспечение ничего не знает о новых процессорных инструкциях и не использует их. Таким образом, тест процессора может показать более оптимистичные цифры, чем в реальности будут получены в процессе эксплуатации системы. Не стОит также забывать о программных ошибках в коде, которые присутствуют в приложении, но отсутствуют в тесте и влияют на производительность. В заключение хочется отметить будущее и настоящее! за NVMe дисками с технологиями типа 3D Xpoint (Optane) и полками на их базе. Смешно и грустно смотреть, как крупные организации сегодня покупают полки десятками дисков SAS — технологии остановившейся десять лет назад.

см. также IOps (операций в секунду) не рекомендуем использовать для расчета оборудования

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

В нашей практике часто бывает так, что клиент не может самостоятельно сформулировать проблемы производительности. Как ему помочь?
Реальные клиенты не читали книжку 1С-Эксперт, ни один нормальный руководитель при решении этой задачи никогда не будет читать пункт 2.4 данной книжки, который называется “Бизнес-процесс решения проблем по ключевым операциям”.
Прежде чем начать что-то исправлять – надо сначала помочь клиенту сформулировать свои желания в критериях, которые можно объективно измерить. Есть огромное желание не делать данный пункт, пропустить его, так как он не кажется важным. И только многократный реальный печальный опыт может нас в этом переубедить, что мы вам дальше и покажем. Если нет объективных критериев – клиент (или пользователь клиента) всегда может потом сказать, что либо лучше не стало, либо сразу так хорошо было.
Есть другой ряд проблем, который менее очевидно и связан с формализмом при реализации данной методики.
Например, мы подпиской на все события проведения документов собираем статистику проведения данных документов. При анализе собранных значений, например по документу реализации товаров и услуг, может выясниться, что проведение этой операции имеет несколько явных пиков в районе 2 секунд, 10 секунд и 50 секунд. То есть ряд пользователей, как правило, видит время в районе 2 секунд, значительная часть пользователей видит время в районе 10 секунд, а часть в районе 50 секунд. При этом нельзя сказать, что такое разное поведение связано с конкретными пользователями. Одна из проблем, которая возникает при формализме, связана с нежеланием вникать в детали. Например, скорость может сильно зависеть от количества строк в табличных частях документа. Логично будет ожидать, что документ с десятком строк в ТЧ будет проводиться в течение нескольких секунд, в то время как 9000 строк вряд ли проведутся за то же время.
Конечно, бизнес может не различать объём или количество строк в ТЧ и для него критична любая операция, которая длится более пяти секунд, так как по каким-то специфичным особенностям бизнеса более долгая операция может приводить к возникновению убытка. Но в любом случае, в поиске решения нам придётся показать бизнесу, что решение напрямую связано с составом ТЧ и количеством строк в ней.
Хотелось бы пару фраз рассказать о выражении «плохой код»: разные пользователи информационной системы давать оценку качеству кода могут диаметрально противоположную. Настоящей дилеммой является выбрать приоритеты между скоростью работы каждого конкретного пользователя, или их одновременной коллективной работе и взаимодействием друг с другом. Одни задачи требуют максимальной производительности в рамках одного потока, например какая-то массивная загрузка данных, расчёт себестоимости. Другие задачи требуют аккуратного, не чрезмерного обращения к данным, неиспользование всех аппаратных ресурсов, чтобы обеспечить возможность коллективной работы в одной информационной системе на одном сервере всех пользователей. Далеко не всегда можно например сказать, что квотирование ресурсов целесообразно для решения однопоточной задачи, где важно как можно быстрее получить результат. Возникает необходимость на уровне бизнеса расставить приоритеты. Будет ли эта однопоточная задача важнее коллективной работы, или эта работа важнее однопоточной задачи.
Вот на слайде приведён пример однопоточной задачи, которая важнее коллективной работы.
Ещё один яркий пример неоднозначности того, что можно считать плохим кодом, является алгоритм партионного учёта (ФИФО/ЛИФО). Данный алгоритм может быть реализован различными способами, но при этом изначально задача партионного учёта для правильной работы требует монопольного захвата конкретной партии. С точки зрения алгоритма и целостности данных не могут два пользователя одновременно изменить информацию о партии. Однако, если подходить к этому вопросу с позиции коллективной работы, то должно быть очевидным, что требования алгоритма изначально являются плохими для обеспечения коллективной работы в этой информационной системе. На фоне выше сказанного можем привести пример реального кода, когда параллельность попираться совсем. В документах двигающих остатки в комплексной конфигурации перед тем как “свернуть резервы” накладывается блокировка на константу. У любой организации, у любых пользователей которые между собой не пересекаются блокировка все равно будет. Потому что блокируется константа — одна конкретная запись для любых документов данного вида, не зависимо от аналитики. И даже если такие документы будут быстро проводится, то о полноценной параллельности такого кода говорить не приходится, параллельности ввода данных нет.

Про виртуализацию и 1С

Поговорим о виртуализации.
Последние несколько лет стала очень широко использоваться виртуализация, администраторы очень быстро увидели плюсы для себя: очень удобно работать с такой машиной, легко переносить её между несколькими физическими серверами, можно настроить отказоустойчивую схему, когда одну виртуальную машину могут обслуживать более одного физического сервера. Кроме того, виртуалка перезагружается на порядок быстрее. Кто не знает, приличный физический сервер может спокойно перезагружаться по 10-15 минут: пока всё потушит, пока сразу после старта неспешно всё у себя проверит, затем даст возможность контроллерам дисковых накопителей потестировать себя и диски всласть, и только после этого начинает грузить операционную систему. Виртуальный же сервер все проверки проскакивает за секунды, с точки зрения железа это всего лишь обычная программа. А для руководства компании мощнейший плюс виртуализации состоит ещё и в том, что можно взять например десять устаревших серверов, и запихнуть их функции на один физический, получается серьёзная экономия что на модернизации оборудования как такового, что на площади серверной комнаты, что на электричестве, нужном для работы и охлаждения сервера. Или можно арендовать в дата-центре вместо десяти слабеньких серверов один сильненький за меньшие суммарно деньги. К тому же, если например раньше вам потребовалось бы увеличить в два раза мощность двух из этих десяти серверов, это могло повлечь за собой необходимость апгрейда этих серверов. А в виртуальной системе достаточно изменить настройки выделения ресурсов. Ну и если вдруг мощности конкретного хост-сервера перестало хватать, можно вынести отдельные виртуалки на другой сервер, причём в некоторых случаях можно их даже не выключать.
Ну то есть замечательная технология. А есть ли у неё минусы? К сожалению, есть.
Главный и основополагающий для нас минус — это снижение производительности (по нашим данным, вендоры сообщают о замедлении относительно физических серверов от 9 до 24%). Причём снижение это идёт сразу по нескольким уровням. Во-первых, что бы там ни рассказывали производители процессоров и виртуальных сред, технология виртуализации сама по себе предполагает выполнение команд не в оригинальной среде, а в её имитации, которая называется эмуляцией. Эмуляция по ресурсам совсем не бесплатна, она отнимает в лучшем случае несколько процентов производительности по сравнению с исполнением того же кода на этом же оборудовании, но без виртуальной среды.
Во-вторых, свои штрафы накладывает эмуляция сетевых интерфейсов и эмуляция сетевых дисков, которые тоже отнимают каждая свои процентики.
Что делает уважающий себя администратор, дорвавшийся до виртуалок? Он берёт старый сервер, где крутились одновременно сервер 1С и сервер СУБД, и раскладывает роль сервера 1С в одну виртуалку, а роль сервера СУБД в другую. С точки зрения отказоустойчивости и балансировки нагрузки — он большой молодец. Такую схему разносить по нескольким физическим серверам проще, распределить нагрузку по незагруженным серверам например.
Однако схема такая сразу начинает работать медленней. Причём, например результат нашего теста может упасть сразу в два раза.
Почему? Например, потому что раньше сервер 1С и сервер СУБД внутри одной операционной системы общались между собой по протоколу Shared Memory, и это было очень быстро. А теперь используют сетевой интерфейс, а даже внутри одного сервера виртуализация сети- задача по ресурсам совсем не бесплатная.
А кроме того, есть ещё и неудобные для 1С сочетания факторов, вот как на снимке: использование сетевого интерфейса WMXNET3 практически гарантирует узкое место на передаче данных 1С по сети.
Есть ещё ряд факторов, которые могут ухудшить производительность виртуальной среды относительно выполнения той же программы на физическом железе без виртуализации.
Мы же выделим один наиболее значимый. Теперь кроме всех прочих факторов, добавляется ещё один, совершенно непредсказуемый для виртуальной машины: на этом же железе может исполняться неизвестное количество других виртуальных машин, нагрузка которых может колебаться от условного 0 до 100%. Благодаря этому можно наблюдать например такую картину: сидит один пользователь в базе, на сервере 1С кроме него никого нет, и запускает один и тот же несложный отчёт, например взаиморасчёты по отдельным контрагентам с расшифровкой по документам. Объём данных примерно одинаковый, и время формирования должно быть примерно одинаковым, но нет! То отчёт формируется за секунду, а то приходится ждать целую минуту. Почему? А потому что на этом же физическом сервере в это время например другой бухгалтер в другой базе на другом сервере запустил закрытие месяца, и сервер страшно занят. Изнутри виртуальной машины вот это внешнее влияние отследить совершенно никак невозможно, только с тоской наблюдать, как скачут замеры времени ключевых операций.
Что делать в данном случае? Обеспечить гарантированно высокую производительность системы можно только в том случае, когда ей никто не может помешать. То есть ответ простой: если высокая производительность какой-то конкретной базы 1С является ключевым показателем работы сервера, то всех остальных пассажиров приходится подвинуть. Либо на конкретном примере с объективными замерами показываем админам, что разница в производительности слишком велика, чтобы её игнорировать, и дальше конкретно эта база 1С обслуживается физическим сервером без виртуализации, либо разгружаем виртуальный сервер от всех сторонних виртуальных машин, и эта база 1С обслуживается виртуальным сервером, но её производительность в любом случае становится стабильной.
В книжке 1С эксперта на 22й странице методика считает, что наиболее значимый вклад составляют плохая работа запроса и плохая работа кода. При этом способность среды выполнять действия с необходимой скоростью не рассматривается. Считается, что во-первых скорость среды неизменна, хотя в виртуальной среде это может быть совсем не так. Кроме того, схожая по внешним признакам среда на практике может кардинально отличаться способностью выполнять такой же объём работ за единицу времени. На сервер может быть возложена куча других задач («резиновый сервер»: купили дорогой, надо использовать ) Обычно, когда проводят нагрузочное тестирование – его всегда проводят с имитацией деятельности в базе, но в реальной жизни надо учитывать и имитировать любую другую стороннюю нагрузку (веб-сервер, терминальный сервер, другая ERP), которые могут отнимать непредсказуемую часть ресурсов сервера. В учебнике приводится упрощённый вариант, которого в жизни обычно не бывает. Написанное в учебнике правильно, но этого явно недостаточно для того, чтобы решать задачу по-настоящему. Умение разложить состав нагрузки по составляющим источникам позволяет существенно сократить объём денег и усилий, необходимых для решения проблем.
Кроме того, многие компании, обеспечивающие работу в ЦОД, зачастую не могут сказать – где находится физически виртуальная машина. Таким образом, эксплуатируемое приложение в виртуальной среде, не привязанное к физическому оборудованию, при частой миграции виртуальной среды между узлами, может кардинально менять скорость исполнения в виртуальной среде. Также вы можете встретиться с ситуацией, когда несколько айти-специалистов берут из одного источника один и тот же образ виртуальной машины, запускают на своих компьютерах с максимально похожими характеристиками, и получают совершенно разные результаты тестов производительности. Более того, даже запуская на одном компьютере несколько копий одного образа, неожиданно выясняется необходимость понимания механизма привязки виртуальных ядер к физическим ядрам процессора. Например, когда на четырёхсокетной машине виртуальная система выбирает ядра разных процессоров, скорость отличается от той же самой виртуалки, ядра которой привязаны к одному физическому процессору.
В качестве ещё одного примера: у нас в своё время был неприятный опыт отладки запроса на базе 1С, размещённой в облаке Амазон. Сервер 1С был развёрнут на одной амазоновской виртуалке, сервер СУБД на другой. Сидим на тестовом сервере в одном сеансе, никого больше нет. Запускаем один и тот же довольно несложный запрос и замечаю, что время его выполнения может отличаться на порядок. То есть к примеру он может выполниться за 3 секунды, в следующий раз за 25, потом за 10. Внутри тестовых серверов не происходит ничего, что могло бы объяснить такую разницу. Всё зависит от того, сколько и каких виртуалок ещё развёрнуто на тех же физических серверах, какую они генерируют загрузку процессоров, памяти, дисков и сети.
В жизни бывают ещё более сложные задачи, когда из-за несущественных на первый взгляд факторов может измениться скорость среды.

Как измерить всё?

Нередко клиенты к нам обращаются с формулировками вида “всё плохо” или “нет каких-то отдельных долгих операций, медленно работает всё”. Как замерять всё?

Возможно, вы ещё не сталкивались с такой ситуацией, но мы думаем, что вы с ней столкнётесь. Продавцы железа, которое вы приобрели, утверждают что оно замечательное. Продавцы ОС и бизнес-приложений тоже говорят, что у них всё хорошо работает. Согласно рекомендациям из книжки 1С-Эксперта, вы посмотрели: нет ли ярко выраженной долгой операции, и в коде нет явно лидирующих операций. Возможно, ваша виртуалка тоже замечательная. Нет ожиданий ни на процессоре, ни на дисках, ни на СУБД!
На бумаге всё замечательно, а по факту работает очень медленно.
Для решения проблемы в качестве начальной точки отсчёта мы много лет назад разработали тест, который стал в среде 1С-ников известен как “тест Гилёва”, и показывает способность системы выполнять эталонный объём работы за единицу времени. Можно по-разному объяснять популярность теста, но лучше мы покажем практические примеры его применения.
Приведу один из наиболее ярких примеров, когда благодаря этому тесту мы смогли с минимальными затратами денег и времени выявить проблему с аппаратной частью сервера:
Есть некий сервер в виртуальной среде, внутри сервера по счётчикам всё в рамках приличий — ровно как я и говорил чуть раньше: нет ожиданий на процессоре, нет ожиданий на дисках, нет ожиданий на СУБД. При этом в 1С всё работает страшно медленно и очень печально. Простой документ открывается по 5 секунд, а проводится 10 секунд, простой отчёт формируется по 30 секунд, при этом опять же замеры в 1С не показывают каких-то мега-лидирующих операций, просто всё выполняется долго. Пользователи очень недовольны, требуют жертвоприношений. Оборудование сервера при этом достаточно адекватное нагрузке, на других проектах с подобным оборудованием у пользователей картина производительности радикально лучше.
Результат нашего теста на тот момент составил абсолютный антирекорд, меньше мы за несколько лет ещё не встречали.
В очередной раз мы пронаблюдали, что оценка теста хорошо коррелирует с оценкой комфортности работы пользователей. Следственные действия внутри сервера не выявили явных виновников, поэтому попробовали искать их снаружи. Решили проверить фактор виртуальной среды, использованной клиентом. У клиента был ещё один сервер с аналогичным оборудованием, попросили развернуть на нём такую же систему, но без виртуализации, так сказать на голом железе. Результат нашего теста вырос во много раз по сравнению со своим виртуализованным двойником. Пользователи немедленно обнаружили, что без виртуализации всё летает, документы открываются и проводятся за секунду, отчёты формируются за несколько секунд.
Рассмотрим ещё один пример применения нашего теста для оценки влияния среды.
Вот сервер клиента, с неким процессором он дал результат в 12 баллов. По субъективной оценке нашего теста, это соответствует оценке “Плохо”. При этом настройки электропитания в Windows выставлены в “максимальная производительность”. Утилита CPU-Z показывает номинальную частоту процессора, то есть заявлено 2 ГГц, и показывает 2 ГГц. Ну то есть вроде бы всё выглядит прилично, как заявлено — так и работает.
Если немного отвлечься в теорию, то частота процессора — это количество операций, выполняемых процессором в единицу времени (сферически). Наш тест позволяет увидеть — за сколько времени в реальной жизни одни и те же процессоры выполняют одну и ту же работу на разных серверах разных клиентов. В теории одинаковые процессоры с одинаковой частотой, выполняя одну и ту же работу, должны выдавать один и тот же результат. Но в жизни всё сложнее. Есть дополнительные факторы, которые оказывают влияние на скорость. В рассматриваемом примере тест выдал значение в два раза меньше, чем наблюдалось на других серверах с таким же процессором. На скорость работы процессора могут значительно влиять настройки BIOS, которые по умолчанию могут быть нацелены на энергосбережение в ущерб производительности. К примеру, включение технологии Turbo Boost у процессора по нашим наблюдениям даёт прирост результатов теста от 10 до 20%, а изменение настроек электропитания с “оптимальных или сбалансированных” на “максимальная производительность” — до двух раз, что в нашем случае и произошло, результат теста в общем итоге улучшился в два раза и составил 24 балла. Производительность 1С также соответственно выросла.
Вообще, в характеристиках оборудования может быть чересчур много маркетинга. Что мешает вендору слегка приукрасить преимущества и скрыть недостатки? Зато у вас есть наш тест, и вы можете сравнить разницу в производительности различного оборудования применительно к задачам 1С и в составе настроек этого оборудования.
Вот я рассказал два примера, а теперь ещё раз: как интерпретировать результат теста. Тест только показывает способность системы выполнить некий эталонный объём работы за единицу времени. Что является одним или несколькими факторами замедлений — тест не показывает. Более того, узкие места есть всегда. Они могут ухудшать работу как значительно, так и быть совсем незаметными.
Небольшие цифры баллов в тесте может быть косвенным признаком значимости узкого места.
Как вы возможно поняли, тест является синтетическим. Если у вас стоит потребность оценить скорость выполнения именно вашего объёма работы, который может совершенно по-другому исполняться на оборудовании, то конечно вам нужно написать свой тест. Он будет не универсальным, но даст точную оценку именно для вашей задачи.
25 баллов в нашем тесте для одного сервера может быть отличным достижением, в то время как 25 баллов для другого сервера достаточно плохо.
Ценность теста — в накопленной за многие годы статистике, которая позволяет для вашего конкретного компьютера сформировать сравнительную оценку. Неожиданным положительным побочным эффектом нашего теста оказалась возможность оценивать влияние такого фактора, как версия платформы 1С Предприятия. Не наша заслуга, но пользователи нашего теста на основе полученных результатов в своё время массово обратились в фирму 1С с жалобой на проседание скорости в очередном релизе платформы 1С:Предприятие. Падение производительности объективно можно было оценить только благодаря такой обширной статистике, что позволило фирме 1С не тратить много сил на перепроверку достоверности жалоб и успешно выпустить новый более быстрый релиз.
Не удивляйтесь, если наш тест покажет невысокие значения при том, что по отдельности каждая компонента должна работать быстрее. Влиять на конечную скорость может всё, даже несовместимость этих компонентов. Можно сверхбыстрый SSD подключить к шине SATA2 и урезать его скорость. А может сложиться и ещё хуже.

Итерационный подход

Очень сложно решать задачи, связанные с параллельностью работы пользователей. При диагностике мы ищем узкие места. Но часто в подобных ситуациях узких мест много.
Может быть даже целый каскад значимых узких мест, и количество их непредсказуемо.
Для бизнеса это плохо слабой предсказуемостью трудозатрат. Пока одно узкое место не расшито — можно не увидеть причин следующего узкого места, а значит и не оценить его стоимость. Такие проблемы решаются многоитерационным способом. Как говорят профессионал — это тот, кто много раз наступил на грабли.
Нам нравится считать себя профессионалами, и поэтому мы не сможем вам дать формулу подсчёта стоимости при итерационном подходе. Это вызывает сильное непонимание у бизнеса, и часто звучат фразы типа “не надо юлить и разводить нас на деньги”. Правильным ориентиром будет: сначала предварительная оценка эффекта от расшивания самого узкого места. Если количество блокировок не уменьшится, то это вовсе не означает, что не стало лучше. В апдексе будет например видно, что интенсивность ввода данных возросла. И только вследствие возросшей интенсивности появились новые блокировки.
Затем будет следующая итерация, где мы оцениваем суммарную интенсивность блокировок, группируя их по месту исполнения кода.
Используя правило Парето (расшифровать про 20-80), выясняем новое наиболее узкое место с учётом количества пользователей, которые страдают от этих блокировок, таблиц на которых возникают эти блокировки.
Можно не знать, как работает бизнес-логика приложения, но при этом понять, что избыточные блокировки часто возникают из-за отсутствия используемой аналитики, по которой различается конкурирующая активность различных пользователей. Например, мы часто видим, что во многих решениях закрытие месяца происходит по предприятию в целом, а не по организации в частности. Нет измерений и индексов с ведущей организацией. Из-за этого все организации вынуждены ждать ту, которая закрывает месяц в настоящее время.
Некоторые блокировки можно было бы вообще избежать при более активном взаимодействии программистов и бизнеса. Не зная точно, нужно ли накладывать блокировку, и не желая выяснять у бизнеса, программист использует пессимистичный стиль “пусть будет блокировка на всякий случай”. Мы часто переспрашиваем бизнес, а нам нередко отвечают “да мы эти таблицы вообще не используем, их можно отключить”.
Ещё одной итерацией в нашей практике часто бывает ситуация, когда якобы кто-то всех блокирует и всем плохо, но никто не знает — кто и что делает. Эта задача также легко программно решается, используя собираемые логи об активности пользователей. При желании можно написать код, который будет управлять наложением блокировок, анализируя текущую ситуацию более продвинуто, например оценивая роль сотрудника в компании, критичность бизнес-операции для бизнеса.
Я не буду пересказывать книжку “1С-Эксперт”, так как там достаточно большой раздел посвящён решению проблем с блокировками.
Главное здесь — не хвататься за всё сразу, а расставить приоритеты по каждому конкретному случаю и решать каждый случай отдельно, не позволяя другим сотрудникам компании пытаться всё смешать в одну кучу. Не позволяйте им обобщать и выбрасывать важные различия в деталях.

Postgres параметр SYNCHRONOUS_COMMIT

Включает/выключает синхронную запись в лог-файлы после каждой транзакции. Включение синхронной записи защищает от возможной потери данных. Но, накладывает ограничение на пропускную способность сервера. Вы можете отключить синхронную запись, если вам необходимо обеспечить более высокую производительность по количеству транзакций. А потенциально низкая возможность потери небольшого количества изменений при крахе системы не критична. Для отключения синхронной записи установите значение off в этом параметре.

Еще одним способом увеличения производительности работы PostgreSQL является перенос журнала транзакций (pg_xlog) на другой диск. Выделение для журнала транзакций отдельного дискового ресурса позволяет получить получить при этом существенный выигрыш в производительности 10%-12% для нагруженных OLTP систем.

В Linux это делается с помощью создания символьной ссылки на новое положение каталога с журналом транзакций.

В Windows можно использовать для этих целей утилиту Junction. Для этого надо:

  1. Остановить PostgreSQL.
  2. Сделать бэкап C:\Program Files\PostgreSQL\X.X.X\data\pg_xlog.
  3. Скопировать C:\Program Files\PostgreSQL\X.X.X\data\pg_xlog в D:\pg_xlog и удалить C:\Program Files\PostgreSQL\X.X.X\data\pg_xlog.
  4. Распаковать программу Junction в C:\Program Files\PostgreSQL\X.X.X\data.
  5. Открыть окно CMD, перейти в C:\Program Files\PostgreSQL\X.X.X\data и выполнить junction -s pg_xlog D:\pg_xlog.
  6. Установить права на папку D:\pg_xlog пользователю postgres.
  7. Запустить PostgreSQL.
    Где X.X.X — версия используемой PostgreSQL.

РЕШЕНИЕ ПРОБЛЕМЫ С ЗАВИСАНИЕМ POSTGRESQL.

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

Варианты решения проблемы:

  1. Увеличить количество записей, просматриваемых при сборе статистики по таблицам. Большие значения могут повысить время выполнения команды ANALYZE, но улучшат построение плана запроса:
    1. Файл postgresql.conf — default_statistics_target = 1000 -10000.
  2. Отключение оптимизатору возможности использования NESTED LOOP при выборе плана выполнения запроса в конфигурации PostgreSQL:
    1. Файл postgresql.conf — enable_nestloop = off.
    2. Отрицательным эффектом этого способа является возможное замедление некоторых запросов, поскольку при их выполении будут использоваться другие, более затратные, методы соединения (HASH JOIN).
  3. Отключение оптимизатору возможности изменения порядка соединений таблиц в запросе:
    1. Файл postgresql.conf — join_collapse_limit=1.
    2. Следует использовать этот метод, если вы уверены в правильности порядка соединений таблиц в проблемном запросе.
  4. Изменение параметров настройки оптимизатора:
    1. Файл postgresql.conf:
      1. seq_page_cost = 0.1
      2. random_page_cost = 0.4
      3. cpu_operator_cost = 0.00025
  5. Использование версии PostgreSQL 9.1.2-1.1.C и выше, в которой реализован независимый от AUTOVACUUM сбор статистики, на основе информации об изменении данных в таблице. По умолчанию включен сбор статистики только для временных таблиц и во многих ситуациях этого достаточно. При возникновении проблем с производительностью выполнения регламентных операций, можно включить сбор статистики для всех или отдельных проблемных таблиц изменив значение параметра конфигурации PostgreSQL (файл postgresql.confonline_analyze.table_type = "temporary" на online_analyze.table_type = "all".

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

Скрипт сжатие таблиц mssqlserver

DECLARE @Table_catalog NVARCHAR(128)
DECLARE @Table_schema NVARCHAR(128)
DECLARE @Table_name NVARCHAR(128)
DECLARE @Index_Name NVARCHAR(128)

DECLARE @cmd VARCHAR(4000)

— включение сжатия для таблиц
DECLARE TableNameCursor CURSOR
FOR
SELECT Table_catalog, Table_schema, Table_name FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = ‘BASE TABLE’
ORDER BY Table_catalog, Table_schema, Table_name

OPEN TableNameCursor

FETCH NEXT FROM TableNameCursor INTO @Table_catalog, @Table_schema, @Table_name
WHILE @@fetch_status = 0
BEGIN

PRINT @Table_catalog + ‘.’ + @Table_schema + ‘.’ + @Table_name
SET @cmd = ‘ALTER TABLE [‘ + @Table_catalog + ‘].[‘ + @Table_schema + ‘].[‘ + @Table_name + ‘] REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE)’
EXEC (@cmd)

FETCH NEXT FROM TableNameCursor INTO @Table_catalog, @Table_schema, @Table_name
END
CLOSE TableNameCursor
DEALLOCATE TableNameCursor

— включение сжатия для индексов
DECLARE IndexCursor CURSOR
FOR
SELECT DB_NAME(), schemas.name, tables.name, indexes.name
FROM sys.schemas as schemas inner join sys.tables as tables inner join sys.indexes as indexes on tables.object_id = indexes.object_id on schemas.schema_id = tables.schema_id
ORDER BY schemas.name, tables.name, indexes.name;

OPEN IndexCursor

FETCH NEXT FROM IndexCursor INTO @Table_catalog, @Table_schema, @Table_name, @Index_Name
WHILE @@fetch_status = 0
BEGIN

PRINT @Table_catalog + ‘.’ + @Table_schema + ‘.’ + @Table_name + ‘: ‘ + @Index_Name

SET @cmd = ‘ALTER INDEX [‘ + @Index_Name + ‘] ON [‘ + @Table_catalog + ‘].[‘ + @Table_schema + ‘].[‘ + @Table_name + ‘] REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE)’
EXEC (@cmd)

FETCH NEXT FROM IndexCursor INTO @Table_catalog, @Table_schema, @Table_name, @Index_Name
END
CLOSE IndexCursor
DEALLOCATE IndexCursor

— делаем шринк базы — возвращаем свободное место на диск
SELECT @cmd=(
SELECT ‘DBCC SHRINKDATABASE(»’+ DB_NAME() + »’)’
)
EXEC (@cmd)

Особенности 8.3.11

Переработан механизм реструкторизации, актуально для баз с большими размерами

Реализован новый механизм реструктуризации информационной базы. Основные отличия этого механизма:

  • При выполнении реструктуризации обрабатываются только те физические таблицы базы данных, в которых есть реальные изменения.
  • Максимальное количество изменений выполняется без создания копии таблицы и копирования информации между копиями.
  • Если копирование информации между версиями таблиц все-таки требуется, это копирование будет выполняться средствами СУБД во всех возможных случаях.

Данная возможность включена в статусе бета-версии. Новый механизм реструктуризации используется только в клиент-серверном варианте, при работе с СУБД Microsoft SQL Server и PostgreSQL.

Для работы нового механизма реструктуризации требуется наличие Java 1.8 на компьютере, где установлен сервер «1С:Предприятия».

Для файла conf.cfg реализованы параметры JavaHomeJavaOptsUpdateDBCfg.
Смотрите дополнительно https://wonderland.v8.1c.ru/blog/optimizatsiya-restrukturizatsii-bazy-dannykh/

Новый функционал «Система взаимодействия»

Стало возможно информировать клиентское приложение о событиях на стороне сервера «1С:Предприятия», в том числе асинхронно.
Реализована возможность развертывания собственного сервера системы взаимодействия. Сервер поставляется в виде отдельного дистрибутива и требует отдельной установки.

Реализовано событие технологического журнала <WINCERT>.

Событие предназначено для расследования событий, связанных с ошибками проверки действительности сертификатов средствами Windows API.Событие формируется только при работе под управлением ОС Windows.

 Стало возможно запускать более одного сеанса работы с веб-клиентом из одного веб-браузера.

Повышена скорость работы поиска по началу строки в языке запросов при работе с СУБД PostgreSQL.

При работе с СУБД PostgreSQL реализовано преобразование операции языка запросов ПОДОБНО `ТЕКСТ%` в более оптимальную операцию SQL-запроса.В режиме совместимости с версией 8.3.10 поведение не изменилось.

 Улучшена производительность и масштабируемость при использовании на стороне сервера «1С:Предприятия» объектов HTTPСоединение и FTPСоединение в том случае, если используется несколько соединений из различных сеансов.

 

Ускорена работа с временными таблицами, при использовании СУБД Microsoft SQL Server

следующих версий:

  • 2012, версия 11.0.5548.0 и старше.
  • 2014, версия 12.0.2430.0 и старше.
  • 2016.

Повышена скорость работы сервера «1С:Предприятия» в том случае, когда одновременно проводятся документы, содержащие большое количество (десятки тысяч) строк.

 

Оптимизирована работа с большими временными таблицами под управлением СУБД PostgreSQL.

Оптимизированы операции удаления записей из временных таблиц при выполнении некоторых операций в СУБД PostgreSQL и IBM DB2.

Уточнение отображения в линуксе

При работе под управлением ОС Linux, параметр рабочего процесса Занято памяти, вычисляется на основании значения VmRSS (resident set size). Значение параметра Занято памяти стало меньше в абсолютном выражении и более точно соответствует реальности.Рекомендуется провести переоценку параметров перезапуска рабочих процессов в свойствах рабочего сервера.

Добавлен платформенный вариант версионирования данных (для аудита) https://wonderland.v8.1c.ru/blog/istoriya-dannykh/

подробнее http://downloads.v8.1c.ru/content//Platform/8_3_11_2867/1cv8upd.htm

Нагрузка, создаваемая запросами Postgres

SELECT
pg_database.datname AS Database,
pg_stat_statements.query AS Query,
pg_stat_statements.calls AS ExecutionCount,
pg_stat_statements.total_time ExecutionTime,
pg_stat_statements.shared_blks_read + pg_stat_statements.shared_blks_written AS Memory,
pg_stat_statements.local_blks_read + pg_stat_statements.local_blks_written AS IO,
pg_stat_statements.temp_blks_read + pg_stat_statements.temp_blks_written AS Temp

FROM
pg_stat_statements AS pg_stat_statements
INNER JOIN pg_database AS pg_database
ON pg_database.oid = pg_stat_statements.dbid
ORDER BY
ExecutionTime DESC
with s AS (SELECT
CASE WHEN sum(total_time) = 0 THEN 1 ELSE sum(total_time) END AS sum_time,
CASE WHEN sum(blk_read_time+blk_write_time) = 0 THEN 1 ELSE sum(blk_read_time+blk_write_time) END as sum_iotime,
CASE WHEN sum(total_time-blk_read_time-blk_write_time) = 0 THEN 1 ELSE sum(total_time-blk_read_time-blk_write_time)
END as sum_cputime,
CASE WHEN sum(calls) = 0 THEN 1 ELSE sum(calls) END AS sum_calls,
CASE WHEN sum(rows) = 0 THEN 1 ELSE sum(rows) END as sum_rows
FROM pg_stat_statements
)
SELECT
'all_users@all_databases' as "user@database",
100 AS time_percent,
100 AS iotime_percent,
100 AS cputime_percent,
(sum_time/1000)*'1 second'::interval as total_time,
(sum_cputime/sum_calls)::numeric(20, 2) AS avg_cpu_time_ms,
(sum_iotime/sum_calls)::numeric(20, 2) AS avg_io_time_ms,
sum_calls as calls,
100 AS calls_percent,
sum_rows as rows,
100 as row_percent,
'all_queries' as query
FROM s
UNION ALL
SELECT
(select rolname from pg_roles where oid = p.userid) || '@' || (select datname from pg_database where oid
(100*total_time/(SELECT sum_time FROM s))::numeric(20, 2) AS time_percent,
(100*(blk_read_time+blk_write_time)/(SELECT sum_iotime FROM s))::numeric(20, 2) AS iotime_percent,
(100*(total_time-blk_read_time-blk_write_time)/(SELECT sum_cputime FROM s))::numeric(20, 2) AS cputime_percent,
(total_time/1000)*'1 second'::interval as total_time,
((total_time-blk_read_time-blk_write_time)/calls)::numeric(20, 2) AS avg_cpu_time_ms,
((blk_read_time+blk_write_time)/calls)::numeric(20, 2) AS avg_io_time_ms,
calls,
(100*calls/(SELECT sum_calls FROM s))::numeric(20, 2) AS calls_percent,
rows,
(100*rows/(SELECT sum_rows from s))::numeric(20, 2) AS row_percent,
query
FROM pg_stat_statements p
WHERE
(total_time-blk_read_time-blk_write_time)/(SELECT sum_cputime FROM s)>=0.005
UNION ALL
SELECT
'all_users@all_databases' as "user@database",
(100*sum(total_time)/(SELECT sum_time FROM s))::numeric(20, 2) AS time_percent,
(100*sum(blk_read_time+blk_write_time)/(SELECT sum_iotime FROM s))::numeric(20, 2) AS iotime_percent,
(100*sum(total_time-blk_read_time-blk_write_time)/(SELECT sum_cputime FROM s))::numeric(20, 2) AS cputime_percent,
(sum(total_time)/1000)*'1 second'::interval,
(sum(total_time-blk_read_time-blk_write_time)/sum(calls))::numeric(10, 3) AS avg_cpu_time_ms,
(sum(blk_read_time+blk_write_time)/sum(calls))::numeric(10, 3) AS avg_io_time_ms,
sum(calls),
(100*sum(calls)/(SELECT sum_calls FROM s))::numeric(20, 2) AS calls_percent,
sum(rows),
(100*sum(rows)/(SELECT sum_rows from s))::numeric(20, 2) AS row_percent,
'other' AS query
FROM pg_stat_statements p
WHERE
(total_time-blk_read_time-blk_write_time)/(SELECT sum_cputime FROM s)<0.005 ORDER BY 4 DESC;

Использование индексов Postgres

SELECT
t.tablename,
indexname,
c.reltuples AS num_rows,
pg_size_pretty(pg_relation_size(quote_ident(t.tablename)::text)) AS table_size,
pg_size_pretty(pg_relation_size(quote_ident(indexrelname)::text)) AS index_size,
CASE WHEN indisunique THEN 'Y' ELSE 'N' END AS UNIQUE,
idx_scan AS number_of_scans, idx_tup_read AS tuples_read, idx_tup_fetch AS tuples_fetched
FROM pg_tables t
LEFT OUTER JOIN pg_class c ON t.tablename=c.relname
LEFT OUTER JOIN
( SELECT c.relname AS ctablename, ipg.relname AS indexname, x.indnatts AS number_of_columns,
idx_scan, idx_tup_read, idx_tup_fetch, indexrelname, indisunique FROM pg_index x
JOIN pg_class c ON c.oid = x.indrelid JOIN pg_class ipg ON ipg.oid = x.indexrelid
JOIN pg_stat_all_indexes psai ON x.indexrelid = psai.indexrelid )
AS foo
ON t.tablename = foo.ctablename
WHERE t.schemaname='public'
ORDER BY 1,2;
--------------------------------------------------------------
SELECT
idstat.relname AS table_name,
indexrelname AS index_name,
idstat.idx_scan AS times_used,
pg_size_pretty(pg_relation_size(tabstat.relid)) AS table_size,
pg_size_pretty(pg_relation_size(indexrelid)) AS index_size,
n_tup_upd + n_tup_ins + n_tup_del as num_writes,
indexdef AS definition
FROM
pg_stat_user_indexes AS idstat
JOIN pg_indexes ON indexrelname = indexname
JOIN pg_stat_user_tables AS tabstat ON idstat.relname = tabstat.relname
WHERE
idstat.idx_scan < 200 AND indexdef !~* 'unique' ORDER BY idstat.relname, indexrelname; -------------------------------------------------------------- WITH table_scans as ( SELECT relid, tables.idx_scan + tables.seq_scan as all_scans, ( tables.n_tup_ins + tables.n_tup_upd + tables.n_tup_del ) as writes, pg_relation_size(relid) as table_size FROM pg_stat_user_tables as tables ), all_writes as ( SELECT sum(writes) as total_writes FROM table_scans ), indexes as ( SELECT idx_stat.relid, idx_stat.indexrelid, idx_stat.schemaname, idx_stat.relname as tablename, idx_stat.indexrelname as indexname, idx_stat.idx_scan, pg_relation_size(idx_stat.indexrelid) as index_bytes, indexdef ~* 'USING btree' AS idx_is_btree FROM pg_stat_user_indexes as idx_stat JOIN pg_index USING (indexrelid) JOIN pg_indexes as indexes ON idx_stat.schemaname = indexes.schemaname AND idx_stat.relname = indexes.tablename AND idx_stat.indexrelname = indexes.indexname WHERE pg_index.indisunique = FALSE ), index_ratios AS ( SELECT schemaname, tablename, indexname, idx_scan, all_scans, round(( CASE WHEN all_scans = 0 THEN 0.0::NUMERIC ELSE idx_scan::NUMERIC/all_scans * 100 END),2) as index_scan_pct, writes, round((CASE WHEN writes = 0 THEN idx_scan::NUMERIC ELSE idx_scan::NUMERIC/writes END),2) as scans_per_write, pg_size_pretty(index_bytes) as index_size, pg_size_pretty(table_size) as table_size, idx_is_btree, index_bytes FROM indexes JOIN table_scans USING (relid) ), index_groups AS ( SELECT 'Never Used Indexes' as reason, *, 1 as grp FROM index_ratios WHERE idx_scan = 0 and idx_is_btree UNION ALL SELECT 'Low Scans, High Writes' as reason, *, 2 as grp FROM index_ratios WHERE scans_per_write <= 1 and index_scan_pct < 10 and idx_scan > 0
and writes > 100
and idx_is_btree
UNION ALL
SELECT 'Seldom Used Large Indexes' as reason, *, 3 as grp
FROM index_ratios
WHERE
index_scan_pct < 5 and scans_per_write > 1
and idx_scan > 0
and idx_is_btree
and index_bytes > 100000000
UNION ALL
SELECT 'High-Write Large Non-Btree' as reason, index_ratios.*, 4 as grp
FROM index_ratios, all_writes
WHERE
( writes::NUMERIC / total_writes ) > 0.02
AND NOT idx_is_btree
AND index_bytes > 100000000
ORDER BY grp, index_bytes DESC )
SELECT reason, schemaname, tablename, indexname,
index_scan_pct, scans_per_write, index_size, table_size
FROM index_groups;

Отсутствие индексов Postgres

SELECT
relname,
seq_scan - coalesce(idx_scan, 0) AS too_much_seq,
case when seq_scan - coalesce(idx_scan, 0) > 0 THEN 'Нет индекса?' ELSE 'OK' END AS Message,
pg_relation_size(relname::regclass) AS rel_size,
seq_scan,
coalesce(idx_scan, 0) AS idx_scan
FROM
pg_stat_all_tables
WHERE
schemaname='public'
AND pg_relation_size(relname::regclass)>10000 -- ограничение на размер анализируемых таблиц
ORDER BY
too_much_seq DESC;

Базы данных с максимальным IO Postgres

SELECT
pg_stat_database.datname AS DatabaseName,
MAX(pg_stat_database.tup_returned) AS TotalReads,
MAX(pg_stat_database.tup_inserted + pg_stat_database.tup_updated + pg_stat_database.tup_deleted) AS TotalWrites,
MAX(pg_stat_database.tup_returned + pg_stat_database.tup_inserted + pg_stat_database.tup_updated
+ pg_stat_database.tup_deleted) AS IO,
SUM(pg_stat_statements.calls) AS ExecutionCount

FROM
pg_catalog.pg_stat_database AS pg_stat_database
LEFT OUTER JOIN pg_stat_statements AS pg_stat_statements
ON pg_stat_statements.dbid = pg_stat_database.datid
GROUP BY
pg_stat_database.datname
ORDER BY
IO Desc

Особенности 8.3.10

Реализована поддержка СУБД PostgreSQL версии 9.6.

 Смотрите также http://1c.ru/news/pressrelise.jsp?id=1847

Повышена масштабируемость кластера серверов в том случае, если:

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

Снижено количество оперативной памяти, используемой сервером «1С:Предприятия», если в прикладном решении используются пакетные запросы.

Упрощена диагностика использования циклических ссылок при работе встроенного языка.

Реализована возможность дополнительно обработать данные, которые получил динамический список для отображения. Реализовано событие ПриПолученииДанныхНаСервере. Дополнительно смотрите https://wonderland.v8.1c.ru/blog/obrabotka-i-oformlenie-dannykh-dinamicheskogo-spiska/

В технологическом журнале реализовано отражение событий, связанных с:

  • получением и освобождением лицензий (как программных, так и ключей HASP);
  • получением лицензий на базовые версии;
  • регулярным мониторингом соответствия реального оборудования и списка оборудования, зафиксированного в лицензии.

Реализовано событие технологического журнала <LIC>.

Событие технологического журнала <HASP> предоставляет возможность анализа только технологических аспектов работы с ключами HASP (вызовы интерфейса работы с HASP), не предоставляя возможности отслеживать получение и освобождение лицензий, получаемых с ключей HASP.

Реализовано журналирование событий, возникающих при первом соединении сервера «1С:Предприятия» с СУБД Microsoft SQL Server, в технологическом журнале. Журналирование выполняется с помощью события <DBMSSQLCONN>.

В документации данное изменение описано здесь и здесь.

Изменен подход к хранению истории исполнения фоновых и регламентных заданий. В клиент-серверном варианте история хранится в разрезе информационных баз. Для каждой информационной базы хранится история:

  • до 1 000 фоновых заданий, созданных из встроенного языка;
  • до 1 000 регламентных заданий;
  • до 1 000 системных фоновых заданий (формируемых самой системой).

Для каждого задания (фонового, системного фонового и регламентного) будет предприниматься попытка хранить информацию минимум о трех последних запусках. Это количество (три запуска) будет уменьшаться в том случае, если превышен лимит в 1 000 записей на тот или иной вид заданий.

Реализовано в версии 8.3.10.2168 в новое событие SCRIPTCIRCREFS  режим автоматического поиска циклических ссылок

Особенности 8.3.9

С версии 8.3.9.1818, 1С:Предприятие поддерживает прозрачную переустановку разорванных соединений с SQL-сервером, за исключением случаев разрыва соединения при активной транзакции.

Реализована поддержка СУБД Microsoft SQL Server 2016.

Ускорена работа в многопользовательском режиме при использовании СУБД Microsoft SQL Server при активном использовании tempdb, а также устранены задержки при закрытии соединений.

Для Microsoft SQL Server 2014 сервер «1С:Предприятия» выполняет принудительную установку TRACE FLAG 4199. В связи с этим в настройках соединения сервера «1С:Предприятие» с СУБД необходимо указывать пользователя, обладающего административными правами sysadmin.

Источник: http://downloads.v8.1c.ru/content//Platform/8_3_9_2170/1cv8upd.htm#7c1b8dd6-9531-11e6-a3f7-0050569f678a

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

Если при эскалации блокировки возникает конфликт с уже наложенными блокировками, то эскалация не выполняется, а производится попытка установить запрошенную блокировку. В этом случае возможна ситуация, когда в системе будет существовать более 100 000 блокировок на одно пространство.

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

 

Диагностика серверных вызовов

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

 

Веб-сервисы

За счёт переиспользования сеансов значительно увеличена производительность веб-сервисов. http://v8.1c.ru/o7/201604service/index.htm подробнее

Реализованы две различные стратегии:

  • Автоматическое переиспользование сеансов из пула;
  • Управление сеансами с помощью HTTP-заголовков.

Разработчик может выбрать одну или другую стратегию работы в зависимости от особенностей используемых сервисов.

Бета-версия 64-разрядных приложений для Windows

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

Преимущество 64-разрядных приложений заключается в том, что они не имеют ограничений по использованию оперативной памяти. Это позволяет более комфортно работать в конфигураторе с крупными конфигурациями, такими как ERP.

Форматированный документ

Ускорена работа форматированного документа с большими объёмами данных.

 

Инструменты для работы с двоичными данными

Реализован ряд низкоуровневых инструментов для работы с двоичными данными. С их помощью возможна последовательная работа с большими объёмами данных. Также они предоставляют произвольный доступ к относительно небольшим двоичным данным целиком в оперативной памяти. Новые инструменты позволяют решать такие задачи, как:

  • Взаимодействие со специализированными устройствами по двоичному протоколу;
  • Разбор файлов и манипуляция файлами различных форматов;
  • Конвертация текстовых данных напрямую в двоичные данные, например, для отправки отчетов;
  • Работа с двоичными данными в памяти.

Удерживать таблицу в оперативной памяти PostgreSQL

pg_prewarm http://www.postgresql.org/docs/9.4/static/pgprewarm.html

Разогрев кэша

В новом расширении pg_prewarm доступна одноимённая функция, с помощью которой необходимая сущность форсированно загружается в кэш (системный ОС или PostgreSQL). Посмотрим, как это происходит.

Для начала, установим расширение и создадим тестовую таблицу:

<code>CREATE EXTENSION pg_prewarm;

CREATE TABLE big AS
SELECT array_to_string ( array_agg ( t.x ), '' )
	|| '#' || generate_series ( 1, 10000 ) AS value
FROM ( SELECT 'a' || generate_series ( 1, 1000 ) AS x ) t;

-- немного увеличим размер буфера
ALTER SYSTEM SET shared_buffers = '256MB';
</code>

Теперь, остановим сервер PostgreSQL, сбросим кэши ОС на диск и запустим сервер снова (в вашей ОС команды могут быть иные):

<code>/etc/init.d/postgresql-9.4 stop
sync
/etc/init.d/postgresql-9.4 start
</code>

Обратимся запросом к тестовой таблице, наблюдая, откуда выбираются данные:

<code>-- первая попытка
EXPLAIN ( ANALYZE, BUFFERS )
SELECT * FROM big;
--
Seq Scan on big  (cost=0.00..76047.00 rows=5000000 width=8) (actual time=0.013..448.978 rows=5000000 loops=1)
  Buffers: shared read=26047
Planning time: 0.081 ms
Execution time: 689.083 ms

-- вторая попытка
EXPLAIN ( ANALYZE, BUFFERS )
SELECT * FROM big;
--
Seq Scan on big  (cost=0.00..76047.00 rows=5000000 width=8) (actual time=0.044..449.973 rows=5000000 loops=1)
  Buffers: shared hit=32 read=26015
Planning time: 0.027 ms
Execution time: 692.045 ms

-- третья попытка
EXPLAIN ( ANALYZE, BUFFERS )
SELECT * FROM big;
--
Seq Scan on big  (cost=0.00..76047.00 rows=5000000 width=8) (actual time=0.044..449.973 rows=5000000 loops=1)
  Buffers: shared hit=32 read=26015
Planning time: 0.027 ms
Execution time: 692.045 ms
</code>

Наглядно видно, что так как в кэше еще ничего нет, данные читаются с диска (shared read), но с каждым последующим запросом кэш наполняется (shared hit).

Снова остановим сервер PostgreSQL, сбросим кэш ОС и запустим сервер. И опять посмотрим на результат EXPLAIN, но перед этим заполнив кэш данными тестовой таблицы:

<code>-- загружено 26047 блоков
SELECT pg_prewarm ( 'big' );

EXPLAIN ( ANALYZE, BUFFERS )
SELECT * FROM big;
--
Seq Scan on big  (cost=0.00..76047.00 rows=5000000 width=8) (actual time=0.007..407.269 rows=5000000 loops=1)
  Buffers: shared hit=26047
Planning time: 0.129 ms
Execution time: 642.834 ms
</code>

Все данные уже находятся в кэше.

 

Hyper-threading процессоров для производительности — за и против

hyper-threading_kak_working

•После включения технологии гипертрейдинга один физический процессор (одно физическое ядро) определяется операционной системой как два отдельных процессора (два логических ядра). При определённых рабочих нагрузках использование HTT позволяет увеличить производительность процессора. В некоторых тестах около 25% улучшения.
•…а может и ухудшить (любая технология обладает не только плюсами, но и минусами, из-за непопадания в кэш процессора, из-за неправильного предсказания алгоритмом ветвления по потокам задач, взаимное ожидание ресурсов в разных потоках, более «быстрые потоки» ждут «более медленные потоки», ошибки в выборе по загруженности ресурсов)
•НЕ все можно разбить на потоки (вообще складывается субъективное ощущение что гипертрейдинг хорошо работает на настольных компьютерах/ноутбуках где на разных ядрах работают монопточные не пересекаемые приложения)
•НЕ все приложения умеют работать с этой технологией (долгое время Microsoft рекомендовал для MS SQL Server выключать гипертрейдинг еще и потому что его внутренние алгоритмы уже распараллеливают работу на нужном уровне и остальные «улучшения» спорны)
https://support.microsoft.com/ru-ru/kb/322385 «все зависит от нагрузки», моими словами коротко – ни кто точно не знает, пробуйте и так и сяк 

ht

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

https://msdn.microsoft.com/ru-ru/library/ms143760(v=SQL.120).aspx влияние на стоимость владения лицензий в виртуалках
•Если важна производительность в пересчете на виртуальный процессор, может понадобиться отключить технологию Hyper-Threading. Технологию Hyper-Threading можно включать и отключать в параметрах процессора в BIOS, но обычно это операция на уровне сервера, которая действует на всю рабочую нагрузку, активную на сервере. Это обстоятельство делает разумным отделение рабочей нагрузки, действующей в виртуальных средах, от нагрузки, для которой технология Hyper-Threading обеспечит прирост производительности в среде физической операционной системы.
ИТОГО: Для локальных однопользовательских приложений или их использовании на серверах изолированно гипертрейдинг в теории должен улучшать количество одновременно выполняемых задач и сказывать положительно. Что же касается сложных продуктов как 1С:Предприятие 8 и СУБД на большое количество пользователей или по пересекаемым ресурсам/данным точно можно понять только проведя сравнительное тестирование.
Вы можете высказать свое мнение на нашем форуме http://www.gilev.ru/forum/viewtopic.php?f=18&t=1053

Определение производительности рабочего сервера 1С

SELECT COUNT(*) FROM DBSchema

Этот запрос используется как эталонный для измерения скорости обращения к СУБД при определении производительности рабочего сервера в кластере. Результат этого замера участвует в формировании значения колонки «Доступная производительность» списка рабочих процессов консоли кластера. На основании этого значения выбирается рабочий процесс, с которым устанавливается новое клиентское соединение с сервером.

Ошибки в практике оптимизации производительности 1С

 

  • Изменения в системе делаются не по одному
    • Мигрируют с 8.2 на 8.3, с БП 2.0 на 3.0, с одного сервера на другой, несколько изменений в параметрах субд сразу…
    • Нельзя оценить вклад каждого изменения
  • «В нашей команде достаточно опытных разработчиков, настоящих профессионалов своего дела, поэтому через какое-то время мы всё же нагуглили решение.»
    • Изменения делаются «по лучшим практикам»
    • Потому что соседу помогло (добавить SSD)
    • Потому что так советует «авторитет/вендор» (использовать временные таблицы в запросах)
    • Не анализируются причины «лучших практик» и их уместность в конкретном случае
  • Заранее не оценивается ожидаемый эффект
    • Делается что легче
    • Анализ поверхностный
    • Не анализируется наиболее узкое место
    • Можно положить много сил на устранение второстепенных проблем, но не решим наиболее важную они будут не оценены

Причины проблем с производительностью

Не контролируются параметры производительности:
•практикуется субъективная оценка производительности
•бизнес не ставит приоритетов по контролируемым операциям
мониторинг не постоянный

Можно ли говорить об улучшениях работы без использования объективной статистики длительности операций?
Все все знают… вроде… и должны бы делать… но тогда бы не было проблем 🙂
Наше русское «авось» надо уметь оценивать в деньгах. Стоимость решения проблемы с производительностью в день когда она только возникла 5-10% от максимальной стоимости решения.
Через неделю уже это 25%. Через полгода эта проблема будет погребена под другими и вот тогда бизнесу за решение уже придется заплатить «по полной стоимости поиска проблемы», так как придется заново выяснять вес/влияние/значимость вклада проблемы с другими сопутствующими коэффициентами увеличения стоимости…

Влияние стереотипов и привычек на производительность 1С

ВНИМАНИЕ! СТЕРЕОТИП: Сервер нагружен слабо, процессоры слабо используются – поэтому все медленно

  • загрузка сервера должна обеспечивать запас мощности под «пики»
  • неверная оценка загруженности (включая короткий интервал наблюдения)
  • чем больше блокировок, тем меньше загруженность
Да, конечно если у Вас процессоры сервера загружены «по полной» это не означает проблем. Но зато это означает что просто так добавить пользователей, новый функционал, обработать больший объем данных ХОРОШО вы вряд ли сможете — запаса мощности нет!
Кроме того высокая нагрузка на сервер создает большую ВЕРОЯТНОСТЬ что в пиковый момент (максимальной интенсивности) у Вас возникнет ожидание не только оборудования, но и блокировок (потому что часто вероятность блокировок увеличивается пропорционально растущему времени транзакций).

Часто под загруженностью сервера администраторы подразумевают процесс минутного наблюдения диспетчера задач по графику загруженности ядер процессора. Однако в эту минуту вы можете и пиков загруженности не увидеть, и понять насколько это среднестатистическая нагрузка, и насколько эта нагрузка колеблется в течении суток.
Сделать правильный вывод можно с низкой степенью вероятности. Просто так «легко и быстро».

Еще один фактор пониженной нагрузку — блокировки. Когда у Вас интенсивные ожидания на блокировках, вы ЖДЕТЕ (т.е. почти ничего не делаете). В условиях массовых блокировок оборудование часто выглядит как слабо нагруженным, но на самом деле работа парализована. Когда избыточные блокировки «уйдут», то обычно увеличивается количество операций в единицу времени, а значит растет нагрузка на сервер.

Вот поэтому надо записывать нагрузку. на сервер, сопоставлять ее с ожиданиями оборудования и блокировок. Стараться не допускать ситуаций, когда запас мощности сервера составляет меньше 30% по любым компонентам (а не только по процессору).

Объективное измерение производительности информационной системы

Эта заметка будет полезна администраторам информационных систем, которые хотят улучшить ситуацию с производительностью их системы. И вот на что рекомендуем обратить внимание:
1. Скорость операция с точки зрения пользователя – АПДЕКС
2. Загруженность оборудования – оценка запаса мощности

Одна из ошибок, которая часто совершается при повышении производительности информационной системы — спрашивать пользователей «а стало ли лучше сейчас?».

APDEX –статистика длительности операций — это:

  1. Объективная оценка
  2. Позволяет найти общую метрику для IT-специалистов и бизнеса
  3. Это замер начала и окончания операции
  4. Хранение в базе данных
  5. Бывает нужен программист
  6. Позволяет навести порядок в вопросах производительности
  7. В последних конфигурациях 1с механизм уже встроен
Совет пользователям, админы которых после этого поста все равно не будут применять этот подход:

Если хочешь попить чаю, создай предлог «все медленно работает»

Пудри мозг админу «зачем тебе замеры, этим программист должен заниматься» — не позволяй собрать объективные метрики

Если программист или админ спрашивает помогли ли правки, нагло ври что ничего не помогло. Если кричат громче, то твоя возьмет!

Админам на заметку:
  1. Если программист не хочет заниматься апдексом (типа «у меня нет времени»), то это не означает что можно все оставить как есть
  2. Если не будет объективных замеров, то и достигнутое улучшение объективно нельзя будет оценить
  3. Иногда важнее не уметь все делать, а организовать достижение конечного результата в том числе с привлечение других специалистов – главное результат

При хостинге 1cFresh АПДЕКС обязательно! :

  • Особенности «1СФреш»
  • Влияние пользователей одного клиента на работу пользователей другого клиента – потому что физически данные в одной таблице на одних дисках
  • Представители разных клиентов могут давать противоречивую информацию о работе
  • Но нужно следить чтобы сами замеры не были проблемой
  • Высокая конкуренция потенциально может создать блокировки на объектах фиксации – а апдекс во фреше не пишет однопоточно
  • Или доработать АПДЕКС

http://www.gilev.ru/apdex/ — онлайн сервис — «то что доктор прописал»!

  1. Во всех сервисах используется регистрация, ее надо пройти один раз
  2. Видео примера https://youtu.be/cSTYlitD8GM?t=8m
  3. Нужно придумать логин и указать почтовый ящик, куда будут приходить различные сообщения
  4. Во втором письме будет необходимо пройти по ссылке для активации учетной записи в сервисах

Настройка сервиса

  1. Описана http://www.gilev.ru/setupapdex/
  2. Клиентскую часть скачать http://www.gilev.ru/1c/cloud/ApdexClientWork82.cf и объединить с конфигурацией продуктива

Есть отличия от апдекса БСП

  1. Другой состав полей, собираем текст запроса
  2. Более эффективный способ записи без блокировок асинхронно (сначала замеры кэшируются, а потом записываются через фоновое задание )
  3. Отчеты строятся на сайте http://www.gilev.ru/apdex/

Флаг трассировки 2335

Флаг трассировки 2335 заставит SQL Server 2005 и 2008 генерировать более консервативный с точки зрения потребления памяти план исполняя запроса, не ограничивая при этом объём используемой SQL Server памяти для  кэша данных, запросов и т.п. Необходимость в этом флаге может возникнуть, если после увеличения значения «max server memory» наблюдается замедление исполнения запросов. Подробности в статье KB2413549.

Флаг трассировки 1117

Флаг трассировки 1117

При наличии типа ожидания pagelatch рекомендуется вспомнить про логическую конкуренцию ресурсов файлов.

select   session_id, wait_duration_ms,   resource_description      from    sys.dm_os_waiting_tasks where   wait_type like ‘PAGE%LATCH_%’ and              resource_description like ‘2:%’
В рамках одной файловой группы может быть создано несколько файлов. Например, для базы tempdb рекомендуется создавать несколько файлов, что может в некоторых сценариях увеличить производительность системы.

Идея такая:
Если логических ядер <=8 то файлов tempdb должно быть равно количеству ядер (при том что диск достаточный для увеличения нагрузки)

Если логических ядер >8 то добавить еще 4 файла и посмотреть по факту. Надо, еще добавить, но при этом важно не переборщить, можно вместо логических ожиданий наплодить очередей к диску например.

Теперь предположим ситуацию: все файлы, входящие в файловую группу, имеют одинаковый размер. Создается большая временная таблица. Места в файле #1 не достаточно и разумеется происходит AutoGrow. Через время такая же таблица пересоздается, но вставка происходит в файл #2, потому что #1 временно заблокирован. Что в таком случае будет?AutoGrow для #2… и повторная задержка при выполнении запросов. Для таких случаев, был предусмотрен TF 1117. Работал он глобально и при нехватке места в одном файле вызывал AutoGrow для всех файлов в рамках одной файловой группы.

В MS SQL Server 2016 данный трейс-флаг включен по умолчанию для tempdb и может избирательно настраиваться для пользовательских баз:
ALTER DATABASE test
MODIFY FILEGROUP [PRIMARY] AUTOGROW_ALL_FILES
GO
ALTER DATABASE test
MODIFY FILEGROUP [PRIMARY] AUTOGROW_SINGLE_FILE
GO

Посмотрим на размер файлов:
USE tempdb
GO

SELECT
name
, physical_name
, current_size_mb = ROUND(size * 8. / 1024, 0)
, auto_grow =
CASE WHEN is_percent_growth = 1
THEN CAST(growth AS VARCHAR(10)) + ‘%’
ELSE CAST(CAST(ROUND(growth * 8. / 1024, 0) AS INT) AS VARCHAR(10)) + ‘MB’
END
FROM sys.database_files
WHERE [type] = 0

name physical_name size_mb auto_grow
---------- --------------------------------------------------- -------- ------------
tempdev D:\DATABASES\SQL_2016RC0\TEMP\tempdb.mdf 8.000000 64MB
temp2 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_2.ndf 8.000000 64MB
temp3 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_3.ndf 8.000000 64MB
temp4 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_4.ndf 8.000000 64MB

Создаем временную таблицу:
IF OBJECT_ID('#t') IS NOT NULL
DROP TABLE #t
GO

CREATE TABLE #t (
ID INT DEFAULT 1,
Value CHAR(8000) DEFAULT ‘X’
)
GO

INSERT INTO #t
SELECT TOP(10000) 1, ‘X’
FROM [master].dbo.spt_values c1
CROSS APPLY [master].dbo.spt_values c2

Места чтобы вставить данные не хватит и произойдет AutoGrow.

AUTOGROW_SINGLE_FILE:
name physical_name size_mb auto_grow
---------- --------------------------------------------------- ----------- ------------
tempdev D:\DATABASES\SQL_2016RC0\TEMP\tempdb.mdf 72.000000 64MB
temp2 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_2.ndf 8.000000 64MB
temp3 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_3.ndf 8.000000 64MB
temp4 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_4.ndf 8.000000 64MB

AUTOGROW_ALL_FILES:
name physical_name size_mb auto_grow
---------- --------------------------------------------------- ----------- ------------
tempdev D:\DATABASES\SQL_2016RC0\TEMP\tempdb.mdf 72.000000 64MB
temp2 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_2.ndf 72.000000 64MB
temp3 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_3.ndf 72.000000 64MB
temp4 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_4.ndf 72.000000 64MB

Флаг трассировки 8048

В случае, если в вашей системе более 8 логических процессоров и наблюдается большое число ожиданий CMEMTHREAD и кратковременных блокировок:
SELECT waiting_tasks_count
FROM sys.dm_os_wait_stats
WHERE wait_type = 'CMEMTHREAD'
AND waiting_tasks_count > 0

SELECT spins
FROM sys.dm_os_spinlock_stats
WHERE name = ‘SOS_SUSPEND_QUEUE’
AND spins > 0

то использование TF 8048 помогает избавиться от проблем с производительностью.

В SQL Server 2016 данный трейс флаг включен по умолчанию.

флаг трассировки -T1118

-T1118

SQL Server вычитывает данные с диска кусками по 64Кб (так называемыми экстентами). Экстент – это группа из восьми физически последовательных страниц (по 8Кб каждая) файлов базы данных.

Имеются два типа экстентов: смешанные и однородные. На смешанном экстенте могут храниться страницы с разных объектов. Такое поведение позволяет очень маленьким таблицам занимать минимальное количество места. Но чаще всего таблицы не ограничиваются размером в 64Кб и когда требуется более 8 страниц для хранения данных по одному объекту, то происходит переключение на выделение однородных экстентов.

Чтобы изначально выделять для объекта однородные экстенты  предусмотрен флаг трассировки 1118, который рекомендуется включать:

DBCC TRACEON (1118, -1);
GO

В 2016 версии такого уже не будет. Но для каждой пользовательской базы можно задать опцию MIXED_PAGE_ALLOCATION

смотрите также http://www.gilev.ru/trace2371/

Возможности 8.3.4

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

Реализована возможность использования общих реквизитов, не являющихся разделителями, в свойстве объекта конфигурации ПоляБлокировкиДанных.

Общие реквизиты, которые являются разделителями в режиме Независимо и совместно, не могут быть выбраны в список реквизитов ПоляБлокировкиДанных. Реализована возможность указывать такие реквизиты в качестве имени пространства блокировок объекта БлокировкаДанных. Система вызовет исключение в том случае, если в объекте БлокировкаДанныхиспользуется значение разделителя, отличное от значения, используемого в сеансе.

Изменения реализованы для следующих объектов:

  • Справочники;
  • Документы;
  • Планы видов характеристик;
  • Планы счетов;
  • Планы видов расчета;
  • Планы обмена;
  • Бизнес-процессы;
  • Задачи;
  • Константы.

Исключена возможность устанавливать управляемые транзакционные блокировки (свойство ПоляБлокировкиДанных) по реквизитам объектов следующих типов: строка неограниченной длины, хранилище значений, тип значения характеристики, составные типы, включающие в себя какие-либо из вышеперечисленных типов.

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

Для сервера «1С:Предприятия» реализованы лицензии с ограниченным количеством одновременно обслуживаемых сеансов клиентских приложений —  МИНИ-СЕРВЕР на 5 подключений.

Подробнее здесь

Особенности 8.3.1

При работе с Microsoft SQL Server версии 2005 и выше, используется режим управления версиями строк, если конфигурация использует режим управляемых блокировок. Используется уровень изоляции транзакций READ_COMMITED_SNAPSHOT. При чтении данных вне транзакций используется согласованное чтение.

Возможность помещения в технологический журнал информации о работе с внешними источниками данных. Для этого в конфигурационный файл технологического журнала добавлено событие <EDS>

Возможность помещения в технологический журнал информации о выполнении операций, изменяющих работу кластера серверов, например во время репликации данных между сервисами кластера. Для этого в конфигурационный файл технологического журнала добавлено событие <CLSTR>

Ускорена работа при использовании СУБД PostgreSQL за счет изменения структуры индексов. Оптимизация действует для новых информационных баз и для существующих после выполнения реструктуризации базы данных.Стало возможно использовать отдельные табличные пространства для индексов (пространство v81c_index) и данных (пространство v81c_data) в СУБД PostrgeSQL.

Табличные пространства не создаются автоматически и должны быть созданы администратором базы данных. Если дополнительных табличных пространств не создано — используется табличное пространство по умолчанию (pg_default).

Расширен состав свойств для события технологического журнала <call> в том случае, если событие генерируется для процесса rphost (свойство process равноrphost), а также в том случае, если процесс rphost выполняет обращение к виртуальным ресурсам системы.

Добавлены свойства, отображающие:

  • Report — имя объекта метаданных выполняемого отчета;
  • Method — имя вызванного метода;
  • SessionID — номер сеанса;
  • Memory — объем памяти в байтах, занятой, но не освобожденной за вызов;
  • MemoryPeak — объем памяти в байтах, занятой, но не освобожденной за вызов. Пиковое значение;
  • InBytes — количество прочитанных за вызов данных с диска, в байтах;
  • OutBytes — количество записанных за вызов данных с диска, в байтах;
  • Context — контекст события.

 

Возможность помещения в технологический журнал информации о работе с внешними источниками данных. Для этого в конфигурационный файл технологического журнала добавлено событие <EDS>.

 

Возможность помещения в технологический журнал информации о выполнении операций, изменяющих работу кластера серверов, например во время репликации данных между сервисами кластера. Для этого в конфигурационный файл технологического журнала добавлено событие <CLSTR>.

Подробнее здесь

Особенности 8.3.8

Файловая версия 8.3.8 работает существенно быстрее чем версии 8.3.6, 8.3.7

Реализована поддержка веб-сервера Apache 2.4 для ОС Windows и Linux.

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

Оптимизирована работа с сеансовыми данными. Уменьшено место на диске, которое занимают сеансовые данные. Сеансовые данные хранятся в кластере серверов в сжатом виде. Сжатие/расжатие сеансовых данных происходит на стороне рабочего процесса.

В языке запросов реализовано упрощение некоторых выражений вида <ВЫРАЖЕНИЕ> ИЛИ ИСТИНА.

Оптимизированы операции удаления записей из временных таблиц при выполнении некоторых операций в СУБД PostgreSQL и IBM DB2.

Реализована возможность управлять сбором информации о блокировках СУБД в технологическом журнале (элемент<DBMSLOCKS>).Реализован сервис кластера серверов, выполняющий сбор информации о блокировках СУБД. Сервис называетсяAuxiliaryService (Сервис вспомогательныхфункций кластера).

 

Управляемая блокировка, устанавливаемая при записи движений регистра бухгалтерии при использовании БлокироватьДляИзменения, будет установлена по значениям только не оборотных субконто.

Если блокировка устанавливается для дальнейшей работы с остатками, то не рекомендуется указывать значения оборотных субконто при наложении блокировки (возможно использование как свойства БлокироватьДляИзменения, так и явное использование управляемой блокировки). Если блокировка устанавливается для дальнейшей работы с оборотами — следует указывать все необходимые значения субконто, в том числе и значения оборотных субконто (возможно использование только явного вызова управляемой блокировки).

В режиме совместимости с версией 8.3.7 поведение не изменилось.

 

Реализовано событие технологического журнала <FTEXTSKIP>.

При работе с СУБД Microsoft SQL Server изменены типы полей таблиц, используемые для хранения некоторых типов реквизитов конфигурации (дата и время, строковые данные неограниченной длины и двоичные данные неограниченной длины). Новые типы полей используются при отключенном режиме совместимости и после выполнения реструктуризации соответствующего объекта конфигурации.

Для выполнения реструктуризации таблиц базы данных с изменением типов полей необходимо установить нужный режим режим совместимости и выполнить операцию реструктуризации информационной базы в конфигураторе (Главное меню — Администрирование — Тестирование и исправление).

В режиме совместимости с версией 8.3.7 поведение не изменилось.

При работе со всеми СУБД изменена структура индексов по полям составного типа. В результате уменьшено количество индексов. Такое построение индексов осуществляется при отключенном режиме совместимости и после выполнения реструктуризации соответствующего объекта конфигурации.
Для выполнения реструктуризации таблиц базы данных с изменением индексов необходимо установить нужный режим режим совместимости и выполнить операцию реструктуризации информационной базы в конфигураторе (Главное меню — Администрирование — Тестирование и исправление).
В режиме совместимости с версией 8.3.7 поведение не изменилось.

Ошибка 10161406 исправлена в 8.3.8.1747

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

 

Более подробно тут

Особенности 8.3.7

При работе с СУБД PostgreSQL и IBM DB2 ускорено удаление записей о фактическом периоде действия регистра расчета при удалении больших наборов записей.

Реализована поддержка СУБД Oracle Database версии 12.1.0.2 (Linux)

Доступно клиентское приложение, работающее под OS X 10.8 и старше (только в варианте 64-разрядного приложения)

Реализована поддержка дистрибутива Astra Linux Special Edition 1.4

Оптимизирована работа полнотекстового поиска и построение индекса полнотекстового поиска. Реализовано событие технологического журнала <INPUTBYSTRING> для отслеживания событий, связанных с вводом по строке.

При выполнении запроса, обращающегося только к данным табличных частей, исключено соединение с таблицей родительского объекта.
Оптимизировано чтение из СУБД объектов типа ДокументОбъект, СправочникОбъект, БизнесПроцессОбъект, ЗадачаОбъект, ПланВидовРасчетаОбъект, ПланВидовХарактеристикОбъект, ПланОбменаОбъект, ПланСчетовОбъект — чтение сопровождается неявным созданием транзакции только при наличии у объекта табличных частей и если СУБД используется «грязное» чтение вне транзакции.

Оптимизирована работа с условным оформлением в управляемой форме. Ускорено открытие управляемой формы с большим количеством элементов условного оформления.

Ускорена работа конфигураций (включая открытие форм) с большим количеством ролей.

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

Программные лицензии. Начиная с версии 8.3.7.1949 изменение нумерации сетевых адаптеров не будет приводить к нарушению привязки лицензии (если не поменялись другие параметры). Это актуально для работы в виртуальных средах.

Реализовано событие технологического журнала <CONFLOADFROMFILES>.

 

Реализовано событие технологического журнала <INPUTBYSTRING> для отслеживания событий, связанных с вводом по строке.

 

Реализовано журналирование исключительных ситуаций, возникающих в процессе работы отладчика, в технологическом журнале. Журналирование выполняется с помощью события <EXCP>.

 

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

В 8.3.7 могут быть избыточные блокировки на константах и регламентах.

Подробнее описание тут

Особенности 8.3.6

Реализована поддержка СУБД PostgreSQL версии 9.4.

Реализована возможность использования логических выражений в описании поля выборки и в выражениях фильтрации результатов запроса (предложение ГДЕ).

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

В технологическом журнале, в событияхSCALL и CALL, реализованы новые поляIName и MName , которые содержат дополнительную информацию о внутренних вызовах системы. Информация может использоваться специалистами фирмы «1С» при разборе обращений, направляемых в службу поддержки.

Реализовано отражение в технологическом журнале операций обновления индекса полнотекстового поиска. Реализованы события технологического журнала FTEXTCheck и FTEXTUpd. Реализован элемент технологического журнала ftextupd.

Реализовано событие технологического журнала <MAILPARSEERR>.

 

Подробнее описание здесь.

Отсутствии регистрации информационной базы в списке баз замедляет работу толстого клиента и конфигуратора

Обычно влияет сразу на всех пользователей в толстом клиенте. Поэтому после регистрации информационной базы в списке баз пользователя информационной системы НАЧИНАЕТ работать кэширование конфигурации на стороне клиента и ускоряет работу.

конфигуратор

 

см. также http://www.gilev.ru/systemperfomance/

Hyper-threading не всегда гарантия лучшей производительности

1. Статья на сайте Microsoft (в машинном переводе на скриншоте)
hyper

 

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

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

вхостегипер

 

см. также http://www.gilev.ru/systemperfomance/

Нагрузка на файлы

SELECT d.name, f.name, f.type_desc, f.physical_name,
[read b/ms] = num_of_bytes_read * 1.0/sample_ms,
[avg read latency] =
(1.0*s.io_stall_read_ms / (COALESCE(NULLIF(s.num_of_reads,0),1))),
[write b/ms] = num_of_bytes_written * 1.0/sample_ms,
[avg write latency] =
(1.0*s.io_stall_write_ms / (COALESCE(NULLIF(s.num_of_writes,0),1)))
FROM sys.master_files AS f
INNER JOIN sys.databases AS d
ON f.database_id = d.database_id
INNER JOIN sys.dm_io_virtual_file_stats(default, default) AS s
ON d.database_id = s.database_id
AND f.[file_id] = s.[file_id]
order by 8 desc

Обнаружение повышения области блокировки таблицы

Определяем ID объекта — исследуемой таблицы в базе данных

USE [trade_debug] Select * from Sys.objects WHERE Sys.objects.name = ‘_Reference82’

где _Reference82 имя таблицы

ObjectID

Далее настраиваем трассировку SQL server profiler:
PRprop

Устанавливаем фильтр:

PRfilter

Отключение эскалации чревато дополнительной нагрузкой на сервер, это надо учитывать:

USE [trade_debug] ALTER TABLE _Reference82 SET (LOCK_ESCALATION = DISABLE)

Проверить режим эскалации блокировок можно с помощью скрипта:

USE [trade_debug] SELECT lock_escalation, lock_escalation_desc, name FROM sys.tables WHERE lock_escalation_desc=’DISABLE’

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

NUMA – Non Uniform Memory Access

На русский язык это можно перевести как Неравноценный Доступ к Памяти.

Современные многосокетные сервера, по сути, представляют собой несколько изолированных односокетных компьютеров, объединенных на одной материнской плате. Каждый процессор монопольно владеет своими слотами оперативной памяти, и только он имеет к ней доступ. Аналогично, каждый процессор имеет свои персональные PCI-E шины, к которым подключены различные устройства материнской платы, а так же слоты расширения PCI-E. Процессоры соединены между собой высокоскоростной шиной обмена данными, по которой они получают доступ к «чужим» устройствам, делая запрос на это соответствующему процессору-хозяину. По понятным причинам, доступ процессора к «своей» памяти происходит гораздо с меньшими накладными расходами, чем к «чужой».

смотрите также Особенности 16 слотовых материнских плат для голдов и 1С

КЕЙС: Как мы ускорили обмены с 10 часов до нескольких минут

Если в Вашей компании используется обмен между информационной системой на платформе 1С:Предприятие 8 и сайтом, или вы интересуетесь приемами повышения производительности, то думаю, Вам будет интересно посмотреть, как мы решили следующую задачу.
Клиент обратился с проблемой неработающего обмена с сайтом.
В своей работе Заказчик использует информационную систему на основе «Управление торговлей ред. 11». Конфигурация регулярно выполняет обмен с сайтом. Обмен осуществляется через XML файлы и происходил очень долго. При выгрузке данных для сайта клиент столкнулся с тем, что скрипт загрузки со стороны сайта не успевал обработать выгруженные данные.
Чтобы улучшить ситуацию, Заказчик своими силами разбил выгрузку на порции. Но это не принесло полного решения проблемы.
Чтобы решить проблему, заказчик пригласил меня.
Если Вы не сталкивались с методами повышения производительности раньше, то отмечу, что так или иначе все сводится к нахождению «избыточной работы» и устранению ее.
Проблема оказалась комплексной. Со стороны 1С при выгрузке в файлы попадала избыточная информация. Т.е. передавалось больше данных, чем потом реально использовалось. А со стороны сайта модуль загрузки выполнял лишние действия.
Кроме этого, сама выгрузка, даже по небольшому количеству товаров, занимала длительное время.
Чтобы понять, «какая деятельность лишняя», нужно посмотреть максимально подробно, из чего состоит вся процедура выгрузки данных.
Замер производительности «отладчиком» операции «выгрузки» показал следующее распределение длительности между операциями. 80% времени выполнялся запрос, собирающий данные для выгрузки. Мне повезло, так как 80% времени означает, что если улучшить этот запрос, то можно не прилагать много усилий к другим операциям, ведь эффект на всю выгрузку будет виден сразу. Еще 14% процентов замера выгрузки проверялось какое-то условие. Возможно, на результаты замера свое влияние оказала посторонняя нагрузка (замер выполнялся не «в чистых условиях», на сервере работали и другие пользователи), но этот замер дал представление о проблеме.
Замер до оптимизации
Самой простой проблемой оказалось условие «Если». Полностью условие выглядело так:
Если Параметры.РежимПошаговойВыгрузки
    И НЕ Параметры.ВыгружатьКраткийПакетПредложенийВРежимеИзменений
    И НеОпределено = ВыгруженныеТовары.Найти(Параметры.ВыборкаЦен.Номенклатура) Тогда
Проблема заключалась в выражении ВыгруженныеТовары.Найти(Параметры.ВыборкаЦен.Номенклатура)
Здесь ВыгруженныеТовары — это массив позиций номенклатуры, выгружаемой на текущем шаге. Количество элементов задается в параметрах выгрузки и составляет 400. То есть количество невелико.
Данные этого массива в процедуре никак не использовались, поэтому было решено заменить массив на соответствие. Соответствие представляет собой индексированную коллекцию, и поиск по ней выполняется очень быстро.
В качестве ключа использовал ссылку на номенклатуру, а значение «Истина». После доработки условие стало выглядеть так:
Если Параметры.РежимПошаговойВыгрузки
    И НЕ Параметры.ВыгружатьКраткийПакетПредложенийВРежимеИзменений
    И НеОпределено = ВыгруженныеТовары[Параметры.ВыборкаЦен.Номенклатура] Тогда
и общее время  по этому выражению составило 34 секунды.
Количество повторений этого фрагмента определяется исходным алгоритмом.
Вторым проблемным фрагментом по замеру является запрос, выполняющий сбор данных для выгрузки.
 МассивРезультатовЗапроса = Запрос.ВыполнитьПакет();
В данном замере время его выполнения составило  более 8 часов. Запрос представляет из себя пакет из более 30 запросов.
Часть данного запроса получается на основе схемы компоновки данных с применением отборов. Отбор накладывается по номенклатуре по условию «в группе». При компоновке макета компоновщик, по возможности, добавляет в результирующий запрос условия, соответствующие отбору.
Например, запрос такого вида:
ВЫБРАТЬ РАЗРЕШЕННЫЕ
                СвободныеОстаткиОстатки.Номенклатура КАК Номенклатура,
                СвободныеОстаткиОстатки.Характеристика КАК Характеристика,
                СвободныеОстаткиОстатки.ВНаличииОстаток КАК ВНаличииОстаток,
                СвободныеОстаткиОстатки.ВРезервеОстаток КАК ВРезервеОстаток
ПОМЕСТИТЬ ВремОстатки
ИЗ
                РегистрНакопления.СвободныеОстатки.Остатки() КАК СвободныеОстаткиОстатки
 после применения отбора примет такой вид:
ВЫБРАТЬ РАЗРЕШЕННЫЕ
                СвободныеОстаткиОстатки.Номенклатура КАК Номенклатура,
                СвободныеОстаткиОстатки.Характеристика КАК Характеристика,
                СвободныеОстаткиОстатки.ВНаличииОстаток КАК ВНаличииОстаток,
                СвободныеОстаткиОстатки.ВРезервеОстаток КАК ВРезервеОстаток
ПОМЕСТИТЬ ВремОстатки
ИЗ
                РегистрНакопления.СвободныеОстатки.Остатки(,Номенклатура В ИЕРАРХИИ (&amp;П)) КАК СвободныеОстаткиОстатки
 После компоновки данных это условие добавилось к нескольким запросам с полем номенклатура. Данное условие плохо сказывается на скорости выполнения запросов.
Чтобы решить эту проблему, в исходный запрос схемы компоновки данных добавил запрос выборки номенклатуры во временную таблицу. И уже данные этой таблицы использовал в качестве фильтра в последующих запросах. Также настроил схему компоновки данных таким образом, чтобы отбор по номенклатуре применялся только для добавленного запроса выборки номенклатуры. После этих манипуляций результирующий запрос принял такой вид (фрагмент):
ВЫБРАТЬ
                Номенклатура.Ссылка
ПОМЕСТИТЬ втНоменклатура
ИЗ
                Справочник.Номенклатура КАК Номенклатура
ГДЕ
                Номенклатура.Ссылка В ИЕРАРХИИ(&amp;П)

;

ВЫБРАТЬ РАЗРЕШЕННЫЕ
                СвободныеОстаткиОстатки.Номенклатура КАК Номенклатура,
                СвободныеОстаткиОстатки.Характеристика КАК Характеристика,
                СвободныеОстаткиОстатки.ВНаличииОстаток КАК ВНаличииОстаток,
                СвободныеОстаткиОстатки.ВРезервеОстаток КАК ВРезервеОстаток
ПОМЕСТИТЬ ВремОстатки
ИЗ
                РегистрНакопления.СвободныеОстатки.Остатки(,Номенклатура В (ВЫБРАТЬ т.Ссылка ИЗ втНоменклатура как т)) КАК СвободныеОстаткиОстатки
 Также анализ запроса выявил и другие причины его медленного выполнения:
  • Соединение с подзапросами
  • Отсутствующие или неоптимальные индексы
  • Излишняя выборка данных
В общем, классика жанра.
Решив данные проблемы в комплексе, удалось сократить время выполнения результирующего запроса при полной выгрузке до 78 секунд.
Говоря об оптимизации в теоретическом контексте, часто забывается, что в реальной жизни любая коммерческая работа должна быть рентабельна. Несколько запросов пакета еще имели потенциал для ускорения, но полученный результат полностью устроил клиента, и на этом мы остановились.
Замер после оптимизации
После оптимизации время полной выгрузки не превышает 5 минут. Время выгрузки тестовой группы из 15 товаров – несколько секунд (до оптимизации –1.5 минуты).
Заказчик остался очень доволен и сказал много теплых слов. Всегда приятно не просто сделать хорошо работу, но и услышать слова благодарности.
Надеюсь, мой опыт пригодится Вам, и Вы тоже сможете помочь решить подобные проблемы.

 

Повышение параллельности работы пользователей в компании Авилон

Отзыв о проделанной работе по оптимизации для тысячи пользователей

Авилон отзыв

Проект сделан с использованием технологий http://www.gilev.ru/online/
Ориентировочная стоимость  аналогичных работ – 150 000 руб.

Другие отзывы о проделанных нами работах можно посмотреть здесь http://www.gilev.ru/results/

Улучшения по производительности при отключении режима совместимости 8.2.13

Почему мы рекомендуем отключать режим совместимости с 8.2.13

Улучшения в версии 8.2.14

  • Оптимизировано выполнение запроса вида «ТипЗначения(Поле1) = ТипЗначения(Поле2)», если «Поле1» и «Поле2» содержат значения ссылочного типа.
  • Оптимизированы выборки, выполняемые порциями (используемые в методах «Выбрать()», а также при реструктуризации), для всех СУБД.
  • Оптимизирован ряд механизмов сервера 1С:Предприятия для повышения масштабируемости и производительности при большом количестве работающих пользователей.
  • Оптимизирована работа с файлами на диске (включая временные файлы) для следующих механизмов: полнотекстовый поиск, справка, объект «ИнтернетПочта».
  • Оптимизирована работа кластера серверов с данными сеанса.
  • Ускорена работа функций «ПолучитьСоединенияИнформационнойБазы()» и «ПолучитьСеансыИнформационнойБазы()» при большом количестве зарегистрированных пользователей.
  • Повышена производительность и масштабируемость модуля расширения веб-сервера.
  • В веб-клиенте оптимизировано обновление табличного документа после выполнения интерактивного редактирования, а также после программного изменения отдельных ячеек табличного документа.
  • Уменьшено количество серверных вызовов в части функциональности в веб-клиенте.
  • Ускорена работа механизма управляемых блокировок.
  • При отключенном режиме совместимости изменен режим хранения констант и настроек регистров накопления. Для каждого объекта используется своя таблица базы данных. Это означает улучшенную параллельность работы пользователей. При включении режима совместимости (в значение «Версия 8.2.13» или «Версия 8.1») выполняется обратная конвертация для обеспечения возможности запуска прикладного решения с помощью версии 8.2.13. Требуется реструктуризация!

Улучшения в версии 8.2.15

  • Для полей управляемой формы, отображающих реквизит составного типа, ускорено открытие списка быстрого выбора в тех случаях, когда в составной тип входят ссылочные типы с разными настройками быстрого выбора.
  • Уменьшено влияние режима отладки на скорость работы в режиме «1С:Предприятие» для тонкого клиента, толстого клиента, сервера и внешнего соединения.
  • Увеличена производительность работы системы в случае использования двух и более разделителей или одного разделителя с типом «Строка».
  • Оптимизирован запуск клиентского приложения.
  • Оптимизировано открытие формы веб-клиента при использовании большого количества элементов в условном оформлении формы.
  • Оптимизировано открытие формы отчета в веб-клиенте, который содержит большое количество элементов условного оформления.
  • Для блокировочных СУБД (Microsoft SQL Server, IBM DB2) изменение пользователя информационной базы в транзакции более не конфликтует с процессом аутентификации, кроме случая, когда аутентификацию пытается выполнить пользователь, данные которого изменены, и транзакция, в рамках которой были выполнены изменения, не завершена.
  • Для нового независимого и непериодического регистра сведений, индекс по измерениям является кластерным. При создании первого регламентного задания, индекс по идентификатору задания также является кластерным. Требуется реструктуризация! Для создания необходимых индексов в существующей информационной базе можно выполнить одно из следующих действий:
    • Выполнить реструктуризацию базы данных.
    • Выполнить загрузку информационной базы из файла «.dt».

Улучшения в версии 8.2.17

  • Реализована поддержка СУБД Microsoft SQL Server 2012.
  • Для работы с Microsoft SQL Server 2008 R2 возможно использование Native Client. При использовании Native Client возможно использование протокола SHARED MEMORY, если оба сервера находятся на одном компьютере. Использование протокола SHARED MEMORY (при использовании Native Client) возможно, начиная с версии Microsoft SQL Server 2005. Можно получить значительное ускорении при использовании SHARED MEMORY.

Улучшения в версии 8.2.18

  • Реализована поддержка Native Client для СУБД Microsoft SQL Server 2005 и Microsoft SQL Server 2012.
  • Оптимизирован сервис нумерации кластера серверов «1С:Предприятия», в результате чего исключено снижение производительности сервера при длительной работе.
  • Оптимизирована работа тонкого и толстого клиентов, работающих с файловой информационной базой, расположенной на сетевом ресурсе, при многопользовательском доступе. Ускорены различные операции с информационной базой, включая открытие и редактирование форм объектов, просмотр форм списков, запись объектов, проведение документов и т.д.
  • Повышена масштабируемость сервера «1С:Предприятия» при работе с высокой нагрузкой и большим количеством одновременно работающих пользователей.
  • Ускорена работа функций СтрЧислоСтрок() и СтрПолучитьСтроку() при работе в тонком клиенте, толстом клиенте и на стороне сервера.
  • Оптимизировано получение писем с помощью объекта ИнтернетПочта.
  • Ускорена работа функции ЗначениеЗаполнено() в том случае, если параметром функции выступает выражение, состоящее из получения свойства какой-либо переменной (как «через точку» так и с помощью операторного способа ([])) любого уровня вложенности.
  • В таблицу журнала документов добавлен индекс по полю Ссылка. В результате повышается скорость работы динамического списка журнала документов, а также поиск по ссылке в журнале документов.
  • Оптимизирована генерация запросов для СУБД Microsoft SQL Server:
    • Сокращено количество повторяющихся планов запросов;
    • Сокращено количество компиляций запросов в Microsoft SQL Server;
    • Уменьшен размер кеша планов запросов Microsoft SQL Server;
    • Уменьшено время работы некоторых запросов;
    • Улучшились создаваемые планы запросов в некоторых случаях.

     

  • Оптимизирована работа динамического списка и динамической выборки из базы данных в случае наличия упорядочивания выборки по убыванию.Для Microsoft SQL Server эти операции оптимизированы дополнительно, а также оптимизирована операция реструктуризации.
  • При работе в клиент-серверном варианте в режиме управляемых блокировок, изменен механизм генерации новых ссылок для объектов информационной базы. Ссылки генерируются строго последовательно для всех соединений сервера «1С:Предприятие» с сервером СУБД. В результате сокращена фрагментация таблиц и индексов в базе данных, а также повышена скорость вставки и чтения записей таблиц базы данных.
  • Оптимизирован механизм балансировки нагрузки в кластере серверов.
  • Оптимизировано получение из базы данных прикладных объектов без табличных частей при вызове метода ПолучитьОбъект() и при обращении к свойствам «через точку» от ссылки.
  • Оптимизирована работа сервера «1С:Предприятия» при выполнении запросов к объектам, на которые наложены ограничения доступа к данным.
  • При работе с СУБД Microsoft SQL Server оптимизированы операции, использующие конструкцию IN (…) с одним значением в списке.
  • Оптимизирован запуск клиентских приложений, фоновых и регламентных заданий.
  • Ускорена работа системы при частом выполнении фоновых заданий и вызовов web-сервисов.
  • Ускорено открытие управляемых форм.Оптимизация наиболее заметна в случае многопользовательского доступа (с помощью тонкого клиента) в файловом варианте информационной базы, расположенной на сетевом ресурсе.
  • Ускорена работа некоторых видов запросов в файловом варианте информационной базы, например:
    • Запросы вида ВЫБРАТЬ ПЕРВЫЕ 1 …;
    • Сравнение двух списков с помощью оператора языка запросов В: … (Объект, СчетФактура) В (&СписокОбъектовИПартий) ….

     

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

Улучшения в версии 8.2.19

  • Оптимизирован запуск системы при большом количестве запусков, выполняемых с небольшими интервалами между запусками.
  • Проведена оптимизация внутренних механизмов платформы, улучшающая производительность и масштабируемость кластера серверов «1С:Предприятия».
  • Для независимых регистров сведений без измерений реализовано создание отдельных индексов по разделителям. Требуется реструктуризация!
  • Для разделителей с режимом разделения Независимый и совместный реализован дополнительный индекс в объектных таблицах, включающий значение разделителя, а также первичный ключ таблицы. Индекс позволит избежать эскалаций блокировок в СУБД при некоторых сценариях работы с таблицей.
  • При работе в веб-клиенте оптимизированы следующие операции с табличным документом: открытие, построчная прокрутка, постраничная прокрутка.

ВАЖНО. ДЛЯ ПОЛУЧЕНИЯ ЭФФЕКТА ОТ ВЫКЛЮЧЕНИЯ СОВМЕСТИМОСТИ НАДО СДЕЛАТЬ «РЕСТРУКТУРИЗАЦИЮ» В «ТЕСТИРОВАНИИ И ИСПРАВЛЕНИИ»!

 

Отзыв на курс Кухара Богдана «23 способа ускорить 1С»

С чего все началось с того, что по инерции ухватился за слова «ускорить работу 1с»

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

получил симпатичное письмо     ну собственно и посмотрел само видео

видео Кухара Богдана

Мы благодарны за то, что  Богдан попросил / разрешил дать обратную связь

отзыв   что с удовольствием и сделаем:

способ 1 от Кухара На работу пользователей влияет много факторов. Покупать лицензии на терминальный сервер, не проведя предварительно анализа причин замедления — деньги на ветер. Точнее это как в рулетку «повезет / не повезет».

Каким плюсом обладает терминальный сервер — он предоставляет пользователям «примерно равные по мощности аппаратные ресурсы». Естественно, если частота процессора на терминальном сервере будет выше чем на Вашем ноутбуке, то это может дать эффект. Все же логично, вы подключаетесь с более мощного компьютера по факту. Но для этого еще надо купить более мощный терминальный сервер. Если например на вашем ноутбуке будет частота 3,5 Гц, а на терминальном сервере 1,8 Гц, то Вы наверняка не улучшите, а ухудшите производительность. Дьявол в деталях.

Еще один момент — это физическая удаленность пользователя от сервера 1С:Предприятие. Использовать терминальный сервер имеет смысл, если он находится на том же «роутере / маршрутизаторе» что и сервер 1С, а компьютеры пользователей например в другом сегменте сети. Если компьютеры пользователей находятся также как и терминальный сервер в одном сегменте сети, не факт, что вы получите выигрыш от терминального сервера. Если Вы уверены, что с терминального сервера будет «быстрее», то до разворачивания службы терминалов зайдите на сервер под пользователем с правами локального администратора и запустите 1С:Предприятие — убедитесь в своей правоте на практике!

Способ 2 от Богдана Иногда люди легко попадаются на уловки маркетологов.

Можно сказать что будет «быстрее» и многие забывают куда более важный вопрос «А на сколько быстрее?».

Есть очень простой способ — запустить нагрузочный тест http://www.gilev.ru/tpc1cgilv/  в обычном варианте, и по методу 2 от Богдана. Что получилось у Вас?

Совет 3 от Богдана Хочется подколоть » запустил дефрагментацию на своем OCZ Vector, не помогло, что я делаю не так?»

Для тех кто не в курсе, на SSD полностью занятое пространство куда больше имеет эффекта на производительность. А вот с дефграментацией особо толку не будет.

Ради справедливости надо сказать, что если Вы на MS SQL Server решили использовать обычные HDD, то просто сразу отдавайте файлу весь диск или максимально много. Не делайте «шринк» базы данных! Тоже относится к tempdb!

Совет 4 Вообще то совет правильный формально. Единственное, если админ не читает документацию и ставит на скуль антивирус, то он вызывает большие сомнения в плане квалификации.

Если говорить более широко, ЛЮБАЯ ФУНКЦИОНАЛЬНОСТЬ ТРЕБУЕТ РЕСУРСОВ.

На самом деле рекомендуем не ставить со скулем ни каких других ролей сервера. Чем большей ролей, тем больше они будут конкурировать за ресурсы сервера. И фтп сервер, и почтовый сервер и все что угодно будет создавать замедление. Чем активней другая роль, тем меньше достанется СУБД ресурсов.

Совет 5   Вообщем то совет пересекается с высказанным ранее — отключайте любой функционал, который не используете.

Все что работает «фоном» и потребляет ресурсы, уменьшает их для основных задач.

Но если уж продолжать эту тему, далеко не всегда можно выключить полнотекстовый поиск.

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

Совет 6 Звучит как  «перепишите Вашу программу» 🙂

На текущий момент по нашему опыту скорость в «толстом» клиенте по отрисовке интерфейса работает быстрее нежели в «управляемых формах». С высокой вероятностью вы получите обратный эффект.

Совет 7 Вообще использовать веб-сервер надо осторожно. Если у Вас все пользователи в локальной сети, то это фактически «лишнее звено».

Процитирую партнерский форум 1С https://partners.v8.1c.ru/forum/topic/1187394 о медленной работе веб-браузера «Проблема нам известна. Считаем ее достаточно важной.На данный момент ведутся задачи по данному направлению.»

Мы рекомендуем использовать при работе через http тонкий клиент 1с, а не браузер по возможности.

Совет 8   Капитан очевидность — хороший вообщем то совет, только звучит более правильно он так «попробуйте разные варианты, выберите лучший» )))

Совет 9 Следуйте этому совету, если хотите себя дискредитировать. Быстрее работает то ПО, которое обладает меньшим функционалом как правило. Чем меньше функций программа умеет выполнять тем она быстрее работает.

Только вот ведь загвоздка, обычно бизнесу нужна не только производительность, но

1. отказоустойчивость

2. техподдержка продукта

3. безопасность

4. наличие специалистов

5. совместимость с другими приложениями

Хотите проблемы, ставьте старое ПО, все ошибки, которые исправлены в более поздних версиях, там будут Вам доступны!

Способ 10 ускорить 1с   Хочется напомнить про наши комментарии к способу №3 — заранее выделите нужное дисковое пространство под данные и логи, не изобретайте велосипед!

Способ 11 увеличить быстродействие 1с О! И снова об избыточном функционале.

Избыточность вредна. Но не нравится сам подход на этом слайде.

Вы должны отдавать отчет себе за каждую запущенную или остановленную службу. Если увлечься, то может так оказаться, что Вам придется восстанавливаться из бэкапа. Вы его сделали?

Если Вы начинающий админ, лучше оставьте галочки «по умолчанию», не торопитесь ломать систему.

Способ 12 Для начало надо объяснить, что MS SQL Server смотрит на возможности процессора (количество ядер) и сам автоматически прикидывает, какое количество рабочих потоков он сможет обслужить. При этом ресурсы под каждое соединение выделяются по мере их создания, а не заранее. Зная как работает 1С:Предприятие, только если у Вас сотни пользователей массово запускают 1с или очень активно пишут данные, есть смысл ковырять эти настройки. В большинстве случаев вы ничего не заметите.

Совет 13 по тюнингу 1с Вообщем то не плохой совет. Но сильного «буста» вы не увидите скорее всего. Это сработает на «слабых» серверах. Если у Вас слабый сервер, лучше обновите железо, это дальновидней.

Совет 14 оптимизации 1с Жуть, зачем блокировать базу? Используйте время минимальной загруженности. Если таблицы и индексы большие, то не надо все за один раз, в разное время обслуживайте разные объекты. Да, и переиндексацию надо делать не «тупо» раз в какой то период, а по мере набегания этой самой дефраментации индексов. Для анализа этой ситуации используйте http://www.gilev.ru/sqlsize/

Совет 15 Вообщем то если купить более быстрый диск то будет быстрее. Но у вот у нас к примеру уже SSD. И кстати, куда больше пользы для потоковой скорости 1С даст частота процессора как ни странно, обязательно изучите http://www.gilev.ru/bestproc1c/ наши рекомендации по подбору процессора, это 50% всей производительности железа.

Совет 16 как ускорить 1с Хороший способ. Только применять надо по другому — кладите туда tempdb!

А еще более актуальный вариант в ближайший год будет это использовать SSD для «расширенного буферного пула» в MS SQL Server 2014.

На рам-диск размещать надо различные кэши, временные файлы, но ни как не базу данных.

Способ 17 повышение производительности 1с Ну да, еще купите дисков, потому в 10 рейде например 3 диска 5го рейда заюзать не получится. А для SSD использование рейд-массивов это вообще отдельная история, они обычно в этом случаи изнашиваются зеркально ). Можно еще раз сказать про капитана очевидность — купите мощнее сервера!

Совет 18   Обычно виртуальные машины нужны не для повышения производительности, а для решения других задач:

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

— организовать отказоустойчивость

— организовать облако и быстрое выделение нужных мощностей

Ну если Вы хотите порушить решаемые задачи, тогда этот совет для Вас!

Способ 19 повышение быстродействия 1с Наверное эзотерические знания это не плохо. Не очень понятно, как на фоне покупки SSD, использования 10 рейда вместо 5го выглядит «слабый» сервер, но уж точно не надо перемещать на компьютер пользователя: — компьютер пользователя не оптимизирован под коллективную конкуренцию ресурсов; — на нем стоит не серверная операционная система, которая просто не позволит вам больше 10 подключений — пользовательский компьютер на ночь часто выключают — еще компьютер пользователя можно «тупо вынести с предприятия», а заодно пароли и т.п. — как вы будете отвечать за компьютер, на котором помимо сервера 1с еще работает другой пользователь, вы думаете он ребутнет, не сможет подвесить систему или запустить торрент на закачку фильмов?

Совет 20 оптимизации 1с Ну вот на самом деле здесь бы как раз порекомендовать использовать терминальный сервер и нет проблем. Используйте вай-фай!

Совет 21 улучшение 1с Ну вот это спорный момент. К пример у вас на сервере 100 баз размером 10 Гб каждой базы данных. Из этой логики нормально будет иметь оперативки 10-20 Гб. Советуем ориентироваться на показатели «Частоты попадания в кэш» у MS SQL Server, если активной подкачки с диска нет, значит памяти хватает.  Но спорить с тем что чем больше памяти тем лучше не будем. Сквозь весь курс проходит красной линией «купите мощнее сервер»…

Совет 22 Чтобы 1с работала лучше

Ну тут можно дать и более радикальный совет. Всегда ограничивайте MS SQL Server по максимальному объему оперативной памяти таким образом, чтобы операционной системе оставалось 5-10% от общего объема оперативной памяти (в том числе для нужд подкачки) , и не менее 2 Гб при этом.

Совет 23

 

Особенностям производительности файлового и клиент-серверного варианта посвящена очень хорошая статья http://www.gilev.ru/mssqlvsfile/ . Мы получили много откликов и только больше убедились в том, что лучший способ не искать «более хорошую программу», а разбирать проблемы, выяснять причины и устранять их.

Если вы думаете что замена MS SQL Server на Оракл или DB2 что то улучшит, то это мы хотим сэкономить Вам кучу времени и денег — правьте код 1С а  не меняйте MS SQL Server на что то другое!

Есть ли смысл комментировать, если не писать конструктивно. А теперь

НЕСКОЛЬКО СОВЕТОВ ОТ НАС:

Совет 1. Не надо делать как «соседу помогло значит и мне поможет». Всегда выясняйте в логах конкретные причины. Не фантазируйте «ну наверно дело ….». Докажите, локализуйте, воспроизведите проблему!

Совет 2. Найдите самое узкое место. При чем и в железе, и в коде.

Используйте http://www.gilev.ru/querytj/ ,  http://www.gilev.ru/hardware/ . Начните устранять проблему с самого узкого места.

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

Совет 4. Если Вы администратор, сервера не загружены, а 1с «висит», не надо занимать позицию «я вот отвечаю за это, поэтому чем смогу помогу». Зовите программистов. В конце концов позовите нас!

Совет 5. Дорогой сервер — не означает что самый быстрый сервер. Разные конфигурации 1С могут по-разному нагружать аппаратные ресурсы. Делайте тест-драйв покупаемых серверов и проводите нагрузочное тестирование.

Совет 6. Если у Вас в системе много взаимоблокировок, а конфигурация на управляемых блокировках, включите версионирование. Это даже если не устранит проблему, то поможет ее быстрее локализовать. Если блокируемые ресурсы используют чтение, то версионирование устранит взаимоблокировки субд. Иначе у вас блокировки только блокировки на запись, вам надо уменьшать время транзакций (например разбивать на более мелкие порции записываемые данные). Используйте http://www.gilev.ru/deadlock/ для дальнейшего анализа.

Совет 7. Консультируйтесь не у толпы по вопросам производительности, у толпы нет финансовой ответственности за сказанное! Спрашивайте тех, кто занимается каждый день, в том числе нашей команда http://www.gilev.ru/forum/. Мы как минимум рискуем репутацией. В платных аудитах и работах мы несем денежные гарантии!

 

 

 

 

 

Медленное подключение по RDP из Windows 7 к серверу Windows Server 2003

пример http://social.technet.microsoft.com/Forums/ru-RU/03869b70-6e56-4f98-9bdc-25c65da7c72f/-

На клиенте Windows7 выполните

netsh interface tcp set global autotuninglevel=disabled
Если не поможет, дополнительно выполните

netsh interface tcp set global rss=highlyrestricted

 

Как включить отладку на сервере 1С

Если требуется включить отладку на сервере 1С 8.2, необходимо проделать следующее:

— запустить редактор реестра
regedit
— открыть в нём раздел
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\1C:Enterprise 8.2 Server Agent
— найти параметр
ImagePath
— изменить его, добавив параметр -debug .
Например, было:

«C:\Program Files (x86)\1cv82\8.2.17.169\bin\ragent.exe» -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d «C:\Program Files (x86)\1cv82\srvinfo»

стало:

«C:\Program Files (x86)\1cv82\8.2.17.169\bin\ragent.exe» -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -debug -d «C:\Program Files (x86)\1cv82\srvinfo»

— перезапустить службу 1C:Enterprise 8.2 Server Agent.

Для сервера 1С 8.1 всё делается точно так же, изменения только в названии служб и пути к файлу запуска ragent.

Сервер как «демон» ОС Linux

Если в отладочный режим необходимо перевести сервер «1С:Предприятия» работающего в режиме «демона» в ОС Linux, то необходимо выполнить следующие операции:

1. Остановить сервер «1С:Предприятия».

/etc/init.d/srv1cv83 stop

2. В конфигурационном файле srv1cv83 установить значение параметра SRV1CV8_DEBUG в значение 1.

SRV1CV8_DEBUG=1

3. Сохранить конфигурационный файл.

4. Запустить сервер «1С:Предприятия».

/etc/init.d/srv1cv83 start

Примечание.  Для RPM-системы нужно править не скрипт (/etc/init.d/srv1cv83), а конфигурационный файл, который находится тут /etc/sysconfig/srv1cv83

Процессор — пороги счетчиков

Процессор является одним из объектов, которое надо обязательно проверять в качестве узкого места. Тут надо понимать, что характеристик производительности много — частота процессора, частота системной шины, размеры кэшей различных уровней, наборы команд и т.д. Нас же интересует относительная загруженность процессора и очереди к процессору операций.

 

Processor\% Processor Time

Порог: усредненно порог для процессоров составляет 65 процентов.

Значение: Этот счетчик является основным показателем деятельности процессора. Высокие значения многих не обязательно плохо. Однако, если значения других счетчиков процессора растут линейно ( % Privileged Time или Processor Queue Length) , то это обозначает проблемы. Убедитесь, что у вас схема энергоснабжения в режиме максимальной производительности.

При анализе загруженности сервера 1С:Предприятие необходимо в некоторых случаях собирать нагрузку по каждому ядру. Для выяснения какой из сеансов нагружает ядро, смотрите в консоли сервера 1С в сеансах максимум по колонке «Время вызова (текущее)», но не в вызове СУБД «Время вызова СУБД (текущее)»

ЗагруженностьПроцессора

Processor\% Privileged Time

Порог: значение более 75 процентов означает узкое место.

Значение: Этот счетчик показывает процент времени работающих потоков в привилегированном режиме. Когда Ваше приложение вызывает  функции операционной системы (например чтение файла или передачу данных по сети или выделение памяти),то они вызываются в привилегированном режиме.

System\Context Switches/sec

Порог: При контексте менее 5000 в секунду на процессоре не стоит волноваться. Если переключение контекста превышает 15000 в секунду на один процессор, то есть проблемы.

Значение: переключение контекста происходит, когда когда процесс более высоким приоритетом исполняется и блокирует процесс более низким приоритетом. Большое количество переключение контекста может произойти и для процессов с одинаковым уровенем приоритета. Это часто означает, что слишком много потоков, конкурирующих за процессоры в системе. Если вы не видите высокой утилизации процессора, и и при этом есть очень низкий уровень переключения контекста, это может означать, что потоки блокируются.

Processor(*)\% Processor Queue Length

Порог: не больше 2х на 1 ядро, т.е. 16 ядер – 32 очереди

Значение: При нехватке ядер процессора возникает ожидание в виде очередей. Убедитесь, что у вас схема энергоснабжения в режиме максимальной производительности. Рекомендуется добавить ядер. Можно заменить на процессор из той же серии, но с большим количеством ядер. При этом старайтесь не увеличивать количество ядер в «ущерб» частоте процессора.

Для анализа используйте онлайн-сервис.

Типичные ошибки при подборе процессоров

» Процессоры и платформы фирмы ХХХ хорошие, остальные плохие».
«Процессоры и платформы одной фирмы за сильно меньшую цену обеспечивают сильно лучшие эксплуатационные характеристики — производительность, энергопотребление и тепловыделение и т.п.»

И то и другое, мягко говоря, маркетинг.

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

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

«Купим сейчас с одним процессором, потом докупим при нужде еще один/три»

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

Во-вторых, 99% гарантированную работоспособность в паре/четверке можно получить только от процессоров с одним и тем же степпингом, в особо запущенных случаях — из одной и той же партии. Понятно, что найти через несколько лет пару к процессору — весьма нетривиальная, иногда и нерешаемая задача — т.е. подобный запас — на Ваш и именно Ваш страх и риск.

Воспользуйтесь нашими услугами по побору серверов.

Влияние HDD на быстродействие 1С:Предприятие 8

О чем пойдет речь

Только вариант клиент-серверной версии 1C:Предприятие 8 под MS SQL Server.

Только кластеры NTFS и блоки RAID-массива (пусть даже это RAID0 из одного диска) в операционных системах Windows Server 2003 (и Windows XP).

Внимание! Действие статьи не распространяется на RAW-партиции и простые диски HDD, не входящие ни в какой RAID-массив с собственным контроллером.

Также маловероятна проблема в в Windows Server 2008 и Windows Vista.

Предмет оптимизации

«Размер блока и размер кластера желательно устанавливать одинаковыми, например, для баз данных SQL Server очень часто слышны рекомендации выбирать и там и там 64Кб. Однако, операционная система создает самый первый кластер (блок начальной загрузки MBR) размером в 63Кб. Эта особенность NTFS означает, что каждый последующий кластер будет сдвинут на 1Кб на предыдущий блок. Т.е. кластеры окажутся смещёнными относительно границ блоков массива. Такая ситуация приводит к тому, что одна операция чтения или записи кластера будет затрагивать два сектора и будет приводить к удвоению числа запросов ввода-вывода.»(цитата Александра Гладченко).

Источник Disk Partition Alignment for SQL Server (eng) и http://sqlblog.com/blogs/linchi_shea/archive/2007/02/01/performance-impact-of-disk-misalignment.aspx

Официальное подтверждение проблемы Microsoft и тут.

Средняя степень влияния

Практически все основные типы нагрузки ввода-вывода SQL Server получат выигрыш от этой оптимизации от 9 до 23%.

Способы определить наличие проблемы

1. С помощью DiskPart (Описание программы http://technet.microsoft.com/ru-ru/library/cc773140.aspx и http://support.microsoft.com/kb/300415/ru).

diskpart -i

Наличие цифры 32256 (потому что смещение offset 32256 / 512 байт на сектор = 63).

2. С помощью утилиты DiskExt.

3. С помощью обработки для 1С:Предприятие 8.1 NTFS.epf

Необходимо исправить геометрию RAID массива

1. Скопировать ВСЮ информацию с диска (предположим, что имя диска D:) на другой локальный диск (например диск E:) используя команду xcopy с параметрами копирования файлов и каталогов включая ownership и ACL.

xcopy D:\*.* E:\DiskD /E /K /O /X

Запустить Disk Management и посмотреть какой физический диск соответствует логическому диску D; допустим это диск 1.

Запустить Disk Management и удалить логический раздел D на физическом диске 1. (Т.е. чтобы выровнять раздел, нужно удалить смещённый раздел).

2) Внимание! Утилита DISKPART уничтожит данные на диске.

В командной строке запустить утилиту DISKPART и выполнить следующие команды:

DISKPART> select disk 1

Disk 1 is now the selected disk.

DISKPART> create partition primary align=64

DiskPart succeeded in creating the specified partition.

DISKPART> exit

Примечание. Команда «create partition primary align=64» создает новый раздел со смещением первого кластера на 64Кб, что позволяет выровнять границы кластеров и блоков и тем самым оптимизировать работу дисковой подсистемы.

3) В Disk Management создать диск (отформатировать)

4) Скопировать файлы обратно (если есть такая необходимость)

xcopy E:\DiskD\*.* D:\ /E /K /O /X

Примечание. Описание xcopy.

Флаги трассировки MS SQL server 2008, влияющие на производительность

661: Disable the ghost record removal process

Флаг трассировки 661 отключает системный процесс удаления фантомных записей. Фантомные записи появляются в результате исполнения операций удаления, после которых удалённые записи могут оставаться в файле как фантомные записи. Через некоторое время, удаленные записи вычищаются процессом удаления фантомных записей. Когда этот процесс отключается, удаленные записи не вычищаются. Поэтому, место, которое занимают удаленные записи, не высвобождается. Это влияет на занимаемое данными место и на производительность операций просмотра.
Флаг трассировки 661 всегда действует в контексте всего сервера, т.е. имеет глобальный контекст. Вы можете включать флаг трассировки 661 при запуске сервера или в пользовательском сеансе.

834: Use Microsoft Windows large-page allocations for the buffer pool

Флаг трассировки 834 применяется в SQL Server 2008 для включения механизма распределения буферному пулу больших страницы памяти, которыми умеют оперировать последние версии Microsoft Windows. У разных аппаратных платформ может быть разный размер страниц, он может изменяться от 2 до 16 Мбайт. Большие страницы распределяются при запуске и сохраняются на протяжении всей жизни процесса. Флаг трассировки 834 повышает производительность, увеличивая эффективность TLB буфера процессоров.
Флаг трассировки 834 применим только к 64-битным версиям SQL Server 2008. Включить флаг трассировки 834 может только та учётная запись, для которой разрешена локальная политика «Lock pages in memory». Включать флаг трассировки 834 можно только при запуске SQL Server.
Флаг трассировки 834 может препятствовать запуску сервера, если память сильно фрагментирована и это мешает распределению больших страниц. Поэтому, флаг трассировки 834 безопаснее использовать на серверах, которые обслуживают только SQL Server 2008.
Для получения более подробной информации о поддержке больших страниц Windows, перейдите на следующую страницу сайта Microsoft Developer Network (MSDN): Large-Page Support.

3502: Log Database Checkpoint Start and End times in the SQL Server ErrorLog

Флаг трассировки 3502 не влияет на производительность, но он нужен для контроля выполнения эталонных тестов TPC. Этот флаг трассировки заставляет SQL Server регистрировать в SQL Server ErrorLog время начала и окончания работы системного процесса контрольной точки.

8744: Disable pre-fetching for ranges

Флаг трассировки 8744 отключает предварительную выборку для таких операторов, как «Nested Loops». Неуместное использование этого флага может спровоцировать дополнительные физические чтения, при реализации плана с оператором «Nested Loops«.
Когда флаг трассировки 8744 включён при запуске сервер, он получает глобальный контекст. Когда он включен в сеансе пользователя, контекст ограничивается сеансом.

смотрите также http://www.gilev.ru/escalation/

Виртуализация сервера приложений 1С с аппаратным ключом

13f561e539d0

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

Многие знают, что для работы сервера приложений 1С необходим аппаратный HASP-ключ, выпускаемый в формате LPT-переходника или USB-донгла. В отношении виртуализации у компании 1С мнение весьма специфичное – раньше представители компании заявляли о невозможности работы сервера в виртуальной среде, а теперь предлагают приобрести программный ключ защиты вместе с новым комплектом ПО за 40000р.

Данный подход не кажется сильно лояльным, однако при более детальном рассмотрении проблемы, удалось найти более экономичное и удобное решение.

В рамках статьи, в качестве платформы виртуализации, мы будем рассматривать гипервизор Microsoft Hyper-V Server 2008 R2. Выбор, в основном, обусловлен функциональными возможностями, которые представляет гипервизор в своем «бесплатном» исполнении. В частности – поддержка кластеризации с «живой миграцией» виртуальных машин между узлами.

К сожалению, в Hyper-V не реализовано полноценного механизма подключения USB-устройств к виртуальным машинам. Это создает некоторый дискомфорт, в случае необходимости подключения к виртуальному серверу дополнительных внешних устройств, в том числе аппаратных ключей. В процессе виртуализации (P2V) физического сервера, вообще отрезаются все упоминания о шине USB и устройствах, подключенных к ней.

У основных конкурентов — VMWare и Citrix, существуют рабочие механизмы для перенаправления устройств на шине PCI с bare-metal гипервизоров на виртуальные машины. С помощью этого же механизма, можно перенаправлять на виртуальную машину и USB-устройства.

Сам факт проброса USB-устройств непосредственно из гипервизора сводит к нолю преимущества, получаемые от использования кластера Hyper-V с его функционалом «живой миграции». При перемещении виртуальной машины с одного гипервизора на другой, необходимо будет каждый раз перетыкать ключ и заново настраивать переадресацию. Становится понятно, что нам необходимо более гибкое решение.

В данном случае, нам на помощь придет отличная программа USB-Redirector, осуществляющая проброс любого USB-устройства по локальной сети с одного сервера на другой. Стоимость самой скромной Windows-редакции данной утилиты — 65 евро, а для осуществления задуманного больше и не надо. Существует большое количество, как аппаратных, так и программных реализаций данной технологии от самых разнообразных разработчиков. Однако в рамках статьи мы рассмотрим именно программу от Incentives Pro, как наиболее экономичное решение рассматриваемой задачи.

Программа работает как клиент-серверное решение, где сервер предоставляет доступ к одному или нескольким USB-девайсам, а клиент подключает их как собственные локальные устройства. В качестве клиентского приложения можно использовать бесплатный USB Redirector Lite или полнофункциональный USB Redirector. В качестве USB-сервера можно использовать любой компьютер, под управлением ОС Windows или Linux. Стоит отметить, что версии для Linux полностью бесплатны и обеспечивают полную кроссплатформенную совместимость с платными Windows-решениями.

После установки серверной части, мы должны выбрать в консоли программы те устройства, к которым необходимо предоставить доступ по сети. Для проброса устройства по сети, серверу USB Redirector не требуется даже драйвера для устройства, он понадобится только на сервере 1С с клиентским приложением.

usb-server_PNG

При использовании технологии Live Migration в кластере Hyper-V, виртуальная машина перемещается между узлами кластера, не прерывая сетевых соединений. Так как промежуток времени, когда виртуальная машина не доступна по сети, пренебрежимо мал, пользователи не испытывают дискомфорта в работе с сервером приложений 1С.

usb-client_PNG

devman-usb_PNG

Для корректной работы вышеописанной схемы, необходимо разрешить на обоих серверах доступ по порту 32032 для USB Redirector Service. Сама программа не создает правила для встроенного брандмауэра, так что их придется настраивать вручную.

На видео представлена процедура настройки клиентского и серверного приложений.

После удачного дистанционного подключения нашего HASP-ключа, в диспетчере устройств появятся виртуальные USB-девайсы, драйвера на которые уже должны стоять на сервере. В случае использования LPT-ключа, можно воспользоваться переходником LPT-to-USB, китайские реализации которого можно с легкостью найти в розницу.

Андрей Ивашенцев