Список сокращений

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

В текущей версии подсистемы ОП гистограмма строится автоматически.

При использовании подсистемы «Оценка производительности», если ключевая операция связана с транзакцией, это можно точно определить имеющимися средствами. Регистр сведений «Замеры времени» содержит реквизит «Имя пользователя» и данные о времени начала замера. Нужно найти по журналу регистрации, что пользователь в это время делал, и в нем по полю «Представление данных» определить, например, что это был за документ (номер и дату). Если ключевая операция с транзакцией не связана (например, ключевая операция – это выполнение отчета или открытие формы), обычно просто достаточно знать, под каким пользователем это действие выполнялось. Но если этого недостаточно, надо вместе с началом замера вносить в журнал регистрации данные, необходимые для понимания особенностей выполняемой операции.

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

Как говорилось выше, для получения необходимой точности нужно не менее 100 замеров. Если речь идет не о частых, а о редких или даже единичных событиях большой длительности (например, о выполнении каких-то регламентных операций), то описанный подход не годится: очень велика становится разница, выполняется операция, скажем, 2 часа или же 8. Если такая ключевая операция находится в числе прочих (коротких и частых), то надо смотреть по ситуации, что с ней делать. Можно считать для нее APDEX просто для сохранения единого подхода к замерам, соответственно подобрав целевое время, но можно сразу выделять ее в отдельную задачу, с результатом в виде достижения обозначенного времени выполнения.

Почему «страдания» заключено в кавычки, и что страдает на самом деле, см. раздел 6.1.

Но только не в том случае, если вы работаете с «1С» по проекту ЦКТП – тогда использование именно методики APDEX будет обязательным.

При использовании СУБД SQL Server.

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

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

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

См. предыдущую сноску.

В скобках – синонимы.

Как указывалось выше, записи вне транзакций в «1С» не бывает. Но читать вне транзакции можно, и таким образом получить «грязное» чтение.

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

Точнее ставится блокировка стабильности схемы (Sch-S), но она не влияет на блокировки транзакций, включая монопольные (X) блокировки.

Речь о неявной транзакции, инициированной средствами платформы при выполнении действий с прикладным объектом, и обработчиках, при выполнении этого действия автоматически выполняющихся. Но если просто взять и вызвать выполнение процедуры ОбработкаПроведения(), то само по себе это действие транзакцию не инициирует. Данное замечание верно для таблиц 3.6.5–3.6.8.

В синтакс-помощнике выполнение обработчика события ПередУдалением в транзакции в явном виде указано только для ДокументОбъект, для остальных видов объектов связь обработчика с транзакциями не указана.

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

Эта статья является фрагментом книги: П. С. Белоусов, А. В. Островерх «1С:Предприятие: от 8.0 к 8.1». Дата выхода книги – ноябрь 2007.

В данном предложении под высоким/низким уровнем понимается не Lock mode, а именно Lock level – объем (уровень) данных, на который накладывается блокировка. Речь идет, например, о том, что при постановке какой-то блокировки на запись таблицы на всю таблицу ставится соответствующая блокировка намерения. Благодаря этому предотвращается изменение ресурса более высокого уровня другими транзакциям таким образом, что это сделает недействительной блокировку более низкого уровня. И нет необходимости проверять блокировки в каждой строке и на каждой странице, чтобы убедиться, что транзакция может заблокировать всю таблицу, что повышает производительность.

События, происшедшие с момента выхода первого издания, показали, что и объектные блокировки могут являться предметом внимания 1С:Экспертов по технологическим вопросам, если имеет место неправильно организованная массовая работа с одними и теми же объектами. Например, массовый просмотр одних и тех же объектов через форму элемента не является ошибкой проектирования. А вот массовое закрытие этих форм кнопкой ОК, которая не только закрывает окно, но и перезаписывает объект, – это ошибка, и для форм, открывающихся только для целей просмотра, возможность записи тем или иным способом надо закрывать.

Кроме того, пессимистическая объектная блокировка может быть установлена программно методом <Объект>.Заблокировать() и снята методом <Объект>.Разблокировать(). Эти методы есть у объектных типов данных. Важно: не следует путать методы <Объект>.Заблокировать() и <БлокировкаДанных>.Заблокировать(). Первый устанавливает объектную пессимистическую блокировку, второй – транзакционную управляемую.

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

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

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

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

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

Эскалации бывают на СУБД и в менеджере управляемых блокировок. Их поведение различно. Различие состоит в том, что если в момент попытки эскалации на СУБД MS SQL кто-то другой будет держать блокировку, то эскалации не произойдет, но при этом транзакция дальше продолжит свое выполнение. Если в «1С» кто-то другой будет держать блокировку, то «эскалирующаяся» транзакция попадет в ожидание от всех, кто еще держит блокировки на этом ресурсе. Если в «1С» не получится проэскалироваться в течение N (по умолчанию 20) секунд, то транзакция получит таймаут.

Если активация флага трассировки выполняется глобально на рабочем сервере, то выполнять DBCC TRACEON (trace# [, ....n ],-1), чтобы избежать непредсказуемых последствий, рекомендуется только тогда, когда пользователи не выполняют запросов к серверу (фактически когда никто не работает). На рабочем сервере надежнее эти флаги включать, используя в командной строке параметр -T при запуске файла Sqlservr.exe.

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

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

Замечание про чтение справедливо, если не используется Read Committed Snapshot.

Необходимо помнить, что свойство БлокироватьДляИзменения реализовано с помощью установки управляемой блокировки в процессе записи набора, подробнее см. раздел 3.9.

Если вы используете уровень изоляции Read Committed Snapshot (8.3 без режима совместимости + MS SQL Server 2005 и старше), вы можете забыть про сложности с разделяемыми блокировками СУБД, они не устанавливаются.

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

Пример взят из практики, в нем нормально отрабатываются случаи с ошибкой и разрывом соединения, потому что RLS отключается только на время одного запроса на чтение. Пример, однако, не идеален, он не будет корректно работать, в частности, в ситуации, когда в транзакции ранее уже была ошибка, заключенная в скобки «Попытка – Исключение», а Запрос.Выполнить() – первое чтение после этой ошибки, которое вернет сообщение «в данной транзакции уже происходили ошибки!». Лучше, хотя и не всегда проще, использовать привилегированный режим. Этот режим как раз существует для таких случаев, но в клиент-серверном варианте при выполнении на клиенте данный метод не выполняет никаких действий, и при работе с обычным приложением потребуются дополнительные усилия по переносу кода в серверные общие модули.

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

Поведение в файловой и клиент-серверной версии должно быть одинаковым.

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

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

Также см. сноску в конце раздела 3.11.

Мы не проводили работ по полному сличению материала статьи с ИТС и фактически имеющихся в базах индексов. Но то, что мы сравнивали, позволяет говорить о том, что это точное и очень полезное описание для версий 8.2.14–8.3.5. Как мы говорили, фактический состав индексов надо уметь получать самостоятельно, но в данном материале описаны еще и закономерности, касающиеся разделителей и сплиттера, которые трудно обобщить, анализируя экспериментальные данные.

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

Кластерные индексы выделены полужирным.

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

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

Splitter – указано для регистра накопления. Для регистра бухгалтерии указано «РазделительИтогов». На практике можно убедиться, что поле добавляется в индекс, если для регистра разрешено разделение итогов в конфигураторе (и неважно, включено разделение итогов или нет).

См. выше примечание к полю Splitter для регистров накопления.

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

В MSDN описан другой способ. Графический план фактического выполнения можно получить так же, выполнив запрос в SQL Management Studio, если включить там опцию «Запрос» – «Включить действительный план выполнения». Текст запроса можно скопировать туда, например, из SQL:BatchCompleted, тогда в конец текста запроса будут включены еще и значения параметров. Этот способ содержит два важных ограничения: он прост только для простых запросов, когда нет временных таблиц, и он не выводит план в текстовом виде с важными для нас столбцами Rows и Executes (как получить из него для SQL Server 2005 количество выполнений каждого оператора, мы так и не нашли).

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

Собственно запрос начинается со слова SELECT.

В MSDN сказано (дословно): «Эта всплывающая подсказка выглядит так же, как Количество строк в реальном плане выполнения». В английской версии: «This ToolTip item displays as Number of Rows in an Actual Execution Plan». Если заранее не знать, о чем речь, смысл фразы может быть понят неоднозначно, даже в английском варианте.

Мы понимаем эту фразу так: если вы смотрите реальный (действительный) план выполнения, а не ожидаемый, то вам в поле «Ожидаемое количество строк» будет выведено то же самое, что уже есть в поле «Фактическое количество строк». А чтобы узнать, сколько их ожидалось, нужно смотреть ожидаемый план, например, через событие Showplan XML, которое, как и вообще работу с ожидаемыми планами, мы в этой книге не рассматриваем.

Здесь и далее: столбец Argument выводится в Showplan Statistics Profile, но из-за большой длины строк мы не имеем возможности приводить его в примерах. Однако, с чем идет работа, можно понять и из столбца StmtText в Showplan Statistics Profile, а в графическом плане – из поля «Объект» («Object»).

Подходящим является индекс, удовлетворяющий следующим требованиям:

1. Индекс содержит все поля, перечисленные в условии.

2. Эти поля находятся в самом начале индекса.

3. Эти поля идут подряд, то есть между ними не «вклиниваются» поля, не участвующие в условии запроса.

Об этом еще будем говорить в разделе 4.20, посвященном оптимизации запросов.

Непривычные для специалистов по «1С» термины: полусоединение – semi-join возвращает строки только одной из соединяемых таблиц, без выполнения соединения полностью.

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

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

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

Зеркалирование поддерживается только для полной (FULL) модели.

Именно бэкап журнала транзакций, а не полную резервную копию.

Не путать с одноименной моделью восстановления.

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

На AIX была развернута СУБД IBM DB2.

На HP-UX была развернута СУБД Oracle Database.

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

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

На всякий случай обращаем внимание, что, в отличие от рис. 4.7.6, где в параметрах у Записать() – структура, т. к. это код для управляемой формы, в обычной форме и при вызове с сервера в параметрах у Записать() – РежимЗаписиДокумента.Проведение.

Хороший повод отметить, что задачу написания идеальных инструкций на все времена мы перед собой не ставим. Код, даже списанный из книжки, перед применением на продуктиве надо проверять и отлаживать, а 1С:Эксперт должен уметь программировать и не должен падать в обморок при появлении сообщений об ошибке, особенно таких очевидных, как Переменная не определена (ПараметрыПриложения). Встраивание БСП вер. 2.1.1.22 не требовало объявления указанной переменной, поэтому в первом издании книги про это ничего написано не было. Работоспособность нынешнего кода проверена на БСП вер. 2.2.5.30. Выйдет БСП 2.3.1, возможно, появятся новые нюансы.

Для 8.3 каталог по умолчанию содержит в пути не «1Cv82», а «1Cv8».

Для ОС Linux настройка формирования дампов выполняется средствами ОС. Поэтому элемент <dump> игнорируется. См. статью «Создание дампов аварийного завершения программы в ОС Linux» на ИТС, а также в гл. 6 «Руководства администратора».

Ее переименование потребует дополнительных усилий, которые здесь рассматривать не будем.

Это пришлось сделать и в процессе подготовки текста. По этой причине следующие рисунки имеют в заголовке не «Создание», а «buh2».

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

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

Речь исключительно у СУБД SQL Server.

Примечание ко второму изданию: абзац по сравнению с первым изданием не изменен, что происходит на самом деле – см. раздел 3.15 «Особенности чтения в объектной модели».

Т. е. при автоматическом режиме управления блокировкой данных в «1С». В управляемом режиме такой проблемы не существует, а использование конструкции ДЛЯ ИЗМЕНЕНИЯ ни на что не влияет.

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

ВРМ (виртуальное рабочее место, «робот») – клиентское приложение, выполняющее обработку по команде Тест-центра.

Еще раз извинения читателям от автора.

Чревато потерей журнала регистрации и списка зарегистрированных баз.

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

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

Мы берем cf от 2.0.13.10, подготовленный в соответствии с инструкциями из разделов выше. Все реалии работ касаются именно этого релиза.

Текущие рекомендации для 8.2 следующие: для 64-разрядного сервера – 1 рабочий процесс, для 32-разрядного сервера – 1 рабочий процесс на 2 Гб оперативной памяти или на 100–150 пользователей.

– по 1 рабочему процессу на каждые 2 Гб оперативной памяти, необходимые для работы сервера приложений (но не от общего объема ОЗУ, т. е. ошибкой будет запускать 32 рабочих процесса только потому, что у вас на сервере 64 Гб оперативной памяти).

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

В 8.3 механизм определения количества рабочих процессов переработан; количество процессов определяется автоматически на основе количества информационных баз и количества пользователей для одного процесса, задаваемых в свойствах рабочего сервера «1С».