При нажатии "записать", даже в уже существующем элементе справочника, без обновления файла, система надолго задумывается. На других справочниках такого не замечено.
Замер производительности ясности не дает: все время (5 минут) висит на строке Справочник.ДополнительныеОтчетыИОбработки.Форма.ФормаЭлемента.Форма / Успех = Записать(ПараметрыЗаписи);

Включи оталдку на сервере и повтори замер

(1)включена

http://prntscr.com/o2sdai

Блокировки поди

Если смотреть в консоли администрирования кластера - то видно что соединение с sql не висит. Т.е. сама запись на sql проходит быстро. Но вот сервер 1с чего-то задумывается...

Так долго гонит данные с клиента на сервер чтоли.

(6) я бы сказал что наоборот, долго ждем ответа от сервера, хотя на сервере отладка шагает бодро до конца, а вот от последнего шага до возврата на клиент - "вечность"

(7) // Если смотреть в консоли администрирования кластера -

проверь там же блокировки какие-то

(8) не вижу блокировок
http://prntscr.com/o2slj8
http://prntscr.com/o2sl5q
http://prntscr.com/o2skxq

(9) есть подозрение на TimestampService, но как понять что это именно из-за него? И как исправить?

(6) тоже об этом подумал
(7) А другие серверные (контекстные) вызовы из формы проходят без тормозов?

(9) Список с блокировками - это же ниже, не там, где Соединения. Оно там пишет есть ли разделяемая блокировка или исключительная.

(12) по сеансу: http://prntscr.com/o2sura

(12) а вообще пользователей много. Есть подозрение что кто-то блокирует? Так в консоли же не написано какой именно объект заблокирован.

Сейчас вспомнил что один раз вылезла ошибка таймаута блокировки. Но только один раз.

(15) Дико извиняюсь, но у вас часто записываются ДополнительныеОтчетыИОбработки?

(14) Ну да. Не написано, но наличие большого числа сеансов может держать на чтение таблицу элементов из этого справочника.
Вот-вот (15) - это явно кто-то из пользователей блокирует таблицу своим чтением.