ipmi

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

FREEPROCCACHE

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

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

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

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

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

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

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

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

 

 

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

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

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

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

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

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

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

BIOS: Processor C-states / All C-states

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

BIOS: Collaborative Power Control

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

 

BIOS: Minimum Processor Idle Power Package State

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

BIOS: Minimum Processor Idle Power Core State

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

 

BIOS: Intel QPI Link Power Management

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

BIOS: Override OS Energy Performance

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

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

BIOS: Software Controlled T-States

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

 

BIOS: Energy Efficient Turbo

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

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

BIOS: ENERGY_PERF_BIAS_CFG

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

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

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

BIOS: Intel SpeedStep (IST)

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

Intel SpeedStep

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

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

BIOS: Turbo Boost

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

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

или Turbo Boost Tehnology.

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

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

BIOS: Package C State

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

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

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

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

BIOS: CPU C6 Report

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

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

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

BIOS: CPU C3 Report

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

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

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

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

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

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

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

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

C1E

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Подробнее:

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

filemon

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

hostname port=5433

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

 

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

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

Удаление postgres

sudo apt-get --purge remove postgresql\*
sudo apt-get purge postgresql
sudo apt-get autoremove postgresql
sudo rm -r /etc/postgresql/
sudo rm -r /etc/postgresql-common/
sudo rm -r /var/lib/postgresql/
sudo userdel -r postgres
sudo groupdel postgres

Команды в linux

a2p — конвертировать awk скрипт в программу на perl;
ac — вывести статистику по времени работы пользователя в системе;
addgroup — добавить новую группу в систему;
adduser — добавить нового пользователя;
agrep — версия утилиты grep, которая может обрабатывать усредненные паттерны;
alias — создание псевдонимов для команды консоли linux;
apropos — поиск по ключевому слову или регулярному выражению в страницах справки man;
apt — поиск, установка и удаление программ в Ubuntu;
aptitude — текстовая оболочка для apt, позволяет управлять программным обеспечением, используется по умолчанию в Debian;
ar — утилита для создания, модификации и извлечения файлов из архивов ar;
arch — отображает информацию об архитектуре системы;
arp — управление таблицей ARP кэша;
as — ассемблер;
aspell — интерактивная проверка орфографии;
at — запланировать запуск команды на нужное время;
awk — утилита для фильтрации текста на основе регулярных выражений и языка программирования AWK;
basename — удаляет информацию о директории из имени файла;
bash — интерпретатор команд Bourne Again Shell, используется по умолчанию в большинстве дистрибутивов Linux;
bс — простой консольный калькулятор;
bdiff — поиск отличий в больших файлах;
bfs — текстовый редактор, для работы с большими файлами;
bg — восстановить задачу, свернутую в фоновый режим;
biff — получить подробную информацию про электронное письмо в терминале;
break — завершить цикл while, for, foreach или until;
bs — версия игры Battleship для Linux;
bye — эквивалент команды exit, используется для выхода из терминала;
cal — отобразить правильно отформатированный календарь в командной строке;
calendar — отобразить напоминания и заметки;
cancel — остановить вывод информации о работе задачи;
cat — вывести содержимое файла;
cc — компилятор языка Си;
cd — изменить рабочую директорию;
cfdisk — утилита для разметки диска в терминале, более простая в использовании, чем fdisk;
chdir — аналог cd, меняет текущую директорию на указанную;
checkeq — процессор языка программирования для описания сравнений;
checknr — проверка файлов nroff и troff на ошибки;
chfn — изменить дополнительную информацию о пользователе, такую как номер телефона, имя и так далее;
chgrp — изменить группу для файла;
chmod — изменить разрешения для файлов или папок;
chown — изменить владельца файла;
chroot — запустить команду или оболочку в другом корневом каталоге, каталог изолирован и команда не может получить из него доступ к внешней системе;
chsh — изменить оболочку входа;
cksum — подсчитать и вывести CRC сумму для файла;
clear — очистить вывод терминала;
cmp — сравнить два файла побайтно;
col — команда читает стандартный ввод построчно и передает информацию на вывод с возможностью реверсной подачи бумаги;
comm — сравнить два небольших файла построчно;
compress — сжать один или несколько файлов;
continue — завершить текущую итерацию while, for, foreach и until;
cp — скопировать файл или папку;
cpio — создание и распаковка архивов типа cpio;
crontab — настройка расписаний и заданий планировщика cron;
csh — командная оболочка C Shell;
csplit — обрезать часть файла по шаблону;
ctags — создать файл тегов для исходного кода;
cu — отправка сигнала другой системе через терминал;
curl — передача и получение данных с удаленного сервера;
cut — обрезать определенную часть каждой строки из файла;
date — отобразить текущую дату и время;
dc — сложный стековый арифметический калькулятор;
dd — утилита для копирования бинарных данных из одного места в другое;
delgroup — удалить группу;
deluser — удалить пользователя;
depmod — вывести список всех загруженных модулей ядра и их зависимостей;
deroff — удалить nroff, troff конструкции из файлов;
df — посмотреть общее доступное дисковое пространство в системе;
dhclient — получить динамический ip адрес по DHCP;
dig — посмотреть информацию о DNS;
dircmp — сравнение содержимого двух папок;
dirname — удалить имя файла из адреса, оставить только адрес папки;
dmesg — вывести последние записи журнала ядра;
dos2unix — конвертировать текстовые файлы из формата DOS в Unix;
dpkg — низкоуровневая утилита установки пакетов в Ubuntu;
dpost — перекодирование файлов из формата troff в PostScript;
du — отобразить занимаемое каждым файлом место на диске;
echo — вывести строку текста;
ed — простой текстовый редактор;
edit — еще один текстовый редактор;
egrep — фильтрация текста с учетом регулярных выражений;
eject — извлечь лоток CD-ROM;
elm — клиент электронной почты;
emacs — очень мощный и настраиваемый текстовый редактор;
emerge — пакетный менеджер Gentoo;
enable — включение и отключение принтеров LP;
env — вывести значение переменной окружения;
eqn — язык программирования для описания сравнений;
ex — режим редактирования строки редактора Vim;
exit — завершить сеанс работы с оболочкой;
expand — заменить символы табуляции на ряд пробелов;
expr — обработать аргументы как выражение;
fc — вывод, модификация и выполнение команд из истории;
fdisk — утилита для разметки диска;
fg — восстановление программы, свернутой в фоновый режим;
fgrep — фильтрация текста только по целым строкам;
file — вывод типа файла;
find — поиск файлов в файловой системе по разным условиям;
findsmb — вывести список всех машин, доступных по протоколу SMB;
finger — вывести дополнительную информацию о пользователе;
fmt — форматирование и оптимизация текстовых файлов;
fold — позволяет переносить строки указанной дины из одного файла в другой;
for — организация цикла со счетчиком для выполнения нескольких команд;
foreach — выполнять набор команд для каждого из элементов переданного массива;
free — отобразить свободную оперативную память;
fsck — проверка файловой системы на ошибки;
ftp — интерактивная команда для доступа к FTP серверу;
fuser — позволяет определить какой процесс использует файлы или сокеты;
gawk — GNU версия утилиты awk;
gcc — компилятор языка программирования C++;
getfacl — отобразить информацию про списки контроля доступа для файла;
gpasswd — управление файлами /etc/group и /etc/passwd;
gprof — отобразить доступную информацию о профилировании программы;
grep — фильтрация текста на основе регулярных выражений;
groupadd — создать новую группу;
groupdel — удалить группу;
groupmod — изменение группы;
gnuzip — распаковка сжатых файлов;
gview — запускает графическую версию реактора Vim;
gvim — синоним для gview;
gzip — создание, изменение, просмотр содержимого и распаковка архивов Gzip;
halt — немедленно выключить компьютер;
head — отобразить первые 10 строк из файла;
help — вывести помощь по командной оболочке;
history — вывести последние использованные команды linux;
host — преобразовать имя хоста в ip адрес;
hostid — вывести цифровой идентификатор для хоста;
hostname — вывод и настройка текущего имени хоста;
htop — интерактивный диспетчер задач, который работает в терминале;
id — вывести информацию о пользователей и его группах;
ifconfig — вывод и настройка сетевых интерфейсов;
ifdown — отключить сетевой интерфейс;
ifquery — выбрать информацию о сетевом интерфейсе;
ifup — включить сетевой интерфейс;
info — просмотр документации;
insmod — загрузить модуль ядра, в параметрах нужно передать файл;
iostat — статистика нагрузки на процессор и жесткие диски;
ip — новая утилита для управления сетевыми интерфейсами;
iwconfig — настройка беспроводных сетевых интерфейсов;
jobs — вывести список и состояние всех, запущенных в фоне задач;
join — объединить строки из двух файлов;
kill — отправить сигнал процессу, например, чтобы его завершить;
lillall — убить все процессы с указанным именем;
ksh — командная оболочка Korn Shell;
last — отобразить историю входов пользователей;
ld — редактор ссылок на библиотеки для объектов;
ldd — выводит список зависимостей исполняемого файла и статических объектов;
less — постраничная прокрутка длинного текста;
link — создать жесткую ссылку на файл;
ln — создать символическую ссылку на файл;
lo — завершить работу с командной оболочкой;
locate — поиск файлов, используя проиндексированную базу данных;
login — войти в систему;
logname — выводит логин пользователя;
logout — аналог lo;
losetup — создание и управление виртуальными loop устройствами;
ls — вывести содержимое каталога;
lsmod — посмотреть все загруженные модули ядра;
lsof — посмотреть список всех открытых файлов;
lzcat — посмотреть содержимое файла, сжатого lzma;
lzma — сжать или распаковать файл по алгоритму lzma;
mach — вывести информацию о процессоре;
mailx — обработать сообщения электронной почты;
make — выполнить сборку программы из исходников;
man — просмотр документации;
merge — объединить содержимое трех файлов в один;
mesg — отправка сообщений в другой терминал;
mkdir — создать папку linux;
mkfs — форматировать раздел в выбранную файловую систему;
mkswap — форматировать раздел или файл в swap;
modinfo — вывести информацию про модуль ядра;
modprobe — загрузить модуль ядра по имени;
more — еще одна команда для прокрутки длинного текста;
mount — монтирование разделов;
mt — управление магнитными кассетами;
mv — перемещение файлов и каталогов;
mysql — утилита для управления реляционной базой данных MySQL;
mysqldump — утилита для создания резервной копии базы данных MySQL;
nc — инструмент для передачи данных по TCP/IP;
netstat — вывод информации про сетевые соединения, таблицы маршрутизации, статистику интерфейсов и другое;
newgrp — дать пользователю права новой группы на время;
nice — настройка приоритета для команды;
niscat — отобразить все таблицы NIS и объекты;
nischmod — изменить права для объекта NIS;
nischown — изменить владельца объекта NIS;
nischttl — изменить время жизни пакетов для NIS:
nisdefaults — отобразить параметры по умолчанию для NIS;
nistbladm — администрирование таблиц NIS;
nl — вывод количества строк в файле;
nmap — сетевой сканер открытых портов и уязвимостей;
nohup — продолжить выполнение команды, когда сессия терминала будет завершена;
nroff — форматировать документ для отправки на принтер;
nslookup — получить информацию DNS об удаленном сервере;
od — вывести содержимое файла в двоичном формате;
on — выполнить команду в удаленной системе, но с локальными переменными среды;
onintr — вывести информацию об аппаратных прерываниях;
pack — сжатие файлов по алгоритму Хафмана;
pacman — пакетный менеджер ArchLinux;
pagesize — отобразить размер страниц памяти в байтах;
parted — утилита для разметки диска;
partprobe — проинформировать операционную систему про изменения в таблице разделов;
passwd — изменить пароль пользователя;
paste — объединить строки из файлов;
pax — управление архивами pax;
pact — вывести содержимое сжатого текстового файла;
perl — интерпретатор скриптов Perl;
pg — вывод текстового файла постранично;
pico — простой текстовый редактор;
pine — утилита для просмотра почты;
pkill — убить процесс по его имени, только один;
poweroff — выключить компьютер;
pr — подготовить текст к печати;
printenv — вывести все переменные среды;
printf — вывести отформатированную строку текста;
ps — вывести список запущенных процессов;
pstree — вывести список запущенных процессов в виде дерева;
pvs — вывести версию и внутреннюю информацию из файла ELF;
pwd — показать текущую папку;
quit — завершить сеанс командной оболочки;
rcp — скопировать файл в удаленную систему;
readlink — вывести содержимое символической ссылки;
reboot — перезагрузка компьютера;
red — запустить ed в режиме прокрутки текста;
rename — переименовать несколько файлов в Linux;
repeat — повторять выполнение команды нужное количество раз;
replace — утилита для замены содержимого в строках;
rlogin — войти в удаленную систему;
rm — удалить файл;
rmdir — удалить папку;
rmmod — выгрузить модуль ядра;
route — отобразить таблицу маршрутизации;
rpcinfo — вывести информацию о RPC;
rsh — выполнить команду в удаленной системе;
rsync — быстрый инструмент для копирования и синхронизации файлов с удаленной системой;
s2p — конвертировать sed скрипт в Perl;
scp — копирование файлов по ssh;
screen — консольный менеджер виртуальных терминалов;
script — записывает все, что выводится на экран;
sdiff — сравнивает два файла;
sed — потоковый редактор текста на основе регулярных выражений;
sendmail — отправить письмо;
service — управление службами в Ubuntu;
set — установить значение переменной окружения;
setfacl — настройка списков контроля доступа для файлов;
sfdisk — еще одна программа для разметки дисков;
sftp — клиент для работы с sFTP по защищенному каналу;
sh — командная оболочка Bourne Shell;
shred — удалить файл без возможности восстановления;
shutdown — выключить компьютер или спланировать выключение;
sleep — ожидать указанное количество секунд;
slogin — войти в удаленную систему;
smbclient — консольный клиент для работы с удаленной системой по протоколу SMB;
sort — сортировка строк в Linux;
spell — проверка орфографии;
split — объединение файлов;
startx — запустить сессию X сервера;
ss — просмотр информации о сетевых подключениях;
ssh — подключение к удаленной системе;
stat — отобразить статистику для файла или файловой системы;
stop — остановить задачу в фоне;
strftime — форматировать строку с датой и временем;
strip — удалить отладочную информацию из исполняемых файлов;
stty — настройка параметров текущего терминала;
su — авторизация от имени другого пользователя;
sudo — выполнить команду от имени другого пользователя;
swapoff — отключить раздел подкачки;
swapon — включить раздел подкачки;
systemctl — управление службами в systemd;
tabs — остановить работу вкладок в терминале;
tac — вывести тест, полученный на входе в обратном порядке;
tail — отобразить последних 10 строк файла;
talk — отправить сообщение другому, авторизованному пользователю;
tar — упаковка и распаковка архивов tar;
tcopy — копирование магнитных кассет;
tcpdump — консольный сетевой анализатор;
tcsh — командная оболочка tcsh;
tee — вывести поток ввода в несколько источников;
telnet — утилита для подключения к удаленному порту компьютера;
test — проверка типа файла;
time — замер времени работы команды консоли linux;
timex — замер времени работы команды с выводом более подробной информации;
todos — конвертирование текстовых файлов Unix в формат DOS;
top — интерактивный консольный менеджер процессов для Linux;
touch — создать файл;
traceroute — просмотр маршрута до удаленного узла;
tree — отобразить содержимое файла в формате дерева;
tty — вывести имя файла текущего терминала;
umask — установить маску прав для создания файлов;
umount — размонтировать раздел;
unalias — удалить псевдоним;
uname — посмотреть информацию о системе и ядре;
uncompress — распаковать сжатый файл;
uniq — найти количество уникальных строк в файле;
unlink — удалить ссылку на файл;
unlzma — распаковать архив lzma;
unpack — извлечь файлы из архива pack;
until — организация цикла типа until;
unxz — извлечь все файлы из архива xz;
unzip — распаковать zip архив;
uptime — узнать время работы компьютера;
useradd — добавить пользователя;
userdel — удалить пользователя;
usermod — настройка пользователя;
vacation — настройка автоматических ответов на email;
vi — текстовый редактор Vi;
vim — аналог vi;
w — посмотреть авторизованных на данный момент пользователей;
wait — ожидает завершения процесса;
wall — отправляет сообщение всем авторизованным пользователям;
wc — подсчет количества строк;
wget — загрузка файлов из удаленного сервера;
whereis — просмотр адреса исполняемого файла, исходников и страниц справки для команды;
which — просмотр пути исполняемого файла для команды;
while — организация цикла типа while;
who — посмотреть активных пользователей в системе;
whoami — вывести текущего пользователя;
whois — вывести доступную информацию об интернет ресурсе;
Xorg — исполняемый файл X сервера;
xargs — позволяет составлять команды на лету;
xfd — отобразить все символы шрифта X сервера;
xhost — настройка прав доступа к X серверу;
xlsfonts — отобразить все шрифты X сервера;
xrdb — управление базой данных ресурсов X сервера;
xset — изменить значение переменной X сервера;
xz — сжать файл в формат xz;
xzcat — посмотреть содержимое текстового файла сжатого xz;
yacc — компилятор Yet another compiler-compiler;
yes — ответить да, на запрос другой команды;
yppasswd — изменить пароль базы данных NIS;
yum — пакетный менеджер дистрибутивов Red Hat;
zcat — вывести содержимое файла, сжатого zip;
zipcloack — зашифровать zip файл;
zipinfo — вывести информацию о zip файле;
zipnote — просмотр и изменение комментариев к zip файлам;
zipsplit — объединение нескольких zip файлов;
zypper — менеджер пакетов OpenSUSE.

А давайте выкинем плохую программу и купим хорошую?

Достаточно популярна практика решения проблем маханием шашкой.

Мы часто слышим “у нас плохая программа, хотим вместо неё купить хорошую”. На самом деле это звучит как “мы не хотим решать проблемы, покажите нам способ, как можно ничего не делать”. Умело осваивающие бюджет “эффективные менеджеры” консолидируют десятки баз в одну, а если у них только одна база — наоборот, дробят на несколько, со словами “вот сейчас плохо, а будет хорошо”. Выяснить правду можно, если начать копать. Чем конкретно хорошая программа лучше плохой? Как детально она работает лучше, чем текущая? За счёт чего хорошая программа имеет преимущества над текущей? Погружаясь в детали, иногда можно сделать приятное открытие: значительно дешевле исправить три места в коде текущей программы, чем покупать и внедрять заново новую программу. Даже если теоретически вы правы, и новая программа действительно существенно лучше старой, никто не отменял любимого народом тихого саботажа. Какой бы замечательный не были вы с вашей программой, у вас может не получиться заставить пользователей работать в новой программе так же, как они работали в старой. Привычка — страшная сила. Кто не работал с SAPом, может поверить на слово, что там легче прогнуть бизнес и пользователей под функционал программы, чем программу адаптировать под индивидуальные особенности бизнеса. В этом плане нам очень повезло, платформа 1С позволяет адаптировать программу под специфику бизнеса.
1С — это практически рай для перфекционистов, процесс можно улучшать постоянно!
Мы не будем называть имя клиента, возможно его кто-то узнает, который обратился к нам несколько лет назад за помощью в масштабном внедрении 1С со словами “скоро мы купим SAP, но пока нам надо на чём-то работать”. Вот так на чём-то и работают уже много лет, а SAP всё не покупают и не покупают.
Поскольку 1С сейчас хорошо интегрируется практически с любыми технологиями, в некоторых случаях она более целесообразна в качестве фронтэнда (то есть автоматизированного рабочего места), а где-то наоборот, в качестве бэкенда (то есть серверной инфраструктуры). В такой схеме пользователь может даже не знать, что он работает с 1С. Например, сложный расчёт выполняется 1С-ом, а затем результат отдаётся потребителю через веб-сервис.
Чтобы не ходить далеко за примером: вот на слайде приведён снимок стартовой страницы одного из наших сервисов, а конкретно сервиса APDEX. На снимке вроде бы одна табличка и несколько кнопочек. По факту же для её отрисовки были запрошены данные из пяти разных баз, а если начать запрашивать отчёты — могут быть добавлены данные ещё из нескольких баз. Причём всё это в обычном веб-браузере, и процесс этот совершенно прозрачен для пользователя.
У любой технологии есть плюсы и минусы. Ваш профессионализм — это прямое отражение умения использовать плюсы, избегая ситуаций проявления недостатков системы.
Может быть не самый лучший пример, но для того чтобы в нашем бизнесе мы быстро начали принимать онлайн-платежи, мы сначала организовали приём оплаты через веб-клиента информационной системы 1С, потому что написание приложения у нас заняло три дня. И только потом уже на сайте на чистых веб-технологиях мы повторяли то же самое, опираясь на информационную систему 1С как на прототип.
Что же касается плохих и хороших программ — в нашей практике не раз, не два и не три были случаи, когда упираясь в какие-то совершенно конкретные недостатки старой программы, клиент принимал решение купить новую программу, в которой (как он верит) этих недостатков нет. И только потом, спустя несколько месяцев мучительного внедрения, постепенно приходит прозрение, что новая программа не умеет массу того, что было совершенно само собой разумеющимся в старой. Причём научить новую программу в итоге дольше и дороже, чем было довести до ума старую.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Совмещение терминального сервера с “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>) помещаются планы запросов для запросов UPDATEDELETE и INSERT. (Раньше был только SELECT)

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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


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

За работу с сеансовыми данными отвечает менеджер кластера – 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С.

Получить 3ю строку

Заметка

Declare @N int
set @N = 3;
WITH CTE AS
(
SELECT Name, Salary, EmpID, RN = ROW_NUMBER()
OVER (ORDER BY Salary DESC)
FROM Employee
)
SELECT Name, Salary, EmpID
FROM CTE
WHERE RN = @N

Как найти дубликат записи

Заметка

Дублирование записей с одним полем

SELECT name, COUNT(email)
FROM users
GROUP BY email
HAVING COUNT(email) > 1

 

Дублирование записей с несколькими полями

SELECT name, email, COUNT(*)
FROM users
GROUP BY name, email
HAVING COUNT(*) > 1

 

Перенос данных на рам-диск (или более быстрый диск)

1. Перенос кеша пользователя.

Для переноса кеша требуется выполнить 3 команды:

1. Удаление папки с кешем (по умолчанию: %USERPROFILE%\AppData\Roaming\1C\1Cv82) — для 8.2
%USERPROFILE%\AppData\Local\1C\1cv8 — для 8.3

rd /s /q «<Путь к папке на жестком диске>»

2. Создание папки на RAM диске:

mkdir «<Путь к папке на RAM диске>»

3. Создание символьной ссылки на папку RAM диска:

mklink /j «<Путь к папке на жестком диске>» «<Путь к папке на RAM диске>»

Данную процедуру нужно проделать для каждого пользователя. Проще всего написать батник вида:


mkdir B:\Users\1c\user1

rd /s /q «C:\Users\user1\AppData\Roaming\1C\1Cv82»
rd /s /q «C:\Users\user1\AppData\Local\1C\1cv8»

mklink /j «C:\Users\user1\AppData\Roaming\1C\1Cv82» «B:\Users\1c\user1»
mklink /j «C:\Users\user1\AppData\Roaming\1C\1cv8» «B:\Users\1c\user1»


Следует понимать что содержимое RAM диска находится в оперативной памяти и исчезает при выключении\перезагрузке сервера. Не обнаружив папку на диске B 1с выдаст ошибку: «Ошибка при выполнении файловой операции ‘<Путь к папке с кешем>'» и работать не будет. Поэтому при загрузке сервера каждый аз нужно выполнять создание папок на RAM диске:

mkdir «<Путь к папке на RAM диске>»

Пример батника:


mkdir B:\Users\1c\user1
mkdir B:\Users\1c\user2
mkdir B:\Users\1c\user3


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

gpedit.msc -> Конфигурация компьютера -> Конфигурация Windows -> Автозагрузка.

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

Некоторые приложения RAM-дисков http://www.gilev.ru/ram-disk/ позволяют создавать каталоги автоматом.

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

/N»<имя пользователя 1С>»

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

AdditionalParameters=/N»<имя пользователя 1С>» в файл

C:\Users\<Имя пользователя>\AppData\Roaming\1C\1CEStart\ibases.v8i

Размещать каталог C:\Users\<Имя пользователя>AppData\Roaming\1C\1cv8 на рам-диске надо продуманно, так как там хранятся различные настройки.

2. Перенос временных файлов пользователя.

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

Аналогично переносу кеша, только папка будет другой (по умолчанию: %USERPROFILE%\AppData\Local\Temp).

Каталоги
С:\Temp
C:\Windows\Temp
общесистемных временных файлов также могут быть использованы 1С и их можно переносить на РАМ-диск, но делать надо это острожно, с учетом других приложений на сервере.

3. Перенос журнала регистрации

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

Путь размещения лучше всего посмотреть через ключ D запуска сервера 1С.
Пример размещения C:\Program Files\1cv8\srvinfo\reg_1541\ad4b6360-d5be-4ddf-b55c-4af1496443f2\1Cv8Log

4. Перенос сеансовых данных.

При большом количестве пользователей есть смысл кэшировать сеансовые данные. Подробней здесь http://www.gilev.ru/introsd/ .
Путь размещения лучше всего посмотреть через ключ D запуска сервера 1С.
Пример размещения C:\Program Files\1cv8\srvinfo\reg_1541\snccntx10790324-1e9b-4e2e-bbdc-6d02b2fffd9e

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

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

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

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

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

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

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

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

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

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

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

Cтатус HTTP ответа веб сервера

Код состояния HTTP — это часть строки заголовка, ответа веб сервера на запрос клиента, информирующая о результате запроса и о том, что клиент должен предпринять далее

Код состояния HTTP — это часть строки заголовка, ответа веб сервера на запрос клиента, информирующая о результате запроса и о том, что клиент должен предпринять далее. Думаю не все знают как выглядит заголовок ответа сервера, зато уверен, каждый, пользующийся интернетом, не раз сталкивались, со страницей 404 Not Found или 403 Forbadden. Это и есть, видимый пользователю результат, выдачи сервером, того или иного кода статуса в строке заголовке.

Коды состояния HTTP, разделены на 5 категорий. Клиент может быть не знаком с тем или иным кодом ответа HTTP, однако он должен отреагировать согласно категории кода. Итак протокол HTTP поддерживает следующие коды статуса, разделенные по категориям:

1xx: Information — информационные

100 Continue — Продолжать.
Сервер доволен данными в запросе клиента, можно продолжать передачу заголовков. Появился в протоколе версии HTTP/1.1.
101 Switching Protocols — Переключение протоколов.
Сервер предлагает выбрать другой протокол, более соответствующий данному ресурсу. Протоколы предлагаемый сервером, указываются в строке заголовка Update, если предложенный сервером протокол, устраивает клиента, он высылает новый запрос с указанием нового протокола. Появился в протоколе версии HTTP/1.1.
102 Processing — Обрабатывается.
Используется в протоколе WebDAV, работающем поверх HTTP протокола. Данный код статуса информирует клиента о том, что запрос принят, но на его обработку может понадобится определенное время, что-бы он ( клиент ), не сбрасывал соединение. Клиент в этом случае должен обнулить таймер и ожидать следующей команды.

2xx: Success — Успешное завершение

200 OK — Хорошо.
Запрос к ресурсу выполнен успешно. Данные, запрошенные клиентом, находятся в заголовке и/или в теле ответа. Появился в протоколе версии HTTP/1.0.
201 Created — Создано.
Запрос выполнен успешно, новый ресурс создан. В ответе сервера, в заголовке Location, указывается местоположение созданного ресурса. Кроме того, серверу рекомендуется указывать характеристики созданного ресурса, в заголовке ответа. Появился в протоколе версии HTTP/1.0.
202 Accepted — Принято.
Запрос принят, но еще в обработке. Появился в протоколе версии HTTP/1.0.
203 Non-Authoritative Information — Информация из неавторитетного источника.
Аналогично коду 200, но в данном случае информация может быть неактуальной, так как взята не из первоисточника. Появился в протоколе версии HTTP/1.1.
204 No Content — Отсутствует содержимое.
Сервер успешно обработал запрос, но не вернул содержимого. Появился в протоколе версии HTTP/1.0.
205 Reset Content — Сбросить содержимое.
Сервер успешно обработал запрос, но не вернул содержимого. В отличии от кода 204, данный код, требует от клиента, сбросить представление документа. Появился в протоколе версии HTTP/1.1.
206 Partial Content — Часть содержимого.
Сервер вернул результат запроса клиентом, части содержимого, с помощью заголовка range. Используется для докачки файлов или для многопоточной закачки. Появился в протоколе версии HTTP/1.1.
207 Multi-Status — Многостатусный.
Возвращаемое сервером тело сообщения, представляет из себя XML документ со статусами выполнения нескольких подзапросов. Используется в протоколе WebDAV.
226 IM Used — Использовано IM
Расширение HTTP для поддержки «дельта кодирования» ( delta encoding ). Заголовок A-IM принят, данные возвращаются согласно установленным параметрам.

3xx: Redirection — Редирект ( перенаправление )

Коды данной категории, сообщают клиенту, что для завершения запроса, ему необходимо выполнить дополнительный запрос, как правило по другому URI, соответствующий адрес указывается в строке Location, ответа сервера. Программа — клиент может совершать дополнительные запросы без участия пользователя, при условии что дополнительный запрос делается методами GET или HEAD.

Некоторые клиенты некорректно работают с редиректами 301 и 302, применяя в запросе ко второму ресурсу метод GET, несмотря на то, что первый запрос был сделан с использованием другого метода. В протоколеHTTP версии 1.1, вместо ответа статуса 302, были введены дополнительные коды ответов, 303 и 307. Изменять метод, необходимо только в случает ответа сервера со статусом 303, в остальных случаях использовать исходный метод.

300 Multiple Choices — Несколько вариантов выбора.
По запрошенному URI, существует несколько вариантов ресурса, различных по MIME типу. языку или другим признакам. В ответе сервера, передается список альтернатив, выбираемый клиентским приложением автоматически или самим пользователем. Появился в протоколе версии HTTP/1.0.
301 Moved Permanently — Перемещёно окончательно.
Запрошенный ресурс был окончательно перемещен на URI, указанный в строке заголовка Location, ответа сервера. Некоторые клиенты, при обработке данного кода, ведут себя некорректно, см. выше. Появился в протоколе версии HTTP/1.0.
302 Found — Найдено ( Moved Temporarily )
Данный код статуса сообщает клиенту, что ресурс временно доступен по другому URI, указанному в строке заголовка Location, заголовка ответа сервера. Данный код используется например, при согласовании содержимого ( Content Negotiation ), выполняемого сервером. Появился в протоколе версии HTTP/1.0.
303 See Other — Смотреть другое.
Документ из запрошенного URI, нужно запросить по адресу, указанному в строке заголовка Location, заголовка ответа сервера, используя метод GET, невзирая на то, каким методом был сделан первый запрос. Появился в протоколе версии HTTP/1.1.
304 Not Modified — Не изменялось.
Данный код выдается в случае запроса документа, методом GET, с использованием заголовков If-Modified-Since или If-None-Match, и документ не был изменен с указанного момента времени. Появился в протоколе версии HTTP/1.0.
305 Use Proxy — Использовать прокси сервер.
Запрос к ресурсу, должен выполняться через прокси-сервер., адрес которого, указан в строке заголовка Location, заголовка ответа сервера. Появился в протоколе версии HTTP/1.1.
307 Temporary Redirect — Временное перенаправление
Запрошенный ресурс временно доступен по URI, указанному в строке заголовка Location, заголовка ответа сервера. Появился в протоколе версии HTTP/1.1.

4xx: Client Error — Ошибка клиента

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

400 Bad Request — Плохой запрос.
Из-за синтаксической ошибки, запрос не был понят сервером. Появился в протоколе версии HTTP/1.0.
401 Unauthorized — Не авторизован.
Ресурс требует идентификации пользователя. Клиентское приложение запрашивает у пользователя данные для аутентификации ( имя, пароль ) и передает их на сервер в заголовке WWW-Authenticate. Если данные указаны не правильно, будет снова выдан этот-же код статуса. Появился в протоколе версии HTTP/1.0.
402 Payment Required — Необходима оплата.
Пока не используется. Появился в протоколе версии HTTP/1.1.
403 Forbidden — Запрещено.
Сервер отказал в доступе к запрошенному ресурсу ввиду ограничений. Ограничения могут быть любыми, установленными администратором сервера, или определенным веб приложением. Например, в целях безопасности, закрыт доступ к файлу, .htacces или .htpasswd или к закрытой директории сайта, или в случае, когда аутентификация должна производится через веб приложение ( например сайтовый движок ), ну или блокировка по IP адресу, в случае слишком частых обращений. Появился в протоколе версии HTTP/1.0.
404 Not Found — Не найдено.
Сервер не нашел запрошенный ресурс по указанному адресу. Кроме того данный код ответа можно использовать вместо 403, с целью, скрыть расположение документа, доступ к которому запрещен. Появился в протоколе версии HTTP/1.0.
405 Method Not Allowed — Метод не поддерживается.
Клиент попытался использовать метод, недопустимый для данного ресурса. Сервер передает в заголовке, строку Allow, содержащую список допустимых методов. Появился в протоколе версии HTTP/1.1.
406 Not Acceptable — Не приемлемо.
Запрошенный ресурс, не удовлетворяет, запрошенные характеристики. В случае, если запрос был сделан не методом HEAD, сервер вернет список допустимых характеристик запрошенного ресурса. Появился в протоколе версии HTTP/1.1.
407 Proxy Authentication Required — Необходима прокси авторизация.
Данный код статуса, аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Появился в протоколе версии HTTP/1.1.
408 Request Timeout — Время ожидания истекло.
Истек таймаут ожидания передачи данных, между сервером и клиентом. Появился в протоколе версии HTTP/1.1.
409 Conflict — Конфликт.
Конфликтная ситуация при обращении к ресурсу. Такое может произойти, например, при попытке одновременного изменения файла, методом PUT, несколькими клиентами. Появился в протоколе версииHTTP/1.1.
410 Gone — Удалён.
Данный ответ выдается в случае, если документ был по указанному URI, но в данный момент удален. Появился в протоколе версии HTTP/1.1.
411 Length Required — Необходима длина.
Этот код статуса говорит о том, что для данного URI, в заголовке запроса, должно быть указано значение в поле Content-Length. Появился в протоколе версии HTTP/1.1.
412 Precondition Failed — Условие «ложно.
Данный код выдается в случае, если ни одно из условных полей заголовка не было удовлетворено. Появился в протоколе версии HTTP/1.1.
413 Request Entity Too Large — Запрошены слишком большие данные.
Данный код выдается, если сервер по каким-либо причинам, не может передать, требуемый объем данных. Если это временная проблема, сервер может указать время, по истечении которого можно будет попробовать повторно запросить ресурс, в строке заголовка, Retry-After. Появился в протоколе версии HTTP/1.1.
414 Request-URI Too Long — Запрашиваемый URI слишком длинный.
Слишком длинная строка запроса. Такая ситуация может произойти, например в случае попытки, передать данные методом GET, вместо использования POST. Появился в протоколе версии HTTP/1.1.
415 Unsupported Media Type — Неподдерживаемый тип данных.
Сервер, по какой-то причине, отказался обрабатывать запрошенные данные, используемым методом. Появился в протоколе версии HTTP/1.1.
416 Requested Range Not Satisfiable — Запрашиваемый диапазон не достижим.
В строке заголовка запроса Range, установлен диапазон, выходящий за рамки запрошенного ресурса и отсутствует строка If-Range. Появился в протоколе версии HTTP/1.1.
417 Expectation Failed — Ожидаемое не приемлемо.
Сервер не может обработать строку заголовка запроса Expect. Появился в протоколе версии HTTP/1.1.
422 Unprocessable Entity — Необрабатываемый экземпляр.
Запрос принят, тип данных может быть обработан, синтаксис XML данных в теле запроса верен, но имеет место логическая ошибка, не позволяющая обработать запрос к ресурсу. Используется в протоколеWebDAV.
423 Locked — Заблокировано.
Запрошенный ресурс заблокирован от данного метода. Используется в протоколе WebDAV.
424 Failed Dependency — Невыполненная зависимость.
Выполнение запроса, может зависеть от результата выполнения, какой-либо другой операции, при невыполнении данного условия, будет выдан этот код статуса. Используется в протоколе WebDAV.
425 Unordered Collection — Беспорядочный набор.
Этот код статуса будет выдан в случае, если клиент отправил запрос обозначив положение в неотсортированной коллекции или используя порядок следования элементов отличный от серверного. Введено в черновике по WebDAV Advanced Collections Protocol.
426 Upgrade Required — Требуется обновление.
Указание сервера, клиенту, обновить протокол. Заголовок ответа, должен содержать правильно составленные поля Upgrade и Connection. Введено в RFC 2817 для возможности перехода к TLS посредствомHTTP.
449 Retry With — Повторить с…
Выдается в случае поступления не достаточного количества информации для обработки запроса. В заголовок ответа сервера, помещается строка Ms-Echo-Request. Введено корпорацией Microsoft дляWebDAV.

5xx: Server Error — Ошибка на стороне сервера

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

500 Internal Server Error — Внутренняя ошибка сервера.
Любая внутренняя ошибка на стороне сервера не подпадающая под остальные ошибки из категории 5хх. Появился в протоколе версии HTTP/1.0.
501 Not Implemented — Не реализовано.
Сервер не поддерживает, необходимых для обработки запроса, возможностей. ( например не поддерживается необходимый метод обработки ). Появился в протоколе версии HTTP/1.0.
502 Bad Gateway — Плохой шлюз.
Сервер, работающий в качестве прокси или шлюза, получил сообщение о неудачное в промежуточной операции. Появился в протоколе версии HTTP/1.0.
503 Service Unavailable — Сервис недоступен.
Сервер не в состоянии обрабатывать запросы клиентов по техническим причинам. Появился в протоколе версии HTTP/1.0.
504 Gateway Timeout — Истек таймаут ожидания ответа шлюза.
Проксирующий сервер или шлюз, не дождался ответа от вышестоящего сервера для завершения обработки запроса. Появился в протоколе версии HTTP/1.0.
505 HTTP Version Not Supported — Версия HTTP протокола не поддерживается.
Сервер не поддерживает, или не может обработать, указанную в заголовке версию HTTP протокола. Появился в протоколе версии HTTP/1.0.
506 Variant Also Negotiates — Вариант тоже согласован.
Из-за не верной конфигурации, выбранный вариант указывает сам на себя, в следствии чего, связывание прерывается. Добавлено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation.
507 Insufficient Storage — Переполнение хранилища.
Недостаточно места для обработки текущего запроса. Возможно временная проблема. Используется в протоколе WebDAV.
509 Bandwidth Limit Exceeded — Пропускная возможность канала исчерпана.
Данный код статуса, используется в случае превышения веб площадкой, отведенного ей лимита, на потребляемый трафик. Данный код не описан ни одним RFC и используется только модулем bw/limited, панели веб-хостинга cPanel.
510 Not Extended — Нет расширения.
У сервера отсутствует расширение, которое пытается использовать клиентом. Сервер может передавать информацию, об имеющихся у него расширениях. Введено в RFC 2774 для дополнения протокола HTTPподдержкой расширений.

Методы обработки запросов HTTP

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

Любой веб сервер обязан работать, по крайней мере с двумя методами GET и HEAD. Если сервер не смог определить метод, указанный в заголовке запроса клиента, он должен вернуть код статуса 501 (Not Implemented), если-же метод серверу известен, но неприменим к данному ресурсу, будет возвращен код статуса 405 (Method Not Allowed). Как в первом, так и во втором случае, сервер должен включить в свой ответ, заголовок Allow со списком методов, которые он поддерживает.

Метод OPTIONS

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

Что-бы выяснить возможности сервера, клиент должен указать в запросе URI, символ — «*«, то есть данный запрос к серверу выглядит как: OPTIONS * HTTP/1.1. Кроме прочего, данный запрос может быть использован для проверки работоспособности сервера и поддержки им протокола HTTP, версии 1.1. Результаты данного запроса не кэшируются.

Метод GET

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

Параметры для выполнения запроса, передаются в URI запрашиваемого ресурса, после символа «?«. Запрос в таком случае выглядит примерно так: GET /some/resource?param1=val1&param2=val2 HTTP/1.1.

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

Кроме вышесказанного, существуют еще два вида метода GET, это:
условный GET, содержащий заголовки If-Modified-Since, If-Match, If-Range и им подобные,
Частичный GET, содержащий заголовок Range с указанием байтового диапазона данных, которые сервер должен отдать. Данный вид запроса используется для докачки и организации многопоточных закачек.

Порядок работы с этими подвидами запроса GET, стандартами определен отдельно.

Метод HEAD

Данный метод, аналогичен методу GET, с той лишь разницей, что сервер не отправляет тело ответа. Метод HEAD, как правило используется для получения метаданных ресурса, проверки URL ( есть-ли указанный ресурс на самом деле ) и для выяснения факта изменения ресурса с момента последнего обращения к нему.

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

Метод POST

Метод POST, используется для передачи пользовательских данных на сервер, указанному ресурсу. Примером может послужить HTML форма с указанным атрибутом Method=»POST», для отправки комментария к статье. После заполнения необходимых полей формы, пользователь жмет кнопку «Отправить» и данные, методом POST, передаются серверному сценарию, который в свою очередь выводит их на странице комментариев. Таким-же образом, с помощью метода POST, можно передавать файлы.

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

Если в результате запроса методом POST, возвращается код 200 (Ok) или 204 (No Content), в тело ответа сервера, добавляется сообщение о результате выполнения запроса. Например, если был создан ресурс, сервер вернет 201 (Created), указав при этом URI созданного ресурса в заголовке Location.

Ответы сервера, на выполнение метода POST, не кэшируются.

Метод PUT

Используется для загрузки данных запроса на указанный URI. В случае отсутствия ресурса по указанному в заголовке URI, сервер создает его и возвращает код статуса 201 (Created), если ресурс присутствовал и был изменен в результате запроса PUT, выдается код статуса 200 (Ok) или 204 (No Content). Если какой-то из переданных серверу заголовков Content-*, не опознан или не может быть использован в данной ситуации, сервер возвращает статус ошибки 501 (Not Implemented).

Главное различие методов PUT и POST в том, что при методе POST, предполагается, что по указанному URI, будет производиться обработка, передаваемых клиентом данных, а при методе PUT, клиент подразумевает, что загружаемые данные уже соответствуют ресурсу, расположенному по данному URI.

Ответы сервера при методе PUT не кэшируются.

Метод PATCH

Работает аналогично методу PUT, но применяется только к определенному фрагменту ресурса.

Метод DELETE

Удаляет ресурс, расположенный по заданному URI.

Метод TRACE

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

Метод LINK

Связывает указанный ресурс с другим ресурсом.

Метод UNLINK

Снимает привязку одного ресурса к другому.

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

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

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

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

Общие параметры командной строки

Общие параметры командной строки

Указание свойств подключения

/F <путь> — путь к информационной базе, если она хранится в файле 1Cv8.1CD (имя файла указывать не надо).

/S <адрес> — адрес информационной базы, хранящейся на сервере «1С:Предприятия 8», складывается следующим образом:

<Имя компьютера, работающего сервером приложений>\ <Ссылочное имя информационной базы, известное в рамках сервера «1С:Предприятия 8»>

/WS <url> — строка ws-соединения.

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

/IBConnectionString — позволяет задать строку соединения с информационной базой целиком в том виде, в котором ее возвращает функция СтрокаСоединенияИнформационнойБазы(). Части строки соединения могут быть переопределены параметрами /S и /F. Для этого нужно, чтобы/IBConnectionString находился в командной строке раньше них. Передавая строку соединения в качестве параметра командной строки, нужно помнить о том, что строка соединения содержит кавычки. Поэтому требуется взять всю строку в кавычки, а содержащиеся внутри кавычки удвоить.

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

wsn — имя пользователя для аутентификации на веб-сервере;
wsp — пароль пользователя для аутентификации на веб-сервере;
wspauto — использовать автоматические настройки прокси сервера;
wspsrv — адрес прокси сервера;
wspport — порт прокси;
wspuser — имя пользователя для прокси с авторизацией;
wsppwd — пароль для прокси с авторизацией.

/O <скорость соединения> — определяет скорость соединения (используется в тонкомклиенте):

 Normal — обычная,
Low — низкая скорость соединения.

Настройка аутентификации

/N <имя> — имя пользователя. Должно быть указано так же, как в списке пользователей, создаваемом в Конфигураторе.

/P <пароль> — пароль пользователя, имя которого указано в параметре /N. Если у пользователя нет пароля, этот параметр можно опустить.

/WA[+/-] — определяет режим использования аутентификации операционной системы при запуске «1С:Предприятия». Если параметр /WA не указывается, то подразумевается, что используется параметр командной строки /WA+.

/WA- — запрет применения аутентификации операционной системы при старте «1С:Предприятия».

/WA+ — установка обязательного применения аутентификации операционной системы при старте «1С:Предприятия».

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

/WSA[+/-] — определяет режим использования аутентификации операционной системы на веб-сервере. Если параметр /WSA не указывается, то подразумевается, что используется параметр командной строки WSA+.

/WSA- — запрет применения аутентификации пользователя на веб-сервере.

/WSA+ — установка применения аутентификации пользователя на веб-сервере. Используется аутентификация средствами операционной системы.

/WSN <имя> — имя пользователя для аутентификации на веб-сервере в случае указания параметра /WSA+.

/WSP <пароль> — пароль пользователя, имя которого указано в параметре /WSN, для аутентификации на веб-сервере.

/AppAutoCheckVersion[+/-]  — определяет использование подбора нужной версии для каждой базы:

/AppAutoCheckVersion— — автоматический подбор версии платформы не выполняется.

/AppAutoCheckVersion+ — автоматический подбор версии платформы выполняется выполняется для каждой базы (по умолчанию).

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

/NoProxy — запретить использование прокси (только для ws-соединения тонкого клиента).

/Proxy -PSrv <адрес прокси> -PPort <порт> [-PUser <имя пользователя прокси> [-PPwd <пароль>] ] — использовать указанные настройки прокси, игнорируя умолчания (только для ws-соединения) (используется только в тонком клиенте). Например: /Proxy -PSrv 192.168.0.10 -PPort 3128.

/LogUI — логирование действий пользователя.

/OIDA[+/-] — применение сквозной аутентификации пользователя между разными информационными базами и/или внешними ресурсами. (Используется только для тонкого и веб-клиентов!) :

/OIDA+ — использовать OpenID-аутентификацию (по умолчанию).

/OIDA- — не использовать OpenID-аутентификацию.

Если при запуске клиента параметр OIDA не задан, или задан параметр OIDA+, то производится попытка аутентификации через OpenID-провайдера, адрес которого задан в файле deafault.vrd публикации этой информационной базы.

Если OpenID-провайдер требует интерактивной аутентификации (происходит первое обращение или истекло время жизни признака аутентифицированности), клиент отображает диалог для ввода имени и пароля пользователя.

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

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

/Authoff  выполняет OpenID logout (завершение сеанса работы пользователя). Завершение сеанса работы выполняется вне зависимости от используемого в дальнейшем метода аутентификации.

Поиск локального ключа защиты

/UseHwLicenses[+/-] — определяет режим поиска локального ключа защиты.

/UseHwLicenses+ — поиск локального ключа защиты выполняется.

/UseHwLicenses- — поиск локального ключа защиты не выполняется.

Настройки локализации

/L <код языка> — указывается код языка интерфейса платформы. Поддерживаемые языки интерфейса:

Язык

Код
Азербайджанский az
Английский en
Болгарский bg
Венгерский hu
Вьетнамский vi
Грузинский ka
Казахский kk
Китайский zh
Латышский lv
Литовский lt
Немецкий de
Польский pl
Румынский ro
Русский ru
Турецкий tr
Украинский uk
Французский fr

/VL <код локализации сеанса> — указывается код локализации сеанса, используемый при форматировании данных типа Число и Дата, а также в методах ЧислоПрописью() и ПредставлениеПериода().

Настройка интерфейса (Только для управляемого приложения)

/iTaxi — Запуск в режиме интерфейса «Такси».

/itdi — Запуск в режиме интерфейса с использованием закладок.

/isdi — Запуск в режиме интерфейса с использованием отдельных окон (используется по умолчанию).

/DisplayAllFunctions — включает команду меню «Все функции«.

Отладчик и показатели производительности

/Debug — указывает, что запуск 1С:Предприятия выполняется в отладочном режиме.

/DebuggerURL <URL отладчика> — идентификация отладчика, к которому приложение сразу после запуска должно подключиться. Указывается URL отладчика (протокол, компьютер и номер порта), на котором в отладчике можно создавать удаленные объекты.

/DisplayPerformance — показать количество вызовов сервера и объем данных, отправляемых на сервер и принимаемых с сервера.

/SimulateServerCallDelay [-CallXXXXX] [-SendYYYYY] [-ReceiveZZZZZ] — имитация работы клиента в условиях медленного соединения.

-Call — указывает величину задержки (XXXXX) при вызове сервера в секундах, если не указан, то 4.45 с;
-Send — указывает величину задержки (YYYYY) в секундах в расчете на каждые 1 Кбайт данных, отправляемых на сервер. Если не указан, то 0.45 с;
-Receive — указывает величину задержки (ZZZZZ) в секундах в расчете на каждые 1 Кбайт данных, принятых с  сервера. Если не указан, то 0,15 с.

Максимальное значение временных задержек — 10 сек.

Пример: /SimulateServerCallDelay -Call2.1 -Send1.3 -Receive1.2

Автоматизированное тестирование

/TestManager — запуск толстого и тонкого клиента для управления другими клиентами с помощью специализированной объектной модели.

/TestClient [-TPort<Номер TCP-порта>] — запуск толстого и тонкого клиента как управляемого другими клиентами с помощью менеджера тестирования.

-TPort<Номер TCP-порта> указывает номер порта для взаимодействия клиента и менеджера тестирования. По умолчанию используется порт 1538.

/UILOGRECORDER [–TPort<Номер порта TCP/IP>] [-File<Путь>]  — запись журнала интерактивных действий пользователя и формирование на их основе сценария на встроенном языке «1С:Предприяти»е, позволяющего воспроизводить записанные действия. Может совмещаться с параметром /TESTCLIENT.

-TPort<Номер TCP-порта> указывает номер порта для взаимодействия клиента и менеджера тестирования. По умолчанию используется порт 1538.

-File<Путь> имя файла, в который будет сохраняться журнал действий пользователя после завершения записи, если к клиенту не подключён менеджер тестирования.

Использование клиентских сертификатов (только для тонкого клиента)

/HttpsCert [-windows] [-recent] [-auto] [-choose] [-file <path>] [-pwd <password>] [-none] — указывает источник клиентского сертификата. Если данный параметр не указан, то источник клиентского сертификата определяется настройками диалога настройки соединения с информационной базой.  (Используется только в тонком клиенте!)

-windows — указывает, что при соединении нужно использовать клиентский сертификат из системного хранилища сертификатов операционной системы Microsoft Windows. Данная опция игнорируется, если установленовлена хотя бы одна из опций -file или –none.

-recent — выбирать или использовать ранее выбранный клиентский системный сертификат Microsoft Windows.

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

Данный способ выбора клиентского сертификата выбран по умолчанию для опции -windows, если опции -auto и -choose не установлены. Данный параметр игнорируется.

-auto — использовать автоматически выбранный клиентский сертификат из установленных в системном хранилище сертификатов операционной системы Microsoft Windows. Данный параметр игнорируется, если у параметра отсутствует опция –windows.

-choose — всегда выбирать используемый клиентский сертификат Microsoft Windows.

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

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

-file <path> — указывает, что необходимо использовать клиентский сертификат и приватный ключ из указанного файла. Данный параметр игнорируется, если у параметра установлена опция -none.

-pwd <password> — указывает пароль файла, содержащего клиентский сертификат и его приватный ключ. Если сервер требует предоставления клиентского сертификата и файл сертификата защищен паролем, то соединение возможно только при правильно указанном пароле. Данная опция игнорируется, если у данного параметра не указана опция -file.

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

Если ни одна из опций -windows-file или -none не установлена, то параметр /HttpsCertигнорируется.

/HttpsCA [-windows] [-file <path>] [-pwd <password>] [-none] — указывает источник CA сертификатов, используемых для проверки сертификата сервера.  Если данный параметр не указан, то источник сертификатов CA  определяется настройками диалога настройки соединения с информационной базой. (Используется только в тонком клиенте!)

-windows — указывает, что для проверки сертификата сервера при соединении нужно использовать сертификаты CA из системного хранилища сертификатов операционной системы Microsoft Windows. Данный параметр игнорируется, если установлена хотя бы одна из опций параметра -file или -none.

-file <path> — указывает, что для проверки сертификата сервера при соединении нужно использовать сертификаты CA загружаемые из указанного файла. Данный параметр игнорируется, если установлена опция параметра -none.

-pwd <password> — пароль файла, содержащего сертификаты CA. Если файл сертификата защищен паролем, то соединение возможно только при правильно указанном пароле. Данный параметр игнорируется, если у данного параметра не указана опция -file.

-none — указывает, что сертификаты CA не используются и сертификат сервера не проверяется.

Если ни одна из опций -windows-file или -none не установлена, то параметр /HttpsCAигнорируется.

/HttpsForceSSLv3 — определяет принудительное использование протокола SSL версии 3.0 независимо от настроек информационной базы (Используется только в тонком клиенте!)

Регистрация «1С:Предприятия 8» в качестве OLE-Automation-сервера

/RegServer — регистрация приложения.

/UnregServer — удаление регистрации приложения.

Прочие параметры

/@ <имя файла> — параметры командной строки записаны в указанном файле.

/AllowExecuteScheduledJobs -Off|-Force  — управление запуском регламентных заданий. Регламентные задания начинают выполняться на первом запущенном по порядку клиенте, у которого не AllowExecuteScheduledJobs –Off. После завершения сеанса этого клиента, выполнение переходит к какому-либо из других запущенных сеансов. Если запускается сеанс с AllowExecuteScheduledJobs –Force, то регламентные задания начинают выполняться на нем, не зависимо от наличия других сеансов.

/AppAutoInstallLastVersion+/- — управляет автоматической установкой новых версий приложения. «+» — установка новых версий включена; «-» — установка новых версий выключена.

/C <строка текста> — передача параметра в прикладное решение. Для доступа к параметру из встроенного языка используется свойство глобального контекста ПараметрЗапуска.

/ClearCache — очистка кэша клиент-серверных вызовов, в котором хранятся метаданные форм, модули и т.д.

/DisableStartupDialogs  — подавляет вызов стартового диалога и диалогов аутентификации. При этом:

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

/DisableStartupMessages — подавляет стартовые сообщения:

  • «Конфигурация базы данных не соответствует сохраненной конфигурации. Продолжить?»;
  • «Возможностей Вашего компьютера недостаточно для редактирования справки по конфигурации. Для редактирования справки необходимо установить Microsoft Internet Explorer версии 7.0 или выше.»;
  • «Возможностей Вашего компьютера недостаточно для редактирования html-документов, в том числе разделов справки. Для редактирования html-документов необходимо установить Microsoft Internet Explorer версии 7.0 или выше. В данном запуске редактирование html-документов будет недоступно.».

/EnableCheckExtensionsAndAddInsSyncCalls — включает режим строгой проверки использования синхронных вызовов расширений работы с файлами и криптографией и внешних компонент.

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

/Execute <имя файла внешней обработки> — предназначен для запуска внешней обработки в режиме «1С:Предприятие» непосредственно после старта системы.

/Out <имя файла> [-NoTruncate]] — установка файла для вывода служебных сообщений. Если задан параметр -NoTruncate (через пробел), файл не очищается.
Во время исполнения пакетных команд файл сообщений можно открыть для просмотра. Запись сообщений в файл не буферизуется (сообщения записываются сразу).

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

/RunModeManagedApplication — запуск толстого клиента в режиме управляемого приложения, при этом учитывается настройка в списке информационных баз:

  • «Выбирать автоматически» — запускается тонкий клиент;
  • «Тонкий клиент» — запускается тонкий клиент;
  • «Веб-клиент» — запускается веб-клиент;
  • «Толстый клиент» — запускается толстый клиент в режиме управляемого приложения.

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

/RunShortcut <имя файла> — позволяет запустить систему «1С:Предприятие 8» со списком информационных баз, полученным с помощью указанного файла. В качестве файла может быть указан файл списка общих информационных баз (*.v8i), или файл ярлыка информационных баз (*.v8l).

/SLev — определяет уровень защищенности соединения клиента с сервером «1С:Предприятия» (используется для тонкого и веб-клиентов в режиме «1С:Предприятие»).

Возможные значения:
/SLev0 — незащищенное соединение;
/SLev1 — защищенное соединение только в процессе выполнения аутентификации;
/SLev2 — защищенное соединение в течение всего сеанса;
Если не указан, используется значение /SLev0.

/TComp [-None | -Deflate | -SDC] — устанавливает режим сжатия трафика между сервером и клиентом (только для тонкого клиента).

-None — сжатие отключено;
-Deflate — используется стандартное http сжатие трафика по алгоритму deflate;
-SDC — используется собственный алгоритм сжатия;
По умолчанию используется SDC-сжатие трафика.

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

/URL <адрес> — указывает необходимость перехода по ссылке. Поддерживаются ссылки формата e1c:

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

Если подходящего клиентского приложения не найдено, строка соединения определяется из параметра командной строки /URL.

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

Для ссылок формата http(s) всегда запускается (или находится активный) тонкий клиент.

/UsePrivilegedMode — запуск в режиме привилегированного сеанса. Разрешен аутентифицированному пользователю, имеющему административные права. Журнал регистрации фиксирует установку или отказ в возможности установки режима привилегированного сеанса.

/Z<Общий реквизит 1>,<Общий реквизит 2>,…,<Общий реквизит N> — установка разделителей.

<Общий реквизит> = [<+>|<->]<значение общего реквизита>

[<+>|<->] — признак использования: «+» (по умолчанию) — реквизит используется; «» — не используется;

Если разделитель не используется, то перед значением должен быть «-«. Если первым символом в значении разделителя содержится символ «+» или ««, то при указании его нужно удваивать.

<значение общего реквизита> — значение общего реквизита. Если в значении разделителя присутствует запятая, то при указании ее нужно удваивать. Если значение разделителя пропущено, но разделитель должен использоваться, то используется символ «+».

Разделители разделяются запятой.

Например:

«/Z-ПервыйРазделитель,+,—ТретийРазделитель», что означает:

Первый разделитель выключен, значение — «ПервыйРазделитель»,

Второй разделитель включен, значение — пустая строка,

Третий разделитель выключен, значение — «-ТретийРазделитель».

1С Ошибка. Windows error: Ошибка исполнения функции — при установке платформы 1С

По адресу C:\ProgramData\1C\1CEStart находим файл 1CEStart.cfg, редактируем его — удаляем текст ADMINISTRATIONFUNC=0 и сохраняем файл. После этого установка выполняется нормально без ошибки.

Postgres параметр full_page_writes

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

Postgres параметр SYNCHRONOUS_COMMIT

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

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

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

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

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

Postgres: параметр fsync

Данный параметр отвечает за сброс данных из кэша на диск при завершении транзакций. Если установить в этом параметре значение off, то данные не будут записываться на дисковые накопители сразу после завершения операций. Это может существенно повысить скорость операций insert и update, но есть риск повредить базу, если произойдет сбой (неожиданное отключение питания, сбой ОС, сбой дисковой подсистемы).

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

Возможные значения:

  • open_datasync – запись данных методом open() с параметром O_DSYNC,
  • fdatasync – вызов метода fdatasync() после каждого commit,
  • fsync_writethrough – вызывать fsync() после каждого commit игнорирую параллельные процессы,
  • fsync – вызов fsync() после каждого commit,
  • open_sync – запись данных методом open() с параметром O_SYNC.

ПРИМЕЧАНИЕ! Не все методы доступны на определенных платформах. Выбор метода зависит от операционной системы под управлением, которой работает PostgreSQL.

В состав PostgreSQL входит утилита pg_test_fsync, с помощью которой можно определить оптимальное значение параметра wal_sync_method.

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

Для вероятно Windows оптимальным решением будет использование open_datasync.

Для Linux вероятно  оптимальным решением будет использование fdatasync и open_datasync.

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

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

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

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

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

Удалить дублирующие пакеты в CentOS

задача удалить ненужные пакеты с сервера CentOS x64, так как при установке установились и пакеты для архитектуры i386.

Нашлось вот такое решение:

yum remove $(rpm -q –qf=’%{NAME}.%{ARCH}\n’ | grep ‘\.i386$’)

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

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

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

DECLARE @cmd VARCHAR(4000)

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

OPEN TableNameCursor

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

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

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

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

OPEN IndexCursor

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

 

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

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

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

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

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

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

Событие ATTN

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

Использование буферного кеша Postgres

SELECT
'total', pg_size_pretty(count(*) * (SELECT current_setting('block_size')::int))
FROM pg_buffercache
UNION SELECT
'dirty', pg_size_pretty(count(*) * (SELECT current_setting('block_size')::int))
FROM pg_buffercache
WHERE isdirty
UNION SELECT
'clear', pg_size_pretty(count(*) * (SELECT current_setting('block_size')::int))
FROM pg_buffercache
WHERE NOT isdirty
UNION SELECT
'used', pg_size_pretty(count(*) * (SELECT current_setting('block_size')::int))
FROM pg_buffercache
WHERE reldatabase IS NOT NULL
UNION SELECT
'free',pg_size_pretty(count(*) * (SELECT current_setting('block_size')::int))
FROM pg_buffercache
WHERE reldatabase IS NULL;
SELECT
d.datname,
pg_size_pretty(pg_database_size(d.datname)) AS database_size,
pg_size_pretty(count(b.bufferid) * (SELECT current_setting('block_size')::int)) AS size_in_shared_buffers,
round((100 * count(b.bufferid) / (SELECT setting FROM pg_settings WHERE name
= 'shared_buffers')::decimal),2) AS pct_of_shared_buffers
FROM pg_buffercache b
JOIN pg_database d ON b.reldatabase = d.oid
WHERE b.reldatabase IS NOT NULL
GROUP BY 1 ORDER BY 4 DESC LIMIT 10;

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

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

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

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

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

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

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

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

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

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

Размер временных таблиц «1С» в Postgres

select relnamespace, sum(relpages::bigint*8192), pg_size_pretty(sum(relpages::bigint*8192))
from pg_class where relname like 'tt%' group by 1 order by 2 desc;
select sum(relpages::bigint*8192), pg_size_pretty(sum(relpages::bigint*8192)) from pg_class where relname like 'tt%';

Таблицы с максимальным пустым местом Postgres

-- установка расширения
create extension pg_freespacemap;
select
result.table_name,
result.freespace as fororder,
pg_size_pretty(result.size) as size,
pg_size_pretty(result.freespace) as freespace,
result.freespace * 100 / result.size as percent_free
from
(select
t.table_name,
pg_total_relation_size(t.table_name) as size,
sum(s.avail) as freespace
from
(select table_name from information_schema.tables where table_schema = 'public') as t,
LATERAL pg_freespace(t.table_name) as s
group by
t.table_name) as result
order by
fororder desc
limit 20;

Транзакции, ожидающие на блокировках Postgres

SELECT blocked_locks.pid AS blocked_pid,
blocked_activity.usename AS blocked_user,
blocking_locks.pid AS blocking_pid,
blocking_activity.usename AS blocking_user,
blocked_activity.query AS blocked_statement,
blocking_activity.query AS current_statement_in_blocking_process,
blocked_activity.application_name AS blocked_application,
blocking_activity.application_name AS blocking_application
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks
ON blocking_locks.locktype = blocked_locks.locktype
AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.GRANTED;

порядок опроса ключей 1C

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

(Аппаратный способ получения ключей может быть отключен или переопределен параметрами запуска типа /UseHwLicenses-)

Область блокировок 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С.

Долго завершается терминальная сессия 1С

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

  1. Уменьшить тайм-аут завершения процесса SplWOW64.exe. Для этого следует в значение системного реестра SplWOW64TimeOut установить в значение 1 (при отсутствии значения его следует создать с типом DWORD (32 бита)).
    Ветка реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print
  2. Добавить процесс SplWOW64.exe в список процессов, завершаемых при завершении терминальной сессии. Для этого следует значение системного реестра SPLWOW64.EXE установить в значение 0 (при отсутствии значения его следует создать с типом DWORD (32 бита)).
    Ветка реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TerminalServer\SysProcs

Примечание. SplWOW64.exe используется для преобразований между 32-разрядными и 64-разрядными приложениями и запускается 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  режим автоматического поиска циклических ссылок