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

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

Мы часто слышим “у нас плохая программа, хотим вместо неё купить хорошую”. На самом деле это звучит как “мы не хотим решать проблемы, покажите нам способ, как можно ничего не делать”. Умело осваивающие бюджет “эффективные менеджеры” консолидируют десятки баз в одну, а если у них только одна база — наоборот, дробят на несколько, со словами “вот сейчас плохо, а будет хорошо”. Выяснить правду можно, если начать копать. Чем конкретно хорошая программа лучше плохой? Как детально она работает лучше, чем текущая? За счёт чего хорошая программа имеет преимущества над текущей? Погружаясь в детали, иногда можно сделать приятное открытие: значительно дешевле исправить три места в коде текущей программы, чем покупать и внедрять заново новую программу. Даже если теоретически вы правы, и новая программа действительно существенно лучше старой, никто не отменял любимого народом тихого саботажа. Какой бы замечательный не были вы с вашей программой, у вас может не получиться заставить пользователей работать в новой программе так же, как они работали в старой. Привычка — страшная сила. Кто не работал с 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»

Совмещение терминального сервера с “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  режим автоматического поиска циклических ссылок

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

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

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

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

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

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

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

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

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

Не завершаются терминальные сессии при закрытии 1С:Предприятия

У терминальных сервере под Windows Server 2003 x64, Windows Server 2008 x64, Windows Server 2008 R2 x64 может не завершаться терминальная сессия по окончанию работы с 1С. Причиной такого эффекта является является работа с принтером, которая происходит в запускаем процессе SplWOW64.exe.
server
Этот процесс автоматически завершается через некоторое время после выполнения задания печати. Задержка завершения процесса SplWOW64.exe позволяет повысить производительность повторных операций печати. Данный процесс используется для преобразований между 32-разрядными и 64-разрядными приложениями. Если данный процесс сам не завершился до закрытия «1С:Предприятия», то не происходит и закрытия терминальной сессии. Для решения проблемы необходимо уменьшить тайм-аут завершения процесса SplWOW64.exe. Для этого следует в значение системного реестра SplWOW64TimeOut установить в значение 1 (при отсутствии значения его следует создать с типом DWORD (32 бита)).
Ветка реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print
Добавить процесс SplWOW64.exe в список процессов, завершаемых при завершении терминальной сессии. Для этого следует значение системного реестра SPLWOW64.EXE установить в значение 0 (при отсутствии значения его следует создать с типом DWORD (32 бита)).
Ветка реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TerminalServer\SysProcs

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

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

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

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

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

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

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

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

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

 

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

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

 

Веб-сервисы

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

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

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

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

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

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

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

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

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

 

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

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

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

Контроль доступа к файлам для решения задач на платформе 1С:Предприятие 8

  • когда это может потребоваться
    • настройка технологического журнала
    • поиск причин ошибок доступа
    • аудит безопасности
  • инструмент — process monitor http://download.sysinternals.com/Files/ProcessMonitor.zip
  • наложение фильтров
  • анализ логов.

Вот некоторые примеры, которые выяснились с помощью этого инструмента:

  • если запускать сервер 1С из под «SYSTEM», то может потребоваться предоставление прав прав NETWORK SERVICE на каталог C:\Documents and Settings\All Users\Application Data\1C\1Cv8;
  • тоже самое для ошибки:
    «Ошибка при создании информационной базы: Ошибка доступа к файлу ‘C:\Documents and Settings\All Users\Application Data\1C\1Cv8\srvrib.lst'»;
  • профилирование Касперского для ошибки: Ошибка доступа к файлу ‘ada14b12-452d-4f85-9d71-99554e8fc6c0.71dad31c-a9fb-432d-8e31-f7c5fcb89635.new’
  • решение проблем с установкой платформы, корректировка реестра при ошибке «1608: unable to create installDriver instance, return code: -2147319784»

 

Не найдено ни одного сервера с размещенным сервисом serviceName=SessionDataService

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

Это может быть проблема нового формата журнала регистрации. Запись в него «не шустрая». В этом случае стоит попробовать старый формат записи включить.

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

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

Также можно попробовать «отложить» проблему:

Включите в настройках сервера «Менеджер под каждый сервер». И посмотрите, не падает ли сервис сеансовых данных.

 

 

 

 

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

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

По умолчанию в Windows в качестве динамических доступны порты в диапазоне 1024-5000.

 

Windows 2003

В ключе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters добавьте следующий параметр:

  •  MaxUserPort = dword: 64510

После выполнения настройки произведите перезапуск сервера.

Windows 2008 и старше

  1. В ключе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters добавьте следующие параметры:
    • MaxUserPort = dword:65534
    • MaxFreeTcbs = dword:100000
    • TcpTimedWaitDelay = dword:30
    • StrictTimeWaitSeqCheck = dword:
  2. Выполните настройку стека TCP/IP с помощью интерпретатора командной строки (cmd):
    netsh int ipv4 set dynamicport tcp start=1025 num=64510
    netsh int ipv4 set dynamicport udp start=1025 num=64510
    netsh int ipv6 set dynamicport tcp start=1025 num=64510
    netsh int ipv6 set dynamicport udp start=1025 num=64510

После выполнения настройки произведите перезагрузку сервера.

Попытка подключения к контексту сервера с неподходящей версией метаданных

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

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

В некоторых версиях платформы существует ошибка 10161275.

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

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

 

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

 

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

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

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

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

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

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

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

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

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

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

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

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

<code>CREATE EXTENSION pg_prewarm;

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Пользователи блокирующие конкретную таблицу

select a.usename, t.relname, a.current_query, mode from pg_locks l inner join pg_stat_activity a on a.procpid = l.pid inner join pg_stat_all_tables t on t.relid=l.relation where t.relname = ‘tablename’;

select relation::regclass, mode, a.usename, granted, pid from pg_locks l inner join pg_stat_activity a on a.procpid = l.pid where not mode = ‘AccessShareLock’ and relation is not null;

Статистика которую можно получить из базы данных PostgreSQL

Таблица Описание
pg_stat_activity Каждая строка показывает: процесс сервера, OID базы данных, имя базы данных, ID процесса, OID пользователя, имя пользователя, имя приложения, адрес клиента и порт,время, текущею транзакцию, текущий запрос, статус процесса, текст запроса. Колонки показывающие данные текущего запроса доступны если параметр track_activities включен. Эти колонки доступны только для суперпользователя или пользователя владельца процесса.
pg_stat_bgwriter One row only, showing cluster-wide statistics from the background writer: number of scheduled checkpoints, requested checkpoints, buffers written by checkpoints and cleaning scans, and the number of times the background writer stopped a cleaning scan because it had written too many buffers. Also includes statistics about the shared buffer pool, including buffers written by backends (that is, not by the background writer) and total buffers allocated.
pg_stat_database Одна строка: OID базы данных, имя базы данных, количество процессов подключенных к базе, кол-во транзакций примененных и отмененных, количество прочитанных блоков, количество попаданий в буфер, количество выбранных, переданных, добавленных, обновленных и удаленных строк.
pg_stat_all_tables Для каждой таблицы в текущей базе данных (включая TOAST таблицы): OID таблицы, схема и имя таблицы, количество последовательны просмотров, количество строк выбранных запросами, количество просмотров индексов (все индексы данной таблицы), количество строк выбранных через сканирование индексов, количество: пересечений строк, обновленных, удаленных строк, количество обновленных HOT строк, количество живых и мертвых строк, время последнего ручного vacuum, время последнего автоматического vacuum, время последнего ручного analyze, время последнего автоматического analyze.
pg_stat_sys_tables То же что и pg_stat_all_tables, только системные таблицы
pg_stat_user_tables То же что и pg_stat_all_tables, только пользовательские таблицы
pg_stat_all_indexes Для каждого индекса текущей базы: OID таблицы и OID, схема, имя таблица и индекса, количество просмотров индекса, количество записей возвращенных при сканировании индекса, количество живых строк таблицы полученных простым сканированием индексов используя этот индекс.
pg_stat_sys_indexes То же что и pg_stat_all_indexes, только системные таблицы
pg_stat_user_indexes То же что и pg_stat_all_indexes, только пользовательские таблицы
pg_statio_all_tables Для каждой таблицы текущей базы данных (включая TOAST таблицы), OID таблицы, схема и имя таблицы, количество блоков прочитанных с диска, количество попаданий в буфер, количество блоков прочитанных с диска и попавших в буфер для всех индексов таблицы, количество блоков прочитанных с диска и попавших в буфер that table’s auxiliary TOAST table (if any), количество блоков прочитанных с диска и попавших в буфер для индекса TOAST таблиц.
pg_statio_sys_tables То же что и pg_statio_all_tables, только системные таблицы
pg_statio_user_tables То же что и pg_statio_all_tables, только пользовательские таблицы
pg_statio_all_indexes Для каждого индекса текущей базы данных: OID таблицы и индекса, имя таблицы и индекса, количество блоков прочитанных с диска и попаданий в буфер.
pg_statio_sys_indexes То же что и pg_statio_all_indexes, только системные таблицы
pg_statio_user_indexes То же что и pg_statio_all_indexes, только пользовательские таблицы
pg_statio_all_sequences Для каждой последовательности в текущей базе данных: OID последовательности, схема и имя последовательности, количество прочитанных блоков с диска и попаданий в буфер.
pg_statio_sys_sequences То же что и pg_statio_all_sequences, только системные таблицы
pg_statio_user_sequences То же что и pg_statio_all_sequences, только пользовательские таблицы
pg_stat_user_functions For all tracked functions, function OID, schema, name, number of calls, total time, and self time. Self time is the amount of time spent in the function itself, total time includes the time spent in functions it called. Time values are in milliseconds.
pg_locks Информация о блокировках в базе

Определение размеров таблиц в базе данных PostgreSQL

SELECT tableName, pg_size_pretty(pg_total_relation_size(CAST(tablename as text))) as size
from pg_tables
where tableName not like ‘sql_%’
order by size;

или

SELECT
table_name,
pg_size_pretty(table_size) AS table_size,
pg_size_pretty(indexes_size) AS indexes_size,
pg_size_pretty(total_size) AS total_size
FROM (
SELECT
table_name,
pg_table_size(table_name) AS table_size,
pg_indexes_size(table_name) AS indexes_size,
pg_total_relation_size(table_name) AS total_size
FROM (
SELECT ('"' || table_schema || '"."' || table_name || '"') AS table_name
FROM information_schema.tables
) AS all_tables
ORDER BY total_size DESC
) AS pretty_sizes

или

Размер таблиц и индексов

SELECT
t.tablename,
indexname,
c.reltuples::integer 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 x.is_unique = 1 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 indrelid,
max(CAST(indisunique AS integer)) AS is_unique
FROM pg_index
GROUP BY indrelid) x
ON c.oid = x.indrelid
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 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 pg_relation_size(quote_ident(indexrelname)::text) desc;

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

hyper-threading_kak_working

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

ht

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

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

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

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

spyashii-regim

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

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

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

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

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

ib-settings

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SELECT COUNT(*) FROM DBSchema

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

Страница не найдена

404-11

4 апреля — Международный день интернета и День веб-мастера.

Второй праздник отмечается интернет-разработчиками исключительно из-за красивой даты 4.04, напоминающей об «Ошибке 404» — пожалуй, самой известной ошибке в интернете.

 

Объединение данных двух периодических регистров

http://forum.infostart.ru/forum26/topic111009/

Есть два периодических регистра. Первый содержит количества на дату (РегистрКоличество), а второй — состояния на дату (РегистрСостояние). Даты двух регистров независимы друг от друга. Требуется запросом построить третий «регистр», являющийся объединением первых двух, чтобы показывались соответствующие друг другу даты, количества и состояния.

Вот короткое решение с использованием коррелированных запросов (ахтунг!):
ВЫБРАТЬ
ВЫБОР
КОГДА ТаблицаКоличества.Дата > ТаблицаСостояний.Дата
ТОГДА ТаблицаКоличества.Дата
ИНАЧЕ ТаблицаСостояний.Дата
КОНЕЦ КАК Дата,
ТаблицаКоличества.Количество КАК Количество,
ТаблицаСостояний.Состояние КАК Состояние
ИЗ
ТаблицаКоличества КАК ТаблицаКоличества
ВНУТРЕННЕЕ СОЕДИНЕНИЕ ТаблицаСостояний КАК ТаблицаСостояний
ПО (ТаблицаСостояний.Дата В
(ВЫБРАТЬ
МАКСИМУМ(ТаблицаСостояний.Дата)
ИЗ
ТаблицаСостояний КАК ТаблицаСостояний
ГДЕ
ТаблицаСостояний.Дата <= ТаблицаКоличества.Дата)
ИЛИ ТаблицаКоличества.Дата В
(ВЫБРАТЬ
МАКСИМУМ(ТаблицаКоличества.Дата)
ИЗ
ТаблицаКоличества КАК ТаблицаКоличества
ГДЕ
ТаблицаКоличества.Дата <= ТаблицаСостояний.Дата))
 

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

 

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

Объединение непересекающихся интервалов в запросе

http://www.forum.mista.ru/topic.php?id=748551

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

 НачалоПериода  КонецПериода  Гость
1.01.2001 2.01.2001  Росс Геллер
3.01.2001 4.01.2001  Росс Геллер
7.01.2001 8.01.2001 Росс Геллер

должно получиться

 НачалоПериода  КонецПериода  Гость
1.01.2001 4.01.2001  Росс Геллер
7.01.2001 8.01.2001  Росс Геллер

Это делает следующий запрос, являющийся развитием идей решения задачи 14 из предыдущей статьи на случай интервалов:
ВЫБРАТЬ
Дано.НачалоПериода,
Дано.КонецПериода,
Дано.Гостиница,
Дано.ФизическоеЛицо,
СУММА(РАЗНОСТЬДАТ(Слева.НачалоПериода, Слева.КонецПериода, ДЕНЬ) + 1) КАК Интеграл
ПОМЕСТИТЬ ДаноПлюс
ИЗ
Дано КАК Дано
ВНУТРЕННЕЕ СОЕДИНЕНИЕ Дано КАК Слева
ПО (Слева.НачалоПериода <= Дано.НачалоПериода)
СГРУППИРОВАТЬ ПО
Дано.НачалоПериода,
Дано.КонецПериода,
Дано.Гостиница,
Дано.ФизическоеЛицо
;
ВЫБРАТЬ
МИНИМУМ(Дано.НачалоПериода) КАК НачалоПериода,
МАКСИМУМ(Дано.КонецПериода) КАК КонецПериода,
Дано.Гостиница,
Дано.ФизическоеЛицо
ИЗ
ДаноПлюс КАК Дано
СГРУППИРОВАТЬ ПО
ДОБАВИТЬКДАТЕ(Дано.КонецПериода, ДЕНЬ, Дано.Интеграл),
Дано.Гостиница,
Дано.ФизическоеЛицо

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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