Архив рубрики: 1с сервер

Динамическое обновление 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, помогать другим динамическообновлялщикам.

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

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

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

Особенности 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 insert, rac server update.

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

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

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

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

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

 

Инструкция по установке разных версий серверов 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

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

Опубликовано автором

В языке запросов реализована поддержка группирующих наборов (grouping set).
В языке запросов реализована поддержка ключевых слов ГРУППИРУЮЩИМ НАБОРАМ для предложения СГРУППИРОВАТЬ ПО

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

История поиска хранится в хранилище системных настроек с ключом Общее/ИсторияПоискаТаблицы/<Имя формы>.<Имя таблицы>.

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

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

Клиентские приложения (кроме веб-клиента), работающие под управлением ОС macOS, Linux и Windows, переведены на использование графической подсистемы, основанной на библиотеке Cairo.

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

источник https://dl03.1c.ru/content/Platform/8_3_16_869/1cv8upd_8_3_16_869.htm

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

Опубликовано автором

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

Реализована стандартная функция Управление серверами. Данная функция работает аналогично консоли управления кластером. Для своей работы она требует сервер администрирования кластера серверов для всех серверов, которыми требуется управлять. Работа с серверами выполняется с помощью объекта АдминистрированиеСервера.
Интерактивное управление кластером серверов стало возможно не только при работе под управлением ОС семейства Windows. Средства управления кластером доступны в клиентском приложении с помощью диалога Все функции.

Оптимизировано использование оперативной памяти при работе под управлением ОС Linux.

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

Если текст запроса содержит условие, в котором принимают участие два константных выражения, и каждое из этих выражений не является строкой, то данное условие будет заменено на результат выражения перед тем, как запрос будет передан на исполнение СУБД.
В режиме совместимости с версией 8.3.14 поведение не изменилось.
В ряде случаев повышена производительность исполнения запросов.

Ускорена работа с виртуальными таблицами регистра бухгалтерии, обновление итогов при записи движений по регистру и пересчет итогов регистра бухгалтерии.
При этом увеличивается объем хранимых данных и незначительно увеличивается время сохранения набора записей.
Для того, чтобы ускорение работы с регистром бухгалтерии стало заметно, необходимо отключить режим совместимости. При этом будет выполнена реструктуризация регистров бухгалтерии. В том случае, если размер информационной базы превышает 10 Гбайт, рекомендуется для реструктуризации использовать оптимизированный механизм обновления конфигурации базы данных.
В режиме совместимости с версией 8.3.14 поведение не изменилось.

При работе с использованием СУБД PostgreSQL, оптимизировано выполнение проведения больших документов по регистру бухгалтерии, а также использование виртуальной таблицы ДвиженияССубконто.
В клиентском приложении (тонкий, толстый и веб-клиент) реализована возможность снимать объектную блокировку, установленную другим пользователем или этим же пользователем, но в другом сеансе. Под «объектной блокировкой» понимается блокировка, установленная интерактивно, при редактировании объекта в форме или методами Заблокировать(), ЗаблокироватьДанныеДляРедактирования(), ЗаблокироватьДанныеФормыДляРедактирования().

Переработан механизм балансировки нагрузки при создании нового соединения с кластером серверов. Изменен алгоритм оценки производительности рабочего процесса.

Совмещение терминального сервера с “1С”

Опубликовано автором

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

1. “За совмещение”.
Основная НАСТОЯЩАЯ причина совмещения ролей — это экономия денег. А если быть точным — КАЖУЩАЯСЯ экономия на старте эксплуатации.
Конечно многие сторонники приводят другие аргументы. Но они как правило в итоге всё равно “конвертируются” в дешевизну. Кстати, что будет дальше после начала эксплуатации в этот момент сторонники совмещения плохо просчитывают — позиция проста — “прорвемся как-нибудь”.

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

Есть такая вещь как запас мощности оборудования в пиковые моменты. К сожалению многим администраторам не очевидно, что когда он смотрит в диспетчер задач он видит моментальный снимок (несколько минут) текущий загруженности и не видит «пиков». И не увидит.
У разных ролей сервера максимальная амплитуда между «пиком» и средним значением может сильно отличаться. В среднем по больнице, роль терминального сервера характеризуется наибольшей разницей между нагрузкой в пике и средней нагруженностью. Можно дать условное объяснение, но оно условное: руками вбивая данные (один документ раз в пять минут) очень тяжело на стороне клиентской части 1С вообще что либо нагрузить, так как манипуляции с данными, обсчет и т.п. выполняется на другом сервере (сервере 1С и субд). Т.е. пользователи делая что то руками, а это большая часть рабочего дня не сильно то и грузят терминальный сервер. Зато когда возникает некоторая локальная задача не на весь день — скопировать фильм, скачать дистрибутив, выполнить загрузку данных на клиент, да хоть тореннтом порно скачать — все это неплохо кушает ресурсы, пусть и не длительное время, но часто несколько ядер процессора грузятся целиком. А еще есть антивирус, который не должен стоять на сервере 1С (куда нет локального доступа у пользователей) , но зато антивирус обязательно должен стоять на терминальном сервере. Еще на терминальном сервере хорошим тоном последние годы должен стоять антишифровальщик. Такие «штуки» хоть и не постоянно, но иногда что то начинают проверять — новый файл, атаку портов и т.п. Вообщем, называйте это как хотите, но периодически на терминалки бывают ситуации, особенно когда железка загруженна сверхсильно. Это ведь пулл терминалок — это лишь опытные админы делают, балансируя соединения и нагрузку. Я уж молчу про dfss, квотирование ресурсов, виртуализацию и т.п. обрезающие любому потоку максимальную скорость.

1. “За разнесение”. Получается что не только надо говорить о регулировании нагрузки между ролями. Регулировать нагрузку надо между терминальными пользователями. А при количестве превышающим разумное для одного сервервера надо строить несколько терминальных серверов, раскидывая пользователей между ними.
Не совсем теория, но тоже интересный факт. Наша практика показала (а мы делаем порядка 100 аудитов в год), что пики загруженности терминальных серверов при совмещение с сервером 1С — это очень популярный вариант и оказалось что терминальные сервера не мониторятся вообще или делается это условно, но главное сильно влияют на работу других ролей сервера (сервера 1С в данном случае). Причем это не теоретическое рассуждение — выносили нагрузку на отдельный сервер и клиент подтверждал положительный результат.
2. “За разнесение”. Еще один фактор — это лицензирование. На одно и тоже количество пользователей (понятно что мы говорим не про трех человек) с учетом большой разницы в стоимости между стандартом и энтерпрайзом выгоднее собирать в пул несколько недорогих серверов, чем одну мощную “железку”. Наример, если вы лицензируете MS SQL Server, то Вам надо лицензировать ВСЕ ядра сервера, а не те, которые вы аффинити маской назначите использовать. Получается, что Вы переплатите за пользователей, который будут съедать процессоры терминальными сессиями.

3. “За разнесение”. Настоящий аргумент это безопасность. Причем это многогранная вещь. Терминальные сервера стоит активно мониторить антивирусом. Это наиболее вероятно место атаки для троянов, шифровальщиков, брутфорсов и т.п. А вот на сервер с ролью сервера 1С и субд локально лучше вообще не заходить. Консоли правления лучше запускать с другого сервера. Активно проверять антивирусом сервера 1С, их соединения — бррр. Вы скорее всего пожалеете об этом. И уж тем более “грех” на сервере 1С или субд устраивать “файловую помойку”. Впрочем в России безопасностью пока не клюнет — не занимаются, поэтому идем дальше.

4. “За разнесение”. Обычно в момент покупки сервера задача “кто будет разбираться с проблемами конкуренции за ресурсы” серьезно не воспринимается. Но на практике еще можно понять тех, кто роль сервера 1С и субд сажает на “физику”, а рядом ставит виртуалку и в неё помещает “терминальный сервер”, так хотя бы терминальные пользователи имеют меньше приоритет в борьбе за ресурсы, и их легче заквотировать. Но почему не очевидно, что чтобы квотировать надо понимать НА ОСНОВАНИИ КАКИХ МЕТРИК КАКИЕ ПРАВИЛА ПРИМЕНЯТЬ. А кто серьезно мониторит нагрузку терминальных пользователей. А тек кто могут настроить ,например “заббикс”, все равно не могут интерпретировать правильно собранные значения. Другими словами, лень — это нормальная черта админа, но надо правильно оценивать свои силы. Заизолировать нагрузку физически гораздо реалистичней, чем думать, что в процессе эксплуатации у вас вдруг откроется второе дыхание и вы найдете потайные галочки которые вернут нагрузку в норму.
Взять аналогию с кораблями. У них есть “переборки”, для того чтобы в случая пробоя ниже ватерлинии попавшая внутрь вода не распространилась по всему объему корабля и не привела к затоплению. Наивно думать, что когда этот пробой произойдет, то вы займетесь созданием этих самых перегородок. Да ни черта у Вас не будет времени/денег/знаний/желания на это занятие.

А если Вы — маленькая компания, то рядом с клиент-серверным вариантом частенько бывает файловая версия например 1С:Бухгалтерии. И эту базу надо размещать не на сервере субд, а на терминальном сервере на локальных дисках, а не по сети. Иначе вы ухудшите работу файлового варианта.

Хотите поступить правильно — лучше выбейте денег на отдельную терминалку.
Ну а если хотите глубже погрузиться в эту тему, приходите на наш тренинг http://www.gilev.ru/training/ .
Не согласны с материалом — напишите slava@gilev.ru ваши аргументы. Согласны, но у вас свои доводы, напишите их нам slava@gilev.ru. Обе позиции включим в обзорный материал выше.

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

Опубликовано автором

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В технологическом журнале реализованы свойства Dbms, Database, DBCopy для событий обращения к СУБД (DB2, DBMSSQL, DBPOSTGRS, DBORACLE), событий EXCP и SDBL.

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

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

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

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

Опубликовано автором

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

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

 

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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


Особенности работы платформы с сеансовыми данными

Опубликовано автором

За работу с сеансовыми данными отвечает менеджер кластера – rmngr.exe Если в кластере несколько рабочих серверов, то сеансовые данные будут расположены в соответствии с требованиями назначения функциональности.

Если требования не заданы, то сеансовые данные распределятся равномерно по всем рабочим серверам.

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

Для обеспечения скорости работы, платформа всегда пишет новые данные в конец, аналогично transaction log в СУБД. Таким образом, размер сеансовых данных постоянно растет. Во всем объеме сеансовых данных, существуют как актуальные, так и устаревшие данные. Актуальность данных определяется способом их помещения:

  • Если сеансовые данные помещены из формы и в качестве идентификатора передается идентификатор формы (ЭтаФорма.УникальныйИдентификатор), то данные считаются актуальными, пока открыта форма.
  • Если в качестве идентификатора передан УникальныйИдентификатор, не являющийся уникальным идентификатором формы (Новый УникальныйИдентификатор), то значение перестанет быть актуальным после завершения сеанса пользователя.
  • Если ничего не передано, то значение перестанет быть актуальным при любом следующем серверном вызове.

Перед выделением следующего блока на диске, проверяется, прошло ли 5 секунд с момента выделения предыдущего блока. Если 5 секунд прошло, то запускается «сборщик мусора» (key value garbage collector). Сборщик оценивает процент актуальных сеансовых данных в общем объеме. Если актуальные данные занимают менее 25% от общего объема, то все актуальные данные копируются в новые файлы, а затем все старые.

Так как каждый сеанс (клиенты, фоновые задания, web-сервисы) в своей работе постоянно пишет информацию в сеансовые данные, то при большом количестве пользователей, скорость дисковой подсистемы, на которой расположены файлы сеансовых данных, играет очень важную роль. При большом количестве пользователей, рекомендуется располагать файлы сеансовых данных на максимально быстрых дисках. Желательно RAM-drive. Отказоустойчивость дисков не важна, т.к. при потере сеансовых данных, никакой важной информации утеряно не будет.

Следует отметить порядок размещения сеансовых данных. Если поместить во временное хранилище двоичные данные или файл, то эти данные пройдут в качестве потока байт через rphost, затем в rmngr, который сбросит этот поток на диск. Если же, в качестве помещаемого значения,  будет выступать коллекция (таблица значений, результат запроса, массив…), то сначала вся эта коллекция разместиться в памяти rphost, а только затем преобразуется в поток байт и будет передана в rmngr.

сеансовые данные 1С

Опубликовано автором

Сеансовый кэш (по правильному — «сеансовые данные») как правило находится в расположении C:\Program Files\1cv8\srvinfo\reg_1541\snccntx + уникальный идентификатор. В этой папке (название папки может быть наподобие такого: snccntx23a3c417-bab8-43a5-9df9-8ba437f4523c) лежат файлы вида: snccntx.000057F1.dat . Это и есть сеансовые данные.

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

При вызове методов: ПоместитьВоВременноеХранилище, ПоместитьФайл, НачатьПомещениеФайла, значения указанные в параметрах, записываются в сеансовые данные.

При фоновом исполнении отчетов СКД, результат отчета помещается в сеансовые данные, а затем передается в клиентскую часть.

Сам файл *.dat является местом хранения  noSQL база данных (key-value storage).

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

Примечание. Путь кластера сервера 1С (C:\Program Files\1cv8\srvinfo\) может быть переопредлён ключом -D при запуске службы.

Подкаталог reg_1541 соответствует конкретному кластеру, совпадая в наименовании по номеру порта кластера. Если у вас несколько кластеров, или они расположены по нестандартным портам, то учитывайте это, просматривая соответствующие reg_… каталоги.

Рестарт службы сервера 1С с очисткой временных файлов

Пример скрипта рестарта службы сервера 1С с очисткой временных файлов.

set LOG_FILE="scripts.log"
set SERVICE_1C_NAME="1C:Enterprise 8.3 Server Agent (x86-64)"
set SERVICE_RAS_NAME="1C:Enterprise 8.3 Remote Server"
set CNTX_PATH="C:\srvinfo\reg_1541"
set PFL_PATH="C:\ProgramData\1C\1cv8"
set TEMP_PATH="%TEMP%"
echo %DATE% %TIME% stop service %SERVICE_1C_NAME% >> "%~dp0"%LOG_FILE%
sc stop %SERVICE_1C_NAME%
sc stop %SERVICE_RAS_NAME%
timeout 5
taskkill /f /im "rphost.exe"
taskkill /f /im "rmngr.exe"
taskkill /f /im "ragent.exe"
taskkill /f /im "ras.exe"
timeout 5
echo %DATE% %TIME% done stop service %SERVICE_1C_NAME% >> "%~dp0"%LOG_FILE%
echo %DATE% %TIME% start clean temp >> "%~dp0"%LOG_FILE%
DEL /Q /F /S %CNTX_PATH%\snccntx*
DEL /Q /F %PFL_PATH%\*.pfl
DEL /Q /F /S %TEMP_PATH%\*.*
echo %DATE% %TIME% done clean temp >> "%~dp0"%LOG_FILE%
echo %DATE% %TIME% start service %SERVICE_1C_NAME% >> "%~dp0"%LOG_FILE%
sc start %SERVICE_1C_NAME%
sc start %SERVICE_ RAS _NAME%
echo %DATE% %TIME% service %SERVICE_1C_NAME% restarted >> "%~dp0"%LOG_FILE%

Чтобы правильно определилась переменная %TEMP%, скрипт необходимо запускать от имени пользователя, под которым работает служба сервера 1С.

Ошибка СУБД: Размер (39), выделенный тип «numeric», превышает максимально допустимое значение (38)

Опубликовано автором

Это зарегистрированная ошибка платформы 8.3.12.1412. Возникает когда есть ИТОГИ в запросе .

Временные костыли:

1. пересчет итогов
2. смещение даты актуальности итогов
3.  итоговое поле в запросе через Выразить(МоеПоле Как Число(15,2))

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

Опубликовано автором

Ускорена отрисовка интерфейса клиентского приложения.

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

Прекращено использование библиотеки imaplib.

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

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

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

Для события технологического журнала FTEXTUpd реализованы свойства MinDataId, MemoryUsed, BackgroundJobCreated, JobCanceledByLoadLimit, TotalJobsCount, FailedJobsCount.

Улучшена диагностика кластера: В свойствах сеанса и соединения реализованы значения, показывающие время, которое затрачено на выполнение вызовов сервисов кластера от имени сеанса или соединения. Данные значения реализованы для всех средств администрирования: консоль кластера, COM-соединение, интерфейс администрирования из языка Java, сервер администрирования.
Для объектов IInfoBaseConnectionInfo и ISessionInfo реализованы свойства:

durationCurrentService — текущее время работы сервиса кластера;
CurrentServiceName — имя исполняемого сервиса;
durationLast5MinService — время работы сервисов кластера за последние 5 минут;
durationAllService — время работы сервисов кластера с начала сеанса или соединения.
Аналогичные свойства реализованы в консоли кластера для списка сеансов, списка соединений и диалога свойств соединения.

Для утилиты командной строки (rac) кластера серверов реализованы параметры duration-current-service, current-service-name, duration-last-5min-service и duration-all-service команд connection list и session list.

Linux: Для работы клиентского приложения под управлением ОС Linux требуется установленная библиотека webkitgtk-3.0 версии 1.4.3 и старше.

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

Реализована возможность использования внешних провайдеров для выполнения OpenID-аутентификации.

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

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

Опубликовано автором

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

 

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

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

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

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

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

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

Событие ATTN

Опубликовано автором

Свойство logOnly в событии ATTN технологического журнала 1С означает, что действие, указанное в событии, выполнено не будет.
Например, если кластер распознал проблемный процесс, то в ТЖ будет запись события ATTN о том, что процесс должен быть завершен. Но, если флажок «завершать проблемные процессы» не установлен, то все закончится только записью в ТЖ со свойством logOnly. Если флажок установлен, то будет и запись и завершение проблемного процесса.

Область блокировок 1С REFLOCK.INIT

Опубликовано автором

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

REFLOCK.INIT — пространство блокировки предопределенных данных области.

При первом обращении к разделенной таблице из новой области данных платформа проверяет наличие в ней предопределенных данных и создает предопределенные данные в случае их отсутствия. Проверка и добавление выполняется в транзакции с расстановкой управляемых блокировок для исключения несогласованных действий, например, вставки двух комплектов предопределенных данных. Для исключения длительных транзакционных блокировок данное действие выполняется от имени отдельного временного соединения с информационной базой, в которой гарантированно отсутствует объемлющая транзакция. t:tmpConnectID — это — номер временного соединения.

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

Опубликовано автором

Причиной перезапуска процессов может являться изменение системного времени. Из-за этого процесс rmngr фиксирует исчерпание таймаута ожидания принга от рабочего процесса и считает рабочий процесс пропавшим. Это происходит например если у вас включена синхронизация с NTP сервером, и периодически происходит значительная корректировка времени. Это можно обнаружить в журнале событий Windows по событию от Kernel-General об изменении времени  Event Viewer — группа Windows Log — журнал System — отбор (Filter Current Log) по Event Sources = Kernel General и Event ID = 1 типа такого:
The system time has changed to ‎2017‎-‎01‎-‎30T13:31:54.401000000Z from ‎2017‎-‎01‎-‎30T13:31:49.686072200Z.
Change Reason: An application or system component changed the time.

 

Запускается новый рабочий процесс сервера 1С, а старый завершается. Тайм-аут по умолчанию равен 5 секундам.
Пользователями это воспринимается как массовое подвисание.

Для его изменения можно запустить ragent с параметрами, например, -pingperiod 3000 -pingtimeout 15000.

Недопустимое преобразование типов данных в записи

Опубликовано автором

Ошибка СУБД:
Microsoft SQL Native Client: Conversion failed when converting date and/or time from character string.
HRESULT=80004005, SQLSrvr: SQLSTATE=22007, state=1, Severity=10, native=241, line=1

ошибка может возникать например в момент обновления БД при изменении режима совместимости на «Не использовать»

Вариант решения: Установить native client на все рабочие сервера 1С кластера 1С.

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

Опубликовано автором

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недопустимое имя объекта «#tt

Опубликовано автором

Ошибка вроде как у платформу версии 8.3.9.1818 (Сервер 1С Предприятия x86-64) при работе базы начала вываливаться ошибка у пользователей:

Невосстановимая ошибка
Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:
по причине:
Ошибка СУБД:
Microsoft SQL Server Native Client 10.0: Недопустимое имя объекта «#tt1».
HRESULT=80040E37, SQLSrvr: SQLSTATE=42S02, state=1, Severity=10, native=208, line=1

имеет регистрацию на сайте 1С
Код ошибки: 50010160
Код(ы) обращения: CSR-12050 CSR-12078
Зарегистрирована: 19.10.2016

Замечено что в том числе  8.3.9  «не любит» конструкцию «В (&Массив…)»
например ЗКГУ (ОбщийМодуль.ЗарплатаКадрыРасширенный.Модуль : 5948 : Запрос.Выполнить();)

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

1. Исправлена и проверена на практике в релизе  8.3.9.2170. Не возникает на 8.3.8.2167.

2. Проверьте также наличие сервиспаков MS SQL Server.

3. Выключите Shared Memory

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

Опубликовано автором

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

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

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

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

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

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

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

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

 

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

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

 

Веб-сервисы

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

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

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

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

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

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

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

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

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

 

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

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

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

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

Опубликовано автором

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

 

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

 

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

Реализовано свойство Durationus, которое содержит длительность события, выраженное в микросекундах. Отборы по свойствамDuration поддерживаются для совместимости.

Файловый вариант

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

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

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

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

Настройка спящих сеансов

Опубликовано автором

Спящие сеансы

spyashii-regim

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

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

При нештатном завершении клиентского приложения сеанс удерживается еще 20 минут. После этого в версиях до 8.3.5 сеанс удалялся. С версии 8.3.5 сеанс засыпает в в спящем состоянии по умолчанию удерживается еще сутки. Спящий сеанс не занимает клиентскую лицензию «1С: Предприятие 8».

В версии 8.3.5 время засыпания сеанса и время удаления неиспользуемого спящего сеанса можно изменить с помощью специальной обработки или в Конфигураторе 1С в диалоге Администрирование/ Параметры информационной базы, установив рекомендуемые параметры спящего сеанса:

  • время засыпания пассивных сеансов — 300
  • время завершения спящих сеансов — 10

ib-settings

Кстати, кто спит, а кто активен всегда можно посмотреть через консоль сервера на закладке сеансов. В соответствующей колонке «Спящий» есть признак Да/Нет.

Штатно (по версии фирмы 1С) завершить работу в веб-клиенте можно командой «Файл»-«Выход». С версии 8.3.8 добавили команду завершения работы в заголовок приложения, рядом с кнопкой О программе. Она отображается в виде гиперссылки с именем текущего пользователя.При нажатии на гиперссылку открывается диалог с именем пользователя и командой Завершить работу.

Платформа  каждые 5 секунд делает пинги клиетом сервер 1С (видны пакеты по 4 байта).  На основании «пингов» сервер отслеживает целостность соединения с клиентским приложением. Отсутствие пингов в течение примерно 2 минут серввер интерпретирует как разрыв соединения.

В редакции  8.3.7.2008 исправлена ошибка незавершения спящих сеансов https://bugboard.v8.1c.ru/error/000013447.html

Событие Context журнала сервера 1С

Опубликовано автором

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

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

В остальных случаях контекст события выводится в виде свойства Context.

Событие Context имеет тот же t:clientid, что и предшествующие ему события к которым оно относится.

Приблизительно можно считать, что к событию Context относятся выше лежащие события с таким же t:clientid до ближайшего события Context с этим же t:clientid.

Однако, если событие call регистрируется, то если следом за call следует Context с таким же t:clientid, то к этому Context относятся все события с этим t:clientid, лежащие внутри call.

У события call имеется clientID и длительность.

Внутри события call находятся события с таким же t:clientID, время которых лежит в диапазоне от <время события call> — <длительность события call> до <время события call>.

Событие context будет следующим за событием call с таким же значением свойста t:clientID. Если следующим за собвтием call с данным значеннием t:clientID записано кокое-нибудь другое событие, то это значит, что события context не будет.

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

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

Опубликовано автором

SELECT COUNT(*) FROM DBSchema

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

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

Опубликовано автором

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

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

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

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

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

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

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

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

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

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

Опубликовано автором

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

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

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

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

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

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

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

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

 

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

 

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

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

Особенности работы сеансов по рабочим процессам

Опубликовано автором

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

Как можно существенно сократить «Журнал регистрации» удалив из него сообщения о фоновых заданиях

Опубликовано автором

1. Скачиваем SQLite 3 он состоит из трех файлов: sqldiff.exe sqlite3.exe sqlite3_analyzer.exe
2. Копируем 1cv8.lgd в папку с этими тремя файлами;
3. Запускаем sqlite3.exe
4. Выполняем следующие команды:
(select и from и where )
(не забывайте ставить ; в конце строки !)
.open 1cv8.lgd
select * from AppCodes where name like ‘%Background%’;

code|name
2|»BackgroundJob»

// Запоминаем code=2 (как #A)
select * from ComputerCodes where name like ‘%-1C-%’;
// в условие где «-1С-» подставляем имя сервера 1С (которое указываем при регистрации Базы)

code|name
1|»VIRT-1C-01″

// Запоминаем code=1 (как #C)
select * from EventCodes where name like ‘%Begin%’;

code|name
3|»_$Transaction$_.Begin»

// Запоминаем code=3 (как #1)
select * from EventCodes where name like ‘%Commit%’;

code|name
4|»_$Transaction$_.Commit»

// Запоминаем code=4 (как #2)
select * from EventCodes where name like ‘%Finish%’;

code|name
2|»_$Transaction$_.Finish»

// Запоминаем code=2 (как #3)
.changes on
delete from EventLog where (eventCode=#1 OR eventCode=#2 OR eventCode=#3) AND computerCode=#C AND appCode=#A;

changes: 41593705 total_changes: 41593705

// Внимание! Удаление в 7GB файле длилось 15 мин на компе i7 3.2 8Gb-оперативки
// в папке появляется файл 1cv8_journal и постепенно растет …
vacuum;
// Еще примерно 7-8 мин
.exit

Итог наших манипуляций можно оценить по размеру файла 1cv8.lgd
В самом начале:
dir 1cv8.lgd

11.02.2016 09:37 7 288 039 424 1Cv8.lgd

После манипуляций:

11.02.2016 09:37 180 030 464 1Cv8.lgd

Полезная ссылка: https://www.sqlite.org/cli.html

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

Опубликовано автором

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

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

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

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

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

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

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

 

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

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

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

 

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

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

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

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

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

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

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

 

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

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

Опубликовано автором

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

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

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

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

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

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

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

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

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

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

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

 

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

 

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

 

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

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

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

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

Опубликовано автором

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

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

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

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

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

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

 

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

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

Опубликовано автором

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

Реализована официальная поддержка работы «1С:Предприятия» под управлением ОС Microsoft Windows Server 2012 R2 (x86-64)

Реализован новый «спорный» формат хранения журнала регистрации .Файл ЖР в новом формате (sqlite) после сокращения средствами платформы не уменьшается и все так же занимает много места на диске.
Рекомендуют останавливать сервер 1С периодически и использовать утилиту и команду
sqlite3 1Cv8.lgd «VACUUM;»
Добавлен новый способ управления спящими сеансами

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

Вернуть старый формат записи журнала регистрации

Опубликовано автором

Новый формат журнала регистрации (SQLite, *.lgd ) появился в платформе 1С:Предприятие 8 начиная с версии 8.3.5.

Само по себе обновление на 8.3.5 (или даже более новые релизы) не приводит к смене формата ЖР.

Но вот если на 8.3.5+ создать новую базу (или пересоздать старую) с очисткой папки 1Cv8Log, то при отсутствии в ней файла 1Cv8.lgf будет создан ЖР уже нового формата (*.lgd)

На большом количестве пользователей он может оказаться хуже старого режим работы. Чтобы вернуть старый режим записи — для этого (при остановленном сервере 1С):

Найдите в папке базы (…\srvinfo\reg_<PortNo>\<GUID>) папку журнала регистрации (1Cv8Log),

далее из папки 1Cv8Log удалить все файлы (или переместить, или переименовать папку),

в папке 1Cv8Log создать пустой файл 1Cv8.lgf.

Повторите эти шаги для каждой базы.

Для снижения нагрузки полезно уменьшать детализацию логирования ТЖ (например, оставить только ошибки)
Можно использовать RAM-диск для хранения журнала регистрации

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

ошибка совместного доступа к файлу snccntx.dat

Опубликовано автором

Эта ошибка порождается сервером под Windows, если в момент запуска сервера 1С:Предприятия в памяти уже имеется процесс rmngr, использующий этот же каталог реестра кластера.

Остановите службу Агента 1С:Предприятие 8.

Откройте Task manager.

Принудительно завершите все процессы (ragent, rmngr, rphost) кластера.

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

Опубликовано автором

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

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

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

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

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

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

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

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

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

     

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

     

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

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

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

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

 

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

Опубликовано автором

13f561e539d0

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

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

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

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

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

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

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

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

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

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

usb-server_PNG

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

usb-client_PNG

devman-usb_PNG

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

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

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

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