Проблема с большими объемами >50000 строк в таблице значений

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

Пример: есть код

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

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

Причина: замедление вызвано наличием индексов по указанным колонкам таблицы значений. Т.е., подобный код:

Важно: влияние замедления зависит от размера таблицы значений (чем больше строк тем сильнее замедление).

Проблема проверялась на версиях платформы 8.3.14.1779, 8.3.18.1520

Решение: универсального решения нет. Может помочь следующее:

  1. Замена на метод “ЗаполнитьЗначениеСвойств” (метод работает быстрее даже если присваивает сразу несколько значений в индексированных колонках, см демонстрацию в тестовой обработке). Например, на платформе 8.3.18 если в таблице значений 50 тыс строк, то присвоение значения в проиндексированной колонке  50 тыс раз занимает 13.8 сек, если же использовать метод ЗаполнитьЗначенияСвойств — менее 1 сек. Однако важно использовать метод с пустым 3 параметром (см замер из тестовой обработки ниже), в случае если 3 параметром явно указать имя колонки — то эффекта не будет;
  2. Использования соответствия вместо таблицы значений;
  3. Добавление индекса после наполнения таблицы (если позволяет алгоритм)

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

событие технологического журнала VRSREQUEST

Запрос к серверу за некоторым ресурсом

VRSREQUEST и VRSRESPONSE  события как бы оборачивают CALL / SCALL:

  • сначала фиксируются события VRSREQUEST / VRSRESPONSE, отражающие по факту начало и завершение события и не имеют длительности;
  • и только потом CALL / SCALL, показывающие длительность самого события.

На слайде можно увидеть, что VRSREQUEST – это какой-то запрос с process=<apache>. В событии выводятся все HTTP заголовки– по ним видно, что откуда пришло.

Также выводятся два интересных свойства – Pragma: sync=<6> и vrs-session: некоторый идентификатор – по сути, идентификатор нашего сеанса. Мы привыкли видеть сеансы в консоли кластера как 1-2-3-4-5, т.е. целые числа, но они также имеют идентификаторы.

Предположим ситуацию – у нас есть веб-сервер, рабочий процесс, менеджер сервера входящие в какой-то кластер 1С.

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

  • В первую очередь в ТЖ веб-сервера фиксируется событие VRSREQUEST, у которого есть идентификатор vrs-session.
  • В ТЖ менеджера сервера rmng по этому идентификатору мы можем найти событие SESN, у которого Func=start, тот же самый идентификатор и свойство Nmb=1. Nmb – это номер сеанса. Таким образом можно сопоставить ТЖ между веб-сервером и менеджером сервера rmngr – найти время, когда этот сеанс реально был создан, прочитать его номер сеанса в привычном нам виде и найти его в консоли. Это довольно муторно, но при подробном ТЖ это можно сделать.
  • Веб-сервер обращается к рабочему процессу rphost. В ТЖ рабочего процесса также фиксируется событие VRSREQUEST, которое показывает, что к rphost обратились со стороны. Обратите внимание, что если сравнить его с VRSREQUEST на веб-сервере:
    • у них совпадает vrs-session – это, по сути, тот же идентификатор сеанса vrs-session, который был на веб-сервере;
    • кроме того, совпадает свойство Pragma: sync=6 – счетчик серверных вызовов. Если бы мы попытались склеить между собой VRSREQUEST на веб-сервере и в рабочем процессе по vrs-session – мы бы нашли их, но мы бы не знали, кто друг к другу относится. Только если расставить их по времени, но запросов бывает очень много и это довольно сложно сделать. Поэтому склеивание удобнее производить по свойству sync.

При поступлении http-запроса на веб-сервер не только фиксируется событие VRSREQUEST, но и происходит исходящий вызов на рабочий процесс сервера 1С – это событие SCALL. Но пока мы его не видим, потому что события CALL / SCALL выводятся после их завершения, а события VRSREQUEST и VRSRESPONSE выводятся сразу (они не имеют длительности).

Одинаковое значения свойства t:clientID одинаковое у всех записей ТЖ процесса rphost, относящихся к этому вызову: одинаковый у VRSREQUEST, VRSRESPONSE и CALL позволяет их видеть как одно событие в процессе.

событие технологического журнала SYSTEM

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

событие технологического журнала SESN

Действия, относящиеся к сеансу работы. Например: начало сеанса, окончание сеанса и т. д.

Когда клиент подключается к кластеру.

Первое – клиент первоначально устанавливает соединение с rmng.

Второе – rmng создает сеанс. Сеанс – это некая абстрактная сущность, которая представляет пользователя в системе.

Третье – rmng выделяет под сеанс определенные место в сеансовых данных.

Четвертое – rmng назначает сеанс на какой-то рабочий процесс rphost

Пятое – клиент устанавливает с этим rphost TCP соединение.

При установке сеанса выводится событие SESN – это действия, относящиеся к сеансу работы – начало, завершение сеанса.

Номер сеанса в событии SESN указывается в свойстве «Nmb».

Свойство «Func» содержит действие выполненное сеансом:

  • Start – создание сеанса.
  • Attach – сеансу назначено соединение. Причем в момент фиксации события SESN с Func=Attach оно уже имеет длительность, равную времени использования сеансом соединения. Такое событие выводится уже после того, как сеанс освободил соединение. Если сеанс не удалось создать, SESN не будет, оно выводится уже после завершения всех процедур.
  • Finish – это завершение сеанса. Его длительность показывает, сколько сеанс вообще просуществовал.

Анализируя событие SESN с Func=Attach можно смотреть, насколько долго было назначено соединение сеансу. При этом важно понимать, почему сеансу назначается соединение. Как я уже говорил, сам сеанс ничего не делает. Для выполнения какой нибудь работы (выполнение кода 1С, обращения к базе данных) сеансу нужно назначить соединение из пула соединений — через эти соединения сеанс в общем-то и работает.

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

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

событие технологического журнала SDBL

События, связанные с исполнением запросов к модели базы данных системы 1С:Предприятие

SDBL – это промежуточный язык запросов (по сути, язык запросов 1С), данные которого потом переводятся в синтаксис той СУБД, которую мы используем.

Событие SDBL – это исполнение запросов к модели базы данных платформы 1С. Оно возникает, когда код начинает работать с запросами к СУБД. Например может использоваться СУБД Postgres, что будет видно из свойства DBMS события SDBL.

Событие SDBL возникает сначала, когда мы еще не обратились к базе данных. Давайте обратим внимание на его интересные свойства.

  • У него есть свойство Trans=1, которое означает, что событие связано с открытой транзакцией. Это должно всегда настораживать – любые события SDBL со свойством Trans=1 и с большой длительностью свидетельствуют о том, что у нас есть длительные транзакции.
  • Свойство Func=BeginTransaction. В этом свойстве указывается вид выполняемого действия. В нашем примере — начало транзакции.
  • Свойство Context, в котором выводится контекст выполнения кода, откуда это событие было вызвано.

событие технологического журнала SCALL

Исходящий удаленный вызов (исходящий вызов на стороне источника вызова)

По свойствам событие SCALL почти аналогично событию CALL.

Значениям свойства MName:

  • getSeanceServers – «Дай мне сервер сеансовых данных».
  • getSeanceParameterSer – «Дай мне параметры моих сеансов».
  • attachSeanceIB – «Приаттачь мой сеанс к соединению».

 

событие технологического журнала PROC

Cобытие PROC связано с началом, завершением или аварийным завершением процесса платформы 1С.

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

У события PROC есть свойство Txt, в котором указана причина события – старт процесса, получения сигнала о завершении процесса или непосредственное завершение процесса. Здесь мы можем видеть, что процесс был завершен или стартован, указывается признак debug, если включена отладка.

В свойстве Txt события PROC также выводится интересная дополнительная информация.

Например, при проблемах стабильности работы – когда у нас высокая нагрузка и рабочие процессы перестают отвечать друг другу (перестают реагировать на работу подсистемы отслеживания разрывов соединений), у нас могут зафиксироваться вот такие плохие сообщения события PROC:

Bad cluster lock;

Cluster lock absent.

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

Но причина потери TCP-соединений не всегда в сети – не нужно бежать к админам и кричать на них: «Почему у вас сеть не работает», хотя это проще всего сделать. Это бывает и при большой нагрузке – процесс настолько загружен, что он не успевает ответить. Параметры подсистемы отслеживания разрывов соединений регулируются с помощью параметров командной строки запуска процесса ragent. По умолчанию значения там довольно маленькие, и в большой нагруженной системе вы можете столкнуться с тем, что у вас процессы будут часто падать из-за потери блокировки кластера.

Событие не выводится, если процесс завершен принудительно (диспетчером задач или через kill).

 

 

событие технологического журнала EXCP

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

 

событие технологического журнала CONN

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

Такие события фиксируются в технологическом журнале. Даже если никто не работает в системе, там постоянно будут идти события – PROC и CONN.

Событие CONN – это установка или разрыв клиентского соединения с сервером.
Тут под клиентом имеется в виду не пользователь, а клиент со стороны инициатора соединения. В принципе, при любой установке TCP-соединения – что тонкого клиента с рабочим процессом, что рабочего процесса с rmngr – будет фиксироваться событие CONN.

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

Обычно первое событие CONN, в свойстве Txt которого указано Accepted. Событие говорит о том, что рабочий процесс (process=rphost), акцептовал некое TCP-соединение.

Также могут быть события с Txt=Connected и которых видно, что процесс успешно установил TCP-соединение.

Если на событиях CONN много количественно Accepted и Connected, то это свидетельствует о проблемах связанных с установкой/разрывами соединений.

В финале, когда соединение TCP закрывается, тоже выводится событие CONN и оно уже имеет длительность, показывая длительность удержания TCP-соединения между процессами.

Также интересный вариант использования событий CONN – это отслеживать моменты, когда пользователи, заходят в систему под своей доменной учетной записью, но работают в 1С под другим именем пользователя. Когда клиент (тонкий или толстый) подключается к рабочему процессу, будет зафиксировано событие CONN – установка соединения. В этом событии будет передано не имя пользователя, а имя его доменной учетной записи. Это позволит точно узнать пользователя, который мог выполнять в системе странные операции под другим пользователем.

В событиях CONN выводится информация подсистемы отслеживания разрывов соединений в кластере. Для таких событий CONN в свойстве Txt будет указано ‘Ping direction statistics’. С помощью этих событий можно собирать полезную информацию, чтобы понять, есть ли у нас проблемы с сетью между компонентами кластера. Подобные CONN выводятся в лог раз в 10 секунд и несут в себе накопленную статистику.

В свойствах таких событий есть следующее:

address – ip адрес для которого выполняется сбор статистики.

pingTimeout и pingPeriod — таймаут и период опроса в мс. По умолчанию, в платформе стоит возможность сетевого таймаута на 5 секунд. Например, если рабочий процесс не ответит агенту сервера за 5 секунд, то будет считаться, что он потерялся.

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

Свойство packetsLost показывает потери пакетов (потеряно четыре пакета – packetsLost=4). Эту информацию довольно сложно интерпретировать, потому что статистика отслеживается в рамках скользящего 10-секундного окна. Пакеты могут оцениваться как потерянные в текущем окне статистики, но в следующем 10-секундном окне на них могут быть получены ответы.

Свойство packetsLostAndFound показывает количество пакетов, которые были отправлены в одном окне, а пришли в другом. Оно несколько помогает интерпретировать свойство packetsLost.

avgResponseTime и maxResponseTime – эти свойства показывают сетевые задержки.

событие технологического журнала CALL

Входящий удаленный вызов (удаленный вызов на стороне приемника вызова)

Компоненты платформы постоянно общаются между собой, а факт такого общения регистрируется в ТЖ через события CALL и SCALL.

Здесь важно отметить и выделить первый принцип – это парность событий.

Смотрите, здесь на каждой картинке указано два события – SCALL и CALL.

  • SCALL – это исходящий вызов. Когда какой-то компонент (в нашем случае, рабочий процесс rphost) у кого-то что-то запрашивает (в данном случае у rmng) – он делает исходящий вызов, обращается к нему.
  • На стороне приемника в конце обработки этого запроса фиксируется событие CALL. Здесь мы видим, что rphost обратился к rmngr.

Но как же сопоставить эти события? Они действительно парные.

  • В первую очередь, все SCALL и CALL можно склеить между собой через свойство CallID. У событий CALL и SCALL для разных файлов технологических журналов, у разных процессов они будут совпадать.
  • Также в событиях SCALL и CALL можно увидеть очень важное свойство – это t:ClientID или просто ClientID. Возможно, разработчики платформы когда-то запутались и в некоторых событиях осталось t:ClientID, а в других ClientID. До конца не понятно, что значит t – это tcp или thread? Я предпочитаю думать, что это идентификатор потока выполнения, потому что, по сути, это значение также характеризует номер нашего потока выполнения в этом рабочем процессе.
  • Кроме этого, в событии SCALL в новых версиях платформы появилось вспомогательное свойство DstClientID (destination ClientID).

событие технологического журнала FTEXTSKIP

FTEXTSKIP

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

событие технологического журнала WINCERT

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

Скорость работы оперативной памяти

Частота оперативной памяти зависит от ее размещения на материнской оплате относительно процессоров, которые её используют.

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

Для Xeon Scalable 2 поколения — число каналов памяти равно 6, а частота поддерживаемой памяти 2933 MHz.

Из документации мы видим что даже если придерживаться числа 6, но поставить планок в два раза больше на процессор, т.е. 12, то частота всё равно немного упадет с 2933 до 2666 MHz.

Аналогичная ситуация Xeon Scalable 3 поколения — число каналов памяти равно 6, а вот частота поддерживаемой памяти уже выше 3200 MHz.

Из документации мы также видим что если поставить планок в два раза больше на процессор, т.е. 12, то частота упадет с 3200 до 2933 MHz.

Аналогичная разница и на предыдущих поколениях процессоров.

А для устаревших поколений Xeon v3 и v4 соответственно, если в канале процессора, поддерживающего шину 2400 МГц установлен 1 DIMM, он работает на полной частоте. Добавляем модуль в тот же канал – они работают на частоте 2133 МГц. Добавляем третий – канал настраивается на частоту 1866 МГц.

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

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

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

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

Долгая отрисовка форм в 1С — скрытые поля

Существует неявная особенность платформы — даже для неотображаемых полей может происходит их получение и подготовка к отображению.
В платформе 8.3.15.1830 наблюдается следующее поведение в примере:

  •  Регистр сведений «РеестрДокументов», в котором есть измерение «Ссылка» составного
    типа;
  •  Динамический список «Закупки все» получающий данные из регистра
    «РеестрДокументов»
    Пользователь хочет получить реквизит документа путем разыменования поля «Ссылка».
    Например, реквизит «Отклонено», для этого он изменяет настройку формы списка – добавляет
    поле в список:

После выполненной настройки открытие формы списка существенно замедляется (в нашем случае: без такой настройки 2-3 секунды, с настройкой 23-28 секунд)

Проблема: даже если добавленное поле будет отключено (как показано на рис ниже), форма будет продолжать открываться медленно. (21-26 секунд). 

Решение: 

  1. Необходимо удалить поле из настройки формы совсем (а не просто снять галочку видимости);
  2. Эффективно подобные данные из полей составного типа можно получить:
  • Путем изменения структуры регистра «Реестр документов» — добавления требуемых полей и организации их заполнения при изменении документов;
  • В некоторых случаях — возможно получить данные за счет изменения текста запроса динамического списка с использованием конструкции «Выразить КАК»
  • Данные могут быть вычислены в событии табличного поля «ПриПолученииДанных»

 

 

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

Что делать если платформа падает

rphost_8.3.18.102_7c938235_20131025162441_3348.mdmp

Его имя построено по шаблону: ИмяПроцесса_Релиз_АдресОшибки_ГГГГММДДЧЧММСС_PIDПроцесса.mdmp

В котором ГГГГММДДЧЧММСС – это дата и время падения.

Каждая ошибка, из-за которой происходит падение, имеет свой уникальный АдресОшибки.

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

Вы можете обратиться в техническую поддержку фирмы «1С» v8@1c.ru . Конечно это не самый быстрый способ.

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

Версию и разрядность серверной ОС
Разрядность сервера 1С
Количество серверов в кластере
Количество запущенных рабочих процессов на сервере 1С
Версию используемой СУБД
Ссылки на архив с дампом и логами для скачивания.

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

Общесистемные и групповые замедления 1С

Кроме замедлений операций, где поведение связано с конкретной операцией, или особенностями вводимы параметров у этой операции существуют ситуации когда страдают значительной группой пользователей или вообще все пользователи информационной системы.
Общесистемное замедление — когда любые операции испытываются трудности со скоростью выполнения.
Групповые замедления — когда коллективно замедления испытывает группа пользователей на любых операциях.

Причины.

Укрупненно влиять массово могут следующие факторы:

1. Объективное замедление всей системы.
1.1 Сброс частоты процессора
1.2 Пропуск тактов процессора (например из-за перегрева)
1.3 Влияние виртуализации (умышленное или по ошибке). Пример влияния одной виртуалки на другую показан на видео с 7 минуты.
2. Нехватка мощностей сервера
2.1 Существенная или полная утилизация доступных ресурсов (процессор, диски, сеть и т.п.)
2.1.1 Кратковременная/пиковая
2.1.1.1 Загружен может быть не сервер целиком, а ядра, используемые конкретным серверным процессом 1С, например при выполнении фонового процесса по обновлению полнотекстового индекса или диск при достройке индексов для журнала регистрации в последних версиях платформы
2.1.1.2 Замедление при проседании скорости диска может быть связанно с особенностями кэша диска (например серия Samasung EVO использует технологию TurboWrite. Когда «кэш» TruboWrite забивается под завязку, то скорость записи резко падает.) или превышения ресурса перезаписи
2.1.2 Длительная
3. Логические ожидания
3.1 Ожидания внешних процессов
3.1.1 Ожидания опроса ключей 1С (как по архитектуре ключ проброшен с откликом больше 0 мс, так и по причине ошибок в коде). Пример тут.
3.1.2 Плохо написанный вызов из кода 1С синхронно внешнего процесса
3.1.3 Ошибки платформы
3.1.3.1 подвисания при переключении сеансов со старого рабочего процесса на новый
3.1.3.2 замедления как минимум в версии ПРОФ при освоении ~80% доступной оперативной памяти
3.1.3.3 известны проблемы в 8.3.18 с асинхронными вызовами
3.1.3.4 известны случаи некорректной работы при динамических обновлениях
3.1.3.5 известны случаи некорректной работы при долго выполняющемся фоновом задании updateconfigurationlicense
3.2 Квотирование ресурсов (например dfss)
3.3 Внешний перехват сетевого трафика драйвером антивируса или проверка процесса антивирусом
3.4 для бесплатной версии ms sql server (в старых версии был регулятор на 5 активных соединений) или специального настроеннго в платной регулятора ресурсов.

Динамическое обновление 1С

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

1. Например можно словить:
Ошибка СУБД:
ERROR:  relation «_reference5029» does not exist

2. Если изменилась (или удалилась) функция — будет фатальная ошибка или отсутствие контроля целостности данных.

3. Еще одна неприятная ситуация возникает при некорректной работе с кэшем метаданных.
Кэш метаданных расположен в папке \<Имя пользователя OS>\Local Settings\Application Data\1C\1Cv81\
В нем необходимо стереть подпапки Config, ConfigSave, DBNameCache, SICache.
В результате легко получить ошибку «Ошибка потока формата».

Примечание.
UUID информационной базы можно посмотреть в файле
C:\Documents and Settings\<Имя пользователя>\Application Data\1C\1Cv81\ibases.v8i.

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

Возможные проблемы:
1. Основная проблема в работе с КЭШ.
1.1. У пользователя может не обновиться кэш на клиенте.
1.2. Кэш на сервере может не обновиться.
1.3. Кэш у разработчика может не обновиться (если работают несколько разработчиков)
2. Сталкивались с такой ситуацией когда делаешь штук 5 демонических обновлений а потом обычное. При обычном все демонические пропадают. Т.е. все что нажито непосильным трудом…
3. Сама ошибка заключатся в том, что в момент записи в таблицу «Config» что-то произошло, что помешало корректно закончить данную процедуру.

Часто программисты не учитывают, что есть список объектов, НЕ доступных для динамического обновления
Регламентные задания
Общие реквизиты
Планы обмена
Реквизиты, предопределенные элементы, иерархия, владельцы, нумерация справочников
Реквизиты, нумерация, движения, последовательности, ввод на основании документов
Перечисления
Тип значений характеристик, реквизиты, нумерация, предопределенные элементы планов видов характеристик
Реквизиты, нумерация, субконто,  предопределенные элементы планов счетов
Реквизиты, нумерация, расчет,  предопределенные элементы планов видов расчета
Реквизиты, регистраторы регистров сведений, накопления, бухгалтерии, расчета
Реквизиты, нумерация, расчет,  предопределенные элементы планов видов расчета
Реквизиты, адресация, нумерация задач
Реквизиты, нумерация,  ввод на основании бизнес-процессов

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

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

Если вы работаете с часто изменяемой печатной формой и не хотите постоянно выгонять пользователей, используйте внешние обработки.
Хорошей практикой считается все плановые изменения вносить например раз в неделю, например во вторник. К этому дню все правки тестируются не только по отдельности, но и в общем взаимодействии. Если во вторник информационная система ухудшила свою работу, значит сразу понятно, что надо откатить последний релиз к предыдущему. А это означает бэкап не только базы, но и бэкап cf перед внесением изменений.

Если Вы словили проблему связанную с динамическим обновлением, то обязательно очистите сеансовые данные с рестартом службы сервера 1С.
Если проблема не ушла, то запускайте сеанс 1С с ключом /ClearCache .

 

 

 

Народное творчество. Порочность динамического обновления воспета народом в интернете:
«Здравствуйте, меня зовут Алексей и я делаю динамическое обновление.
Раньше, я делал динамическое обновление по три или даже целых пять раз в день.
Я мог не спросить пользователей, не сделать бекап средствами СУБД и динамически обновить базу ради изменения макета печатной формы счета на оплату.
Но потом случилось горе и в одно прекрасное обновление база просто не запустилась.
Это был ч0рный день в моей жизни.
Я потерял друзей, коллеги отвернулись от меня.
Жена меня бросила и дети не хотят со мной разговаривать.
Попа болела после долгого и многозначительного разговора с начальством.
И я решил изменить свою жизнь.
Я теперь занимаюсь спортом
Стал посещать бассейн.
Питаюсь правильно и соблюдаю правила дорожного движения.
Сегодня у меня праздник.
Я  уже 30 дней не делаю динамического обновления без архивации базы данных средствами СУБД.
Я практически готов полностью отказаться от динамического обновления.
Вообще не обновлять динамически.

Преодолеть зависимость от динамического обновления мне помогли 12 простых шагов:

12 ШАГОВ , РАЗРАБОТАННЫЕ САМИМИ ДИНАМИЧЕСКИМИ ОБНОВЛЯЛЬЩИКАМИ
1. Признать свое бессилие перед поведением платформы 1с при динамическом обновлении.
2. Согласиться с утверждением, что без посторонней помощи не обойтись.
3. Мысленно перепоручить себя некой Высшей силе, которая поможет.
4. Проанализировать свои поступки.
5. Признать перед собой и кем-то еще свои ошибки.
6. Не сомневаться, что бекап перед динамическим обновлением сработает.
7. Просить высшие силы избавить от недостатков.
8. Составить список всех людей, кому причинили зло, и захотеть загладить свою вину перед ними.
9. Лично возместить этим людям ущерб, нанесенный вами и вашим динамическим обновлением.
10. Продолжать самоанализ и, при малейших ошибках, сразу признавать, что вы их таки совершили.
11. Не переставать размышлять и благодарить помощника из пункта 3.
12. Достигнув пробуждения, благодаря пунктам 1-11, помогать другим динамическообновлялщикам.

Механизм работы обновления:
Процесс динамического обновления (и обновления вообще) происходит следующим образом:

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

В случае если обновление происходит динамически и клиент подключен к клиент-серверной ИБ, тогда конфигуратор уведомляет сервер о том, что поколение метаданных, с которым сейчас работает сервер, устарело. Сервер запоминает этот факт и при подсоединении следующего нового клиента «поднимает» для него самое актуальное поколение метаданных. Уже подключенные клиенты живут в старом поколении до тех пор, пока они подключены к серверу. Так как конфигуратору, для продолжения работы после обновления ИБ, требуется самое новое поколение, а он подключен к старому, то конфигуратор перезапускается, чтобы подключится к новому поколению метаданных на сервере.

Время простоя

или по забугорному RTO (recovery time objective)

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

Не надо путать время восстановления и объем потерянных данных.

На время восстановления влияет:
1. время восстановления аппаратной составляющей
Время простоя обычно снижают аппаратным резервированием (дублированием).
2. доставка к месту восстановления бэкапов
Время простоя снижают доставкой заранее бэкапа или реплику транзакции.
Также значимую роль занимает скорость сети.
3. время накатывания бэкапов
Диски с бэкапами часто бывают медленными. Для уменьшения времени считывания бэкапов используют быстрые SSD.

На время восстановления могут повлиять и другие факторы.

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

Объем потерянных данных

или по забугорному — RPO (recovery point objective)

это максимальный период времени, за который могут быть потеряны данные в результате инцидента. Например, у нас имеется информационная система и RPO для нее мы определили в 1 час. Это значит, что, если вдруг происходит авария, мы готовы к тому, что систему удастся восстановить, но в ней будут потеряны данные не более, чем за последний час. Количество потерянных данных может быть меньше, если нам повезет, но не более 1 часа. Этот показатель говорит нам о том, как часто мы должны делать резервные копии нашей системы, и какие технологии применять, чтобы удержать этот показатель. Может ли он быть ноль? Теоретически да, но на практике организовать это очень сложно. Это можно организовать, только, если запись идет как минимум в 2 разных хранилища. Использование AlwaysOn Availability Groups или Database Mirroring вам не поможет, т.к. эти технологии не спасут от случайного удаления таблицы.

Наиболее популярный вариант MS SQL Server — log-shipping (доставка журналов) скажем с частотой раз в минуту (при условии что сам процесс бэкапа лога успевает быстрее и не идет накопления очереди) позволяет обеспечить RPO в одну минуту например.

см. также http://www.gilev.ru/31march/
см. также http://www.gilev.ru/rto/

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% от своего размера.

Апгрейд сервера — как узнать что пора

Признаки того, что пора апгрейдить сервера (достаточно одного из пунктов):

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

2. Новые сервера в 2 и более раз быстрее текущих.
2.1. На вашем сервере тест Гилева выдает менее 30 баллов. А если менее 8, то бегом бежать за новым сервером.
2.2. На вашем сервере тест CrystalDiskMark 3.0.4 выдает по Seq write меньше 1000 mb/s или 4K QD32 write  меньше 300 mb/s ( описание теста  )

3. Сервер не справляется с текущей нагрузкой

4. Проведен аудит и выдана рекомендация по апгрейду.

5. (эмпирическое) Сервер на три года старше новой машины директора.

Подбором нового оборудования можно воспользоваться здесь http://www.gilev.ru/podbor/

Особенности 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.

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

До 8.3.19 При работе с лицензиями уровня ПРОФ, для перезапуска рабочих процессов кластера и для прерывания объемных вызовов сервера использовалось значение, равное 80% от оперативной памяти компьютера, на котором работает сервер.

Подключение 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-массивы

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

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

 

Почему для 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С

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

Влияние ресурса перезаписи на выбор SSD

Выбор SSD для клиент-серверного варианта 1С для коллективной работы отличается от покупки SSD для своего ноутбука.

 

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

Быстрее всего на класс устройства можно сориентироваться по показателям DWPD (или “полных перезаписей устройства в день в течение гарантийного срока”) и/или TBW/PBW (или “общий объём данных, который за время гарантийного срока можно записать на устройство»), измеряется в терабайтах для TBW и петабайтах для PBW. Чем выше/больше “полных перезаписей устройства в день” DWPD — тем обычно выше класс устройства.

 

Разные производители по-разному трактуют классы промышленных SSD, но в целом можно привести такой пример разделения:

  • DWPD 0.1 и меньше — класс “boot”, то есть носитель для операционной системы, и больше на него ничего записывать не надо;
    Условно можно считать что это диски для одного пользователя 1С.

  • ssd 0.3-1 — класс read intensive или RI, он же “оптимизированный для операций чтения”. Носители например для складывания архивов или архивных баз, разных “файлопомоек”, куда интенсивность записи невысокая;
    В отдельных случаях это могут быть диски для файловых баз 1С на несколько человек.

  • DWPD 3-5 — класс mixed use или MU, устройства предназначены для “средних уровней интенсивности записи”, какие-нибудь второстепенные базы со средним уровнем активности;
    Самый популярный диапазон. Учтите, что независимо от реальных задач, в “полках” чаще всего бывают именно эти диски. Такие диски хороши для нескольких десятков пользователей 1С.

  • DWPD 10 и более — класс write intensive или WI, устройства предназначены для высокого уровня интенсивности записи, объём записи будет такой, что за сутки может быть перезаписан много раз без существенной потери производительности. Именно этот класс рекомендуется использовать “в общем” для серверов с высокой активностью записи, но гораздо лучше это делать не вслепую, а предварительно оценив фактические объёмы записи на нужном сервере.
    Продавцы “железа” не любят продавать эти диски. Более того, они отговаривают клиентов их покупать. Однако если речь идёт о накопителях для сервера, обслуживающего многие сотни пользователей 1С — соответствующие нагрузке модели дисков находятся как правило именно в этом классе устройств.

Косвенно класс устройства можно понять, сопоставляя паспортные IOPS на чтение и запись. Чем ниже показатель записи по отношению к чтению — тем вероятно ниже и класс устройства. Например, у крайне производительных intel Optane с DWPD 30-60 соотношение примерно 550K/550K, у “средних” P4610 с DWPD 3 соотношение 638K/222K, а у совсем “слабых” P4101 с DWPD на уровне 0.1-0.3 — соотношение 275K/16K у старшей модели в линейке и 60K/2.2K у младшей. 

 

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

 

К сожалению, на сайте intel не по всем моделям можно быстро увидеть паспортную ресурсоёмкость устройства, которая выражается в параметрах , поэтому приходится использовать сторонние источники. В качестве примера ресурса, где можно быстро сравнить ресурсоемкость по DWPD/TBW: https://en.wikipedia.org/wiki/List_of_Intel_SSDs

 

Оценка текущей интенсивности записи на диск

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

 

Если Вы используете 1С в наиболее популярном варианте в связке с MS SQL Server, то основная нагрузка на диск будет через него и с помощью запросов к статистике сервера можно получить оценку интенсивности записи .

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

 

Как смотреть накопленную статистику MS SQL Server

Данные с СУБД можно получать сразу в сгруппированном по дискам виде, и сразу с пересчётом в гигабайты, например таким запросом: 

SELECT SUBSTRING(saf.physical_name, 1, 1) AS [Диск]

, SUM(vfs.num_of_bytes_read/1024/1024/1024) AS [Прочитано (Гб)]

, SUM(vfs.num_of_bytes_written/1024/1024/1024) AS [Записано (Гб)]

FROM sys.master_files AS saf

JOIN sys.dm_io_virtual_file_stats(NULL,NULL) AS vfs

ON vfs.database_id = saf.database_id

AND vfs.file_id = saf.file_id

GROUP BY SUBSTRING(saf.physical_name, 1, 1)

ORDER BY [Диск]

 

например, получится вот такой результат:

При этом, поскольку это данные с момента старта службы — будет полезно сразу оценить и время, за которое эти данные накоплены, например таким запросом:

ВАЖНО. Если с момента рестарта пройдет меньше суток, то надо как минимум подождать пока набегут сутки и повторно посчитать.

ВАЖНО. Интенсивность записи в разные дни может быть сильно разная. Достаточно репрезентативным показательным интервалом времени аптайма сервера для оценки можно считать квартал. Либо генерируете в исследуемом небольшом период пик нагрузки.

ВАЖНО. Любая запись на диски, сделанная НЕ средствами СУБД, например полных бэкапов внешними средствами (например Акронис Бэкап) в замер субд не попадет.

 

Как видно на снимке, служба сервера запущена 14 дней 19 часов (или 355 часов) назад, и статистика накоплена именно за это время.

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

Например, в примере на диск P за это время записано 5142 гигабайта, то есть за неполных 15 дней выходит в среднем примерно по 350 гигабайт в сутки. Как получена эта величина: 5142 записанных гигабайта делим на 355 часов сбора статистики и умножаем на 24 часа в сутках.

Таким образом в текущем примере интенсивность записи — 350 гигабайт в сутки.


Теперь чтобы подобрать SSD, надо посмотреть на подходящий размер и соответствующих “полных перезаписей устройства в день” DWPD.

Если Вы берете диск с 0,1 DWPD intel P4101 емкостью 512 Gb, то 512 * 0,1 = 51,2 Гб/сутки < реальной нагрузки 350 гигабайт в сутки. На практике Вы получите непредсказуемую неудовлетворительную работу диска.
Кроме того, в реальной жизни не только SQL Server генерирует нагрузку, так что надо еще делать поправочный коэф.-т на другую активность.

Требуемый нам диск должен перезаписывать более 400 Гигабайт. Понятно, что кроме этого надо смотреть на требуемый реальный размер диска. Вдруг у нас база размером в терабайт. Рассмотрим на примере диска intel p4610 размером 1,6 Тб 

https://ark.intel.com/content/www/ru/ru/ark/products/140103/intel-ssd-dc-p4610-series-1-6tb-2-5in-pcie-3-1-x4-3d2-tlc.html

Рейтинг износоустойчивости (операции записи за все время эксплуатации): 12.25PBW — это означает гарантированную возможность записать 12.25 петабайта за гарантийный срок, который составляет: Гарантийный период: 5 yrs, то есть 5 лет. 

Пересчитываем условно рейтинг износоустойчивости в расчёте “на 1 день”: 12.25 петабайт = 12250 терабайт, делим на (5 лет Х на 365 дней), получаем 6.7 терабайта в день, теперь делим эту величину на объём диска и получаем примерно 4 объёма полной перезаписи в день (то есть DWPD).

 

Сравниваем 6.7 Тб и 350 Гб реальной нагрузки (лучше с некоторым поправочным коэф.-том) — получаем приемлемый запас по ресурсу перезаписи, который гарантированно справится с текущей нагрузкой.

При этом надо понимать, что статистика представляет собой “среднее по больнице”, в периоды высокой активности пользователей запись может быть в несколько раз больше, или во время ночных регламентов на СУБД, а в другие периоды бывает поспокойней. 

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

 

Бонус: если используется платный сервис http://gilev.ru/sqlsize 

Если на сервере СУБД используется платный сервис http://gilev.ru/sqlsize, то можно сразу воспользоваться уже собранными там данными.

Поскольку данные статистики использования дисков накапливаются с момента старта службы — будет полезно сразу оценить время, за которое эти данные накоплены, в сервисе SQLSize это пункт “Параметры СУБД — Параметры SQL сервер”, пункты “Аптайм (часов)” и “Аптайм (дней)”, например мы там увидим 297 часов или 13 дней.

Далее смотрим статистику использования дисковой подсистемы в пункте “Нагрузка на сервер СУБД — Диски — Интенсивность использования”.

Надпись справа от названия отчёта информирует о том, когда именно была получена эта информация. На данном снимке нас интересует колонка “Записано, МБ”. Если просуммировать все показанные на снимке значения из этой колонки — получается примерно 4540 гигабайт записи на диск C.

 

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

В данном примере получается в среднем примерно по 350 гигабайт в сутки. При этом надо понимать, что статистика представляет собой “среднее по больнице”, ведь наверняка в периоды высокой активности пользователей запись существенно больше, или во время ночных регламентов на СУБД, а в другие периоды бывает поспокойней. Наиболее представительной данная информация будет например, если скриптом получать в некую табличку результат запросов по объёму записи каждый час в течение скажем нескольких дней высокой загрузки, а затем определить интенсивность запись именно в пиковые периоды, когда это могло мешать производительности бизнеса. Например, ночью нагрузка на диски будет большая, но в это время никто в базе не работает, и диски к началу рабочего дня уже могли успеть “прийти в себя”. Но может оказаться и так, что в течение нескольких часов нагрузка на диски по записи существенно превышает паспортную, и производительность записи заметно ухудшается (о чём нам как бы намекает из вышеприведённого снимка колонка “Отклик на запись”, где среднее сглаженное время отклика одной операции записи на разных файлах плавает от 13 до 27 миллисекунд, что было когда-то приемлемо для механических дисков, но это много для SSD, особенно с учётом того, что это той же “среднее по больнице” за 13 дней).

 

Дальше будет полезно выяснить, какая же модель накопителей используется в данном сервере, после этого сравнить «расчётные по DWPD» объёмы записи с фактическими.

Выяснено, что диск обслуживается рассмотренным выше по тексту накопителем intel P4101, вот линк на его спецификацию: https://ark.intel.com/content/www/ru/ru/ark/products/148630/intel-ssd-dc-p4101-series-1-024tb-m-2-80mm-pcie-3-0-x4-3d2-tlc.html 

Заметим, что производитель решил умолчать в данной спецификации о таких важных параметрах, как DWPD (гарантийный показатель количества перезаписей в день) и гарантийный ресурс устройства на запись. Практически единственным намёком на класс устройства в данной спецификации может служить соотношение IOPS на чтение и запись, а именно 275К против 16К.

Однако заметим, что если поискать данное устройство на сайте intel https://www.intel.ru/content/www/ru/ru/products/memory-storage/solid-state-drives/data-center-ssds.html — мы его найдём в разделе “Твердотельные накопители Intel® серии D1: 

Оптимальная надежность и производительность бюджетного уровня для рабочих нагрузок с большим количеством операций чтения“. На странице описания собственно модели P4101 https://www.intel.ru/content/www/ru/ru/products/memory-storage/solid-state-drives/data-center-ssds/d1-series/dc-p4101-series.html написано: “Этот твердотельный накопитель с 64-слойной технологией Intel® TLC PCIe* NAND в форм-факторе M.2 разработан для моделей использования в качестве загрузочного диска и рабочих нагрузок с небольшим количеством операций чтения, таких как индексирование поисковых запросов и кэширование на периферии.”. Это такой намёк от intel, что не надо подобный диск использовать под активно записываемые базы данных 🙂

 

Дальнейшие поиски в интернете показывают различные варианты DWPD для данного устройства, но в целом они колеблются между 0.1 и 0.3, что для накопителя с ёмкостью 1 терабайт означает расчётный объём допустимой записи не более 100-300 гигабайт в сутки, причём расчёт исходит из идеально ровного распределения данного объёма внутри времени суток, то есть за каждый час не более 1/24 данного объёма. Очевидно, если в наблюдаемом примере каждые сутки на диск пишется более 350 гигабайт — это даже в оптимистичном варианте находится выше уровня предельно допустимой нагрузки. А если исходить из того, что в пиках активности запись на диск производится гораздо интенсивнее — станет понятно, что данная модель откровенно не подходит для имеющейся нагрузки, нужно устройство с существенно более высоким показателем DWPD на имеющийся объём (например, из имеющихся в продаже устройств могут подойти: intel P4610 с паспортным DWPD 3, то есть при объёме 1.6 терабайта — возможность записать в сутки до 4.8 терабайт, или Samsung PM1735 с таким же паспортным DWPD3).

О ПРОДАВЦАХ

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

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

 

 

ipmi

Осмотр настроек BIOS, удаленное включение выполняется посредством IPMI. Названия технологии IPMI у разных вендоров разные:
— для Cisco — это Cisco IMC (Integrated Management Controller)
— для DELL- это iDRAC (Integrated Dell Remote Access Card)
— для HP — это iLO (Integrated Lights-Out)
— для IBM и Lenovo — это IMM (Integrated Management Module)
— для Supermicro — это SIM (Supermicro Intelligent Management)

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.18

В веб-клиенте реализована поддержка технологии PWA (Progressive Web Apps)

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

  • Модификатор процедур и функций Асинх. Он указывает на то, что функция асинхронная;
  • Оператор Ждать. Он приостанавливает исполнение кода функции, которая его содержит, до тех пор, пока не будет закончено исполнение асинхронной функции, указанной в качестве его аргумента;
  • Тип Обещание. Функция, отмеченная как Асинх, всегда возвращает объект типа Обещание. Обещание — это обертка для еще неизвестного результата выполнения асинхронной функции. Этот объект наполняется полученным значением после того, как функция будет выполнена;

Для всех прежних асинхронных методов реализованы новые методы-аналоги. Их можно отличить по суффиксу Асинх в названии метода.

Реализована возможность определения MAC-адреса.

При работе в операционной системе Linux реализованы следующие возможности:

  • одновременная установка на один компьютер нескольких версий 1С:Предприятия;
  • автоматический выбор нужной версии клиентского приложения для соединения с сервером;
  • обновление установленной версии клиентского приложения с сервера 1С:Предприятия или с интернет-сервиса получения дистрибутива.

Реализована поддержка СУБД PostgreSQL 12;

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

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

Источник: https://dl03.1c.ru/content/Platform/8_3_18_891/1cv8upd_8_3_18_891.htm

вспомогательные файлы 1С

  • def.usr — хранится в каталоге <Данные приложений пользователя>/1C/1Cv8/<Идентификатор информационной базы> (например, C:/Documents and Settings/User/Application Data/1C/1cv82/4129dbdb-b495-41cb-99ea-ef315060a03e/def.usr) и содержит имя пользователя который последним открывал данную информационную базу.
  • ibases.v8i — хранится в каталоге <Данные приложений пользователя>/1C/1CEStart (например, C:\Documents and Settings\user\Application Data\1C\1CEStart\ibases.v8i) и содержит список информационных баз, зарегистрированных на данном клиентском компьютере. Этот список отображается в диалоге «Запуск 1С:Предприятия».
  • GenTempl_ru.st, GenTempl_en.st  — стандартный файл шаблонов текста расположен в каталоге загрузочных модулей 1С:Предприятия (например C:/Program Files/1cv82/bin) на русском и английском языке соответсвенно.
  • appsrvrs.lst — хранится в каталоге <Данные приложений пользователя>/1C/1cv82 (например, C:/Documents and Settings/User/Local Settings/Application Data/1C/1cv82/appsrvrs.lst) и содержит список серверов 1С:Предприятия, зарегистрированных в утилите администрирования информационных баз в варианте клиент-сервер.
  • srvribrg.lst —  хранится на центральном сервере кластера в каталоге <рабочий каталог центрального сервера> (например, C:/Program Files/1cv82/server/srvribrg.lst) и содержит список кластеров, зарегистрированных на данном компьютере сервера 1С:Предприятия. Содержащиеся в нем данные необходимы для нормальной работы приложений, использующих данный сервер 1С:Предприятия.
  • 1CV8Reg.lst — файл настройки кластера( например C:\Program Files\1cv82\srvinfo\reg_1541\1CV8Reg.lst)
  • В каталогах DBNameCacheConfigSaveConfigSICache хранится множество файлов, кеширующих различные компоненты конфигурации. Эта информация является производной от конфигурации информационной базы, хранимой в базе данных, и служит для ускорения запуска клиентских приложений и повышения их производительности. Кеш конфигурации располагается в каталоге данных приложений текущего пользователя, например, C:/Documents and Settings/User/Local Settings/Application Data/1C/1cv82/7b0a6294-d6a3-41c5-a23e-dc9e5301ad22/DBNameCache.
  • В каталоге 1Cv8FTxt хранятся данные, используемые службой полнотекстового поиска. Они располагаются на компьютере центрального сервера 1С:Предприятия в каталоге <рабочий каталог кластера>/<идентификатор информационной базы>. Например: C:/Program Files/1cv82/server/reg_1541/7eac7609-c0cb-4701-83cf-9ff5f8961de8/1Cv8FTxt.
  • Группа файлов CACHE/ddb<n>.snp хранится в каталоге хранилища конфигурации и служит для кэширования запрошенных версий конфигурации из этого хранилища. Наличие этих файлов не является обязательным и позволяет ускорить получение версий конфигурации.
  • *.1ccr — конфигурационный файл Web-сервиса для работы с удаленным хранилищем может иметь произвольное имя (расширение 1ccr обязательно), формат XML и содержит единственный узел с произвольным именем и атрибутом connectString — в этом атрибуте указывается адрес сервера хранилища в схеме tcp.
  • *.mft — файл с расширение mft является файлом-манифестом — специальным файлом, описывающим шаблон конфигурации. Файл может иметь произвольное имя. Файл располагается в каталоге установленного шаблона конфигурации.
  • *.v8i — в данном файле приводится описание формата файла описаний зарегистрированных информационных баз. Данный список используют все клиенты. Файл располагается на локальном компьютере в каталоге %APPDATA%\1C\1CEStart\ и по умолчанию имеет имя ibases.v8i.
  • 1CESCmn.cfg — файл 1CESCmn.cfg содержит общие настройки программ запуска (1CEStart.exe и 1Cv8s.exe).
  • 1CEStart.cfg — файл 1CEStart.cfg содержит настройки, которые используют программы запуска (1CEStart.exe и 1Cv8s.exe) и клиентские приложения (1Cv8.exe и 1Cv8c.exe). Файл расположен в каталоге %APPDATA%\1C\1CEStart.
  • adminstall.cfg — файл adminstall.cfg указывает на то, что установка системы программ «1С:Предприятие» выполнялась с использованием средств администрирования операционной системы. Файл располагается в каталоге конфигурационных файлов системы «1С:Предприятие» и представляет собой текстовый документ в кодировке UTF-8.
  • comcntrcfg.xml — файл comcntrcfg.xml служит для указания внешнему соединению необходимости запуска в отладочном режиме.
  • Файл располагается в каталоге конфигурационных файлов системы «1С:Предприятие», и его наличие не является обязательным.
  • conf.cfg — файл conf.cfg определяет расположение каталога общих конфигурационных файлов. Файл расположен в каталоге bin\conf каталога конкретной версии «1С:Предприятия» и представляет собой текстовый документ в кодировке UTF-8.
  • debugcfg.xml — файл debugcfg.xml предназначен для настройки дополнительного диапазона портов, используемого при отладке конфигураций. Файл располагается в каталоге конфигурационных файлов системы «1С:Предприятие», и его наличие не является обязательным.
  • def.usr — файл хранится в каталоге %APPDATA%\1C\1Cv82\<Уникальный идентификатор информационной базы> и содержит имя пользователя который последним открывал данную информационную базу.
  • default.vrd — данный файл служит для настройки веб-клиента и использования Web-сервисов, и находится в каталоге виртуального приложения.
  • inetcfg.xml — файл inetcfg.xml позволяет задавать настройки прокси по умолчанию и имеет больший приоритет над настройками прокси по умолчанию в Windows. Файл располагается в каталоге конфигурационных файлов системы «1С:Предприятие», и его наличие не является обязательным.
  • logcfg.xml — файл logcfg.xml служит для настройки технологического журнала. Файл располагается в каталоге конфигурационных файлов системы «1С:Предприятие», и его наличие не является обязательным.
  • logui.txt — располагается в каталоге %APPDATA%\1C\1Cv82\<Уникальный идентификатор информационной базы> и содержит список интерактивных действий пользователя, которые выполнялись за время журналирования.
  • nethasp.ini — для настройки параметров взаимодействия системы «1С:Предприятие» с HASP License Manager используется конфигурационный файл nethasp.ini. Файл располагается в каталоге конфигурационных файлов системы «1С:Предприятие», и его наличие не является обязательным.
  • nhsrv.ini — некоторые настройки HASP License Manager могут задаваться при помощи файла конфигурации nhsrv.ini. При запуске HASP License Manager осуществляет поиск конфигурационного файла nhsrv.ini в различных каталогах в следующей последовательности:
    • каталог, в котором размещается исполняемый файл HASP License Manager;
    • текущий каталог Windows;
    • системный каталог Microsoft Windows (%SystemRoot%\system32 — для 32-разрядной версии и %SystemRoot%\system — для 64-разрядной версии);
    • каталог Microsoft Windows;
    • каталоги, перечисленные в переменной окружения PATH (только в случае установки HASP License Manager как приложения Microsoft Windows).

Рекомендуется размещать файл nhsrv.ini, если это необходимо, в каталоге, в котором размещается исполняемый файл HASP License Manager. Проверка того, что HASP License Manager нашел и прочитал файл конфигурации, можно с помощью журнала Activity Log/Server Activity Log.

  • srv1cv82 — конфигурационный файл /etc/sysconfig/srv1cv82 используется для задания параметров запуска агента сервера «1С:Предприятие» с помощью скрипта /etc/init.d/srv1cv82. Данный конфигурационный файл используется в случае запуска сервера «1С:Предприятия» в операционной системе Linux.
  • swpuser.ini — для того чтобы рабочий процесс запускался не от имени того же пользователя, что и агент сервера, в каталоге данных приложений, относящемся к пользователю агента сервера, может быть размещен файл swpuser.ini
  • *.lic — лицензии базовых конфигураций (C:\Documents and Settings\All Users\Application Data\1C\licenses)

Особенности 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

 

Ошибка сетевого доступа к серверу. (Windows Sockets — 10106(0x0000277A)

 Почему возникает такая проблема

В некоторых случаях при работе с удаленным хранилищем по протоколу http можно столкнуться со случаем недостаточных прав. Но проявляется это нетривиальными сообщениями вроде этого.

Если нажать кнопку «Подробно», то можно получить такую рашифровку:

… Ошибка сетевого доступа к серверу. (Windows Sockets — 10106(0x0000277A)…
На сайте Microsoft есть такая трактовка этой ошибки:

Не удалось инициализировать Service provider.
Запрошенный service provider не может быть загружен или инициализирован. Эта ошибка выдается, если соответствующий service provider’s DLL не загрузился (LoadLibrary failed) или the provider’s WSPStartup или NSPStartup функция failed.

При этом хранилище доступно по протоколу tcp.

Как устраняется проблема

1. Для решения проблемы надо воспользоваться утилитами Sysinternals REGMON и FILEMON.

2. Проверить права на реестр с помощью REGMON и при необходимости исправить:

Отследить сервис w3wp.exe (IIS) в момент попытки соединится с хранилищем

Отсеживаем ключи

HKLM\SYSTEM\Services\Winsock\Parameters
HKLM\SYSTEM\Services\TCPIP\Parameters
HKLM\SYSTEM\Services\NetBIOS\Parameters
HKLM\SYSTEM\Services\Gpc\Parameters

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

3. Проверить права доступа к файлам с помощью FILEMON и исправить при необходимости:

В конкретном разбираемом случаи, после обращения к файлу «repository.1ccr» сервис w3wp.exe от имени IUSR_SRVNAME пытается обратиться к DLL «DRWEBSP.DLL» — «Dr.Web Winsock Provider Hook» (Это от DrWeb — a)  ACCESS DENIED .

Внимание! Это не стандартная ситуация. Чаще всего это либо не проявится вообще, либо может быть другое приложение.

Даем права на чтение и выполнение IUSR_SRVNAME.

При следующей попытке соединиться к хранилищем получаем обращение к DLL «wshtcpip.dll» — «Windows Sockets Helper DLL»  ACCESS DENIED.

Внимание! Это тоже не стандартная ситуация. Чаще всего это либо не проявится вообще, либо может быть другое приложение.

Даем права на чтение и выполнение IUSR_SRVNAME.

filemon

 

В данном конкретном примере это оказалось решением.

В некоторых случаях причина заключается в использовании настроек прокси Internet Explorera, для которого в свою очередь есть «ограничения доступа к сайтам». В этом случаи отказ от прокси или снятие ограничения по доступу также решают проблему

Как восстановить базы данных без лога *.ldf

1. Создаем новую базу с таким же именем и такими же по именам и расположению .mdf и .ldf файлами

2. Останавливаем сервер, подменяем файл .mdf

3. Стартуем сервер, не обращаем внимания на статус базы

4. Из «Query Analyzer» выполняем скрипт:

SQL
Use master
go
sp_configure ‘allow updates’, 1
reconfigure with override
go

4. Там же выполняем:

SQL
select status from sysdatabases where name = ‘<db_name>’

и запоминаем/записываем значение на случай неудачи ребилда лога.

5. Там же выполняем:

SQL
update sysdatabases set status= 32768 where name = ‘<db_name>’

6. Перезапускаем SQL Server.

7. В принципе база должна быть видна (в emergency mode). Можно, например, заскриптовать все объекты.

8. Из «Query Analyzer» выполняем:

SQL
DBCC REBUILD_LOG(‘<db_name>’, ‘<имя нового лога с указанием полного пути>’)

SQL Server скажет — Warning: The log for database ‘<db_name>’ has been rebuilt.

9. Если все нормально, то там же выполняем:

SQL
Use master
go
sp_dboption ‘<db_name>’, ‘single_user’, ‘true’
go
USE <db_name>
GO
DBCC CHECKDB(‘<db_name>’, REPAIR_ALLOW_DATA_LOSS)
go

9a.
Если Вам не удалось перевести базу в single user mode, то для проверки целостности данных можно попробовать dbo only mode
sp_dboption », ‘dbo use only’, ‘true’

10. Если все в порядке, то:

SQL
sp_dboption ‘<db_name>’, ‘single_user’, ‘false’
go
Use master
go
sp_configure ‘allow updates’, 0
go

 

Инструкция по установке разных версий серверов 1С на один сервер

Постановка задачи

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

Текущий сервер 1С имеет следующие параметры:
Версия сервера 1С: 8.3.16.1224
Порт центрального сервера 1С:Предприятия: 1540
Порт главного менеджера кластера: 1541

Планируемые параметры нового сервера 1С:
Версия сервера 1С: 8.3.12.1924
Порт центрального сервера 1С:Предприятия: 2540
Порт главного менеджера кластера: 2541

Порядок выполнения работ

1. Создать нового пользователя

Создадим пользователя USR1CV8_8_3_12, от имени которого будет работать новая служба 1С.

Заполним поля в выведенном окне Новый пользователь.

Нажмем кнопку Создать и потом кнопку Закрыть.

1.1. Зададим локальные групповые политики для пользователя USR1CV8_8_3_12.

Выполним следующие действия:

1. В главном меню Windows выбираем пункт Выполнить (либо по комбинации клавиш Win+R).

2. Вводим в строку Открыть имя “secpol.msc” . И нажимаем кнопку ОК. Будет запущен редактор локальной политики безопасности.

3. В редакторе локальной политики безопасности в левой части окна выбираем ветку Параметры безопасности | Локальные политики | Назначение прав пользователя.

4. Добавляем пользователя USR1CV8_8_3_12 во все политики, в которых имеется пользователь USR1CV8, а именно:

— Вход в качестве пакетного задания

— Вход в качестве службы

— Запретить локальный вход

— Отказать в доступе к этому компьютеру из сети

5. Выходим из редактора локальной групповой политики.

1.2. Даем права на создание баз данных

Пользователю USR1CV8_8_3_12 необходимо дать право на создание баз данных в сервере СУБД Microsoft SQL Server.
В MS SQL Management Studio, во вкладке Безопасность -> Имена для входа нажимаем “Создать имя для входа…”:

Создаем пользователя USR1CV8_8_3_12 с проверкой подлинности Windows:

Даем необходимые права новому пользователю MSSQL. Для работы 1С достаточно прав роли “dbcreator”:

2. Установить новую версию сервера 1С:Предприятие

Устанавливаем сервер 1С:Предприятия 8.3.12:

Снимаем галочку с пункта “Установить сервер 1С:Предприятия как сервис Windows”:

Иначе новая установка затрет параметры службы текущего сервера 1С (8.3.16).

3. Создаем каталог для новой службы сервера 1С:Предприятие 8.3.12

Для службы сервера 1С:Предприятие 8.3.12 потребуется отдельный каталог:

Добавляем для нового каталога “Полные права” для пользователя USR1CV8_8_3_12:

4. Зарегистрировать новую службу Агент сервера 1C:Предприятие и установить новые порты для кластера

Для регистрации новой службы необходимо воспользоваться утилитой sc.exe, и прописать в службу необходимые параметры. Для этого можно создать *.bat-файл. Пример текст *.bat-файла для описываемой ситуации приведен ниже:

@echo off
chcp 1251
set SrvcName=»1C:Enterprise 8.3.12 Server Agent»
set BinPath=»\»C:\Program Files\1cv8\8.3.12.1924\bin\ragent.exe\» -srvc -agent -regport 2541 -port 2540 -range 2560:2591 -d \»C:\Program Files\1cv8\srvinfo_8_3_12\»»
set Desctiption=»Агент сервера 1С:Предприятия 8.3.12″
sc create %SrvcName% binPath= %BinPath% start= auto displayname= %Desctiption% depend= Tcpip/Dnscache/lanmanworkstation/lanmanserver/
pause

!!! Запуск *.bat-файлов производится только с правами Администратора

После успешного выполнения *.bat-файла должно появиться следующее сообщение:

После чего для закрытия окна нажимаем любую клавишу (например, пробел).

В результате исполнения *.bat-файла служба отобразится в утилите.

5. Донастроить службу вручную

Открыть свойства новой службы и указать учетную запись, от имени которой она будет запускаться, и ее пароль. В нашем случае это запись USR1CV8_8_3_12:

Запустить обе службы: Агент сервера 1C:Предприятие 8.3 и Агент сервера 1C:Предприятие 8.3.12:

6. Проверить работоспособность новой технологической платформы

Запустить консоль Администрирование серверов 1С Предприятие (C:\Program Files\1cv8\common\1CV8 Servers (x86-64).msc). Проверить подключение к обоим кластерам (по портам 1540 и 2540 для старой и новой технологической платформы соответственно).

!!! Если в системе используются сетевые экраны, то необходимо разрешить передачу данных по портам 2540-2541, 2560-2591.
Вместо разрешения портов можно разрешить передачу данных процессам кластера (ragent, rmngr, rphost).

Для платформы 8.3.16.1224:

Для платформы 8.3.12.1924:

Решение возможных проблем

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

При возникновении данной ошибки проверьте, запущены ли службы Агент сервера 1С Предприятие

——————————————————————————————————————

При возникновении данной ошибки необходимо перерегистрировать radmin.dll.

*.cmd-файл для перерегистрации библиотеки платформы версии 8.3.16.1224 расположен по пути:
«C:\Program Files\1cv8\8.3.16.1224\bin\RegMSC.cmd»

*.cmd-файл для перерегистрации библиотеки платформы версии 8.3.12.1924 расположен по пути:
«C:\Program Files\1cv8\8.3.12.1924\bin\RegMSC.cmd»

После выполнения нужного *.cmd-файла в свойствах кластера возможно потребуется изменить порт на нужный (в нашем случае для 8.3.16 указать порт 1540, а для 8.3.12 — порт 2540)

После смены порта центрального сервера нужно нажать кнопку “Обновить”:

 

Подключение сервером 1С к PostgreSQL на нестандартном порту

Для подключения по нестандартному порту PostgreSQL в консоли администрирования серверов 1С:Предприятия в параметрах информационной базы в поле «Сервер баз данных» нужно написать строку в следующем формате:

hostname port=5433

Зачем аппаратному 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.