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

Работал себе сервер, работал.
Обслуживал 4 базы.
1) УТ 10.3 слегка допиленная
2) БП 3.0 без допилок
3) УТ 10.3 - для разработки
4) БП 3.0 - тренировачная для бухгалтеров без допилок

В один момент сервер 1С стал тупить.
Конкретно при работе в УТ.

Запуск сессии.
проведение первого документа в свежей сессии - 25 секунд!!!!
повторное проведение его же - около 0,8 сек

Проведение другого документа - около 3,1 секунд. Повторное проведение его же 0,4 - 0,8 сек.

Первое открытие формы документа - около 3 сек. Повторное открытие формы документа (не обязательно этого же) - чуть менее секунды.

Модуль проведения (записи в регистры) не модифицирован.
ПередЗаписью есть некоторые доработки, но по замерам производительности, они не всаживают.
А всаживает типовой код.
Как пример: http://prntscr.com/grwsy4

Реиндексация, пересчет итогов и прочее проводится по расписанию.
ТиИ делал.

Что еще можно посмотреть, что может влиять на скорость?

up:

Пересадил базу временно на другой серв, в роли сервера БД MS SQL - ситуация аналогичная.

Делаю вывод, что проблема в самой БД.
Попробую выгрузить в файловую и прогнать Chdbfl

Пока делается проверка:
Размер базы в dt до 400 Mb
Провожу тесты сейчас (кроме меня грузит сервер 1 бух, больше никого)

Загрузка сервера БД (+1С сервер): http://prntscr.com/grwy5e

виртуальный сервер БД под например дебианом?

>Реиндексация, пересчет итогов и прочее проводится по расписанию.
ТиИ делал.

ты не на форуме телепатов, поэтому уж разъясни в "и прочее" входит vacuum analize?

и да, что там с дисками и ты уверен, что твой postgre.conf анстроен адекватно?

(3)
>виртуальный сервер БД под например дебианом?
нет, реальный серв под дебианом

> входит vacuum analize?
конечно входит

> и да, что там с дисками
массив зеркало под систему, софтовый
ssd под бд

> postgre.conf анстроен адекватно?
вроде как...

chdbfl ничего не обнаружил

>> и да, что там с дисками
массив зеркало под систему, софтовый
ssd под бд

длина очереди какова?

если выгрузить - загрузить скорость выполнения нормализуется?

в смысле через dt

только бэкап не забудь сделать

(6) под это мониторинга с логированием пока не настроил.. Статистика не собрана :(
В момент проведения документа картина такая: http://prntscr.com/grxj9x

(7) неа, ситуация не меняется.
Пробовал и перезагружать конфу и в новую БД засовывать выгрузку, все без толку

В развернутом виде (CD) база под 4 гига... Фигасе из 400 Мб разархивировалось

ну тогда собирать инфу логами ТЖ и через замер производительности.

>ПередЗаписью есть некоторые доработки,

а там никаких подписок не навешано? они ведь в замер не попадут!

(11) эээ.. навешано..
То, что подписки не попадают в замер для меня новость..

(0) дефрагментацию дисков смотрел?

(10) это норм, сжатая база не более 10 процентов от исходной

(10) Запусти atop и смотри утилизацию дисков.

(11) подписки отрабатывают за 0.2 сек, не они вешают
(13) дефрагментация? для Ext3?

(15)http://prntscr.com/gs1atu
куда тут смотреть?

Судя по скрину из (0) что то не так со структурой конфы. Я так понимаю очистиь все кэши в купе с реструктуризацией пробовал ?

(16) В первой колонке DSK, в третьей - busy в процентах.
>>Проведение другого документа - около 3,1 секунд. Повторное проведение его же 0,4 - 0,8 сек.
Это сильно критично? Если бы оно по полторы минуты занимало...

(17) Кеш чистил, базу в dt вгружал и на другой вообще сервак загружал. Положительного эффекта не дало.
Реструктуризацию не пробовал. Сейчас попробую изменить что-нибудь в конфе и пересохранить. Пока в базе никого..

(18) По работе пользователей не особо. По тому, что "с базой что-то не так" мне лично критично как минимум разобраться что происходит.
Хотя... при перепроведении доков пользователи жалуются на "тупняки адинэс"

(19) Тупняк во всех базах или в какой-то конкретной?

(20) только в УТ

сделал реструктуризацию... субъективно вроде бы как быстрее стала немного работать.

Жду пользователей протестить под полной нагрузкой и собрать "мнения"

(21) у тебя конкретные симптомы описаны в (0). не можешь, что ли, еще раз с секундомером "провести первого документа в свежей сессии" ?

(22) могу. Просто сейчас свертка базы идет и выгрузка 2 баз в dt

Боюсь результаты под такого рода нагрузкой могут смазаться..

(23) Ну может у тебя и тупняки были на фоне какой-нить нагрузки?

(23) ясно.. ну, подождем )

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

(24) неа, специально проверял досконально все активные сеансы.

(26) включена.....

(27) Тогда пробуй отключать. Если поможет - надо делать две службы сервера 1с - одну рабочую, вторую - для разработки/отладки.

(24)(25)
Ну.. проведение документа при активной нагрузке на сервере в 12 сеансов - чуть более секунды. Уже приемлемо.

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

(0) План электропитания какой?

(30) не настраивал, по дефолту "из коробки"

(31) По дефолту там вроде оптимизированный, нужно поставить "Высокая производительность", в биосе и в винде.

(32) в роли серверной ОС - Debian :)

(33) Ты же говоришь что на MS SQL то же самое.

(34) конкретно с этой базой да, остальные хорошо работают
План там - конечно максимальная производительность

(35) Так хорошо работают или "Пересадил базу временно на другой серв, в роли сервера БД MS SQL - ситуация аналогичная. "?

(36) Все базы кроме проблемной на том сервере хорошо работают

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

А не создал ли кто-нибудь случайно документик какой-нибудь далёкой-предалёкой будущей датой - например 3017 или 2071 годом?

(38) неа

(0) Такая же фигня при программном проведении документа. При создании реализации на основании заказа клиента документ создается 25-100 сек в зависимости от количества строк в будущей реализации
В ТЖ творится ад, выполняется 20 тыс запросов вида (по регистру заказы клиентов)
UPDATE AccumRgT16283 SET Fld16279 = Fld16279 + -1, Fld16280 = Fld16280 + -1, Fld16281 = Fld16281 + -11374.35 WHERE Period = DATETIME(2017,8,1) AND и тд по измерениям условия
где DATETIME(хххх,х,1) меняется от (1,1,1) и до текущей
пока не разобрался в чем дело

Так проблема ушла или нет после ресруктуризации?