Есть проблема с БД: ни с того, ни с сего на прошлой неделе работа с БД стала проходить крайне долго, то, что выполнялось раньше примерно за 1 секунду, стало выполняться примерно за 15-20 секунд. Что любопытно, глючить в тот момент стал даже поиск по журналу, указываешь номер документа, жмёшь "Найти" и поиск вместо 1 секунды зависает на минуты, при этом сам процесс sqlserver.exe что-то усиленно потребляет на процессоре сервера.
Эта ситуация была на прошлой неделе, я пробовал изменять ТА, удалять помеченные со сжатием БД, прогон всех заданий SQL (очистка истории, обновление статистики + реиндексация, реорганизация) - ничего не помогло.
По итогу перезагрузил сам сервер, и всё резко пришло в норму.
Сегодня история повторилась, и, как и ранее, помог только полный ресет сервера с установленным SQL.
Понимаю, что информация слишком общая, но ранее такого никогда не было, помогите хотя бы с направлением, куда копать.
Спасибо.

Разваливается сервак, продолжайте наблюдения

В момент тупняка проверил монитор ресурсов сервера, а там следующая картина:
https://ibb.co/gzbVYLM

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

(1)
Коллеги, давайте или по теме, или никак, спасибо.

(0) сервак перезагружали? Может там закешилось что-нить, хотя я хз как там у клюшек. Жесткие диски проверяли на ошибки? Может уже сыпаться начали

(4)
Только перезагрузка и помогает.
Жёсткие без ошибок, там установлен RAID отдельно на MDF, отдельно на LDF, состояние RAID в порядке, постоянные CheckConsistency ошибок не выдают.

(5) я так понимаю, что перезагрузка временно помогает, потом так же зависать начинает?

(6)
да, с прошлого зависания прошла неделя, причём всю эту неделю всё работало идеально, а в одно утро резко те же глюки

(2) "FETCH_API_CURSOR 1С 7.7" в поиск, выдаст две темы
Далее сам думай, но проблема в конфе

SQL2008 + 1c77, 100% загрузка CPU сервера пока не зайдет админ в 1С

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

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

(10) это неважно
проблема кривизны запросов для ВыбратьПодчиненныеДокументы когда индекс на дату не срабатывает и по сути шерстит все
смотри там например 37 в (9)

"2005 и 2008 SQL при некотором стечении обстоятельств выбирают неправильный план выполнения запроса при поиске подчиненных документов.
в 2000 такой проблемы нет"

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

(11)
это когда всё работает быстро:
https://ibb.co/JtqSxvX
https://ibb.co/xj5jjnZ
https://ibb.co/2KT3tZm

(12)
ну смотрите: в прошлый раз, когда была проблема, я полностью всех выгнал из 1с, зашёл сам и попробовал просто поиск по журналу по введённому номеру документа, по итогу поиск завис на минуты, хотя по кнопке "Найти" обычно выполнялся за секунду, и в данном случае не было никаких "ВыбратьПодчиненныеДокументы"

(0) как вариант "ленивого", но эффективного мониторинга и поиска причин тормозов - ставишь свежую версию MS SQL Server Management Studio. Затем на своем сервере клацаешь правой мышкой "отчеты-стандартные отчеты - панель мониторинга производительности". Там все кликабельно, клацаешь, много думаешь....

И ещё, может как-то вышеназванная проблема быть связана с тем, что иногда (раз в недели 2-3) 1с у одного из пользователей вылетает с ошибкой неверного состояния курсора ?

(17)
Вашего отчёта нет в списке, есть такие:
https://ibb.co/wBDmw9p

Для 7.7 лучше использовать штатно поддерживаемый ей sql2000. А более новые в вашем случае, скорее всего, со временем работы набирают статистику, на основании которой принимают неверное решение о неиспользовании индексов при отборе. Старая версия более тупая и не умничает без необходимости, всегда используя индексы, если они есть. Думаю так.

(19) эта утилита появилась, по моему, с 18 версии SMS. В более ранних версиях ее нужно было добавлять руками с небольшой доработкой напильником.

(20)
именно такой режим и используется, sql2000

(22) Я не о режиме совместимости базы, а о версии сервера.

(23)
вряд ли проблема именно в SQL 2008 Ent R2, ведь много лет он работал на нём без каких-либо проблем

(24) может какой-нибудь регламент у вас косячный, который утечку памяти вызывает. В итоге через недельку сервак уже загибается. Что-то дорабатывали в конфе перед началом тормозов?

(25)
уточню

(25)
уточнил, ничего не менялось

(0) поднимите backup ,годичной давности, когда все работало быстро

(28)
после ресета сервера всё работает быстро и сейчас
да и какой смысл в бэкапе, когда ежедневно в БД вбиваются тысячи документов ?

Что может быть проще - послушать (12) и сделать глобальный поиск по конфигурации (ну и папке внешних отчетов):

ВыбратьПодчиненныеДокументы(,,

с заменой на

ВыбратьПодчиненныеДокументы('01.01.1980','31.12.2037'

Ну или просто просмотреть ВыбратьПодчиненныеДокументы( на наличие конечной даты и проставить, если её нету, '31.12.2037'.

И посмотреть останутся ли подвисания.

"ВыбратьПодчиненныеДокументы" используется везде только с датами, иначе на этой версии SQL не работает.

И снова воскресенье, и проблема повторяется один в один:
https://ibb.co/S7NS8kF
https://ibb.co/jgtKysC
https://ibb.co/BC9tHcp
https://ibb.co/MZNsxpd

Вся память потребляется SQL, но такое и ранее было постоянно и никогда не приводило к замедлению работы SQL-сервера.
https://ibb.co/yRsqNZQ

И снова в ночь с субботы на воскресенье было выполнение реорганизации на сервере.
https://ibb.co/4FnwsDz

Уже и не знаю, совпадение ли это, что после ночи реорганизации всё начинает жёстко тупить или нет.

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

Поставил Викторией прогон дисков с БД, пока читает, но скорость подозрительно низкая, порядка 27-28 МБ/сек, и это для SAS-дисков с 15000 rpm.

Монитор ресурсов рапортует, что это всего лишь 13% активного времени диска.

(22) если используешь 80 для базы можно считать что оптимизатор запросов практически не работает
переделывай на 100
(0) очисти журнал регистраций - при размере больше 2 гб происходит subj

(30 31) c sql2005  это исправлено

(36)
Выше 80 не работает 7.7 в связке с SQL 2008 Ent R2, это уже проверялось и неоднократно экспериментировалось в момент установки данного сервера много лет назад.

(36)
Журнал регистраций это Вы имеете ввиду журнал Просмотра событий 1с ?

(36)
Если Вы имеется ввиду именно Просмотр событий 1с, то в данный момент ситуация следующая:
https://ibb.co/Pm2MSDh

(38) Как проявляется? Я пару месяцев назад v77 на mssql2016 завел без проблем.

(41)
1с даже не запускалась, сразу выбрасывая ошибку.
На mssql2016 БД у Вас была в каком режиме ?

Всё, приплыли, теперь уже не помогла даже перезагрузка сервера с установленным SQL, глюки остаются.
Если попытаться сделать что-то в 1с, процесс SqlServr.exe грузит 13% ЦП, что любопытно это как раз 100% загрузки одного ядра ЦП (8 ядер ЦП, загрузка одного ядра на 100% это как раз 13% общей загрузки ЦП).

(43) битый диск

(43) Я для кого делал "Секретный релиз платформы v77.27.7"? Качай, ставь, наслаждайся.

(45)
Если не ошибаюсь, изначально он и был установлен.

Пока попробовал и работу одного юзверя, и работу 2-х параллельно - ничего не помогает.
Запустил вручную задание реорганизации из SQL агента, посмотрю за результатом.

Поменяй диски на SSD

(46) Если и был установлен, то версия самая первая v77.27.1 -> v77.27.7

(49)
Можете подсказать, где его можно скачать ?
Или если не сложно, сбросьте ссылку на e-mail из моего профиля.

(48)
Поднимался уже такой вопрос, SSD не встанут в корзину данного сервера, увы.

(49)
Проверил BkEnd на сервере, стоит 1.0.0.7, похоже как раз Ваша, последняя версия.

(47)
Реорганизация закончилась, ничего не помогло.

(34)
Запустил проверку Викторией уже второго набора дисков:
что любопытно, скорость теста набора дисков с LDF-файлами была подозрительно низкая, порядка 27-28 МБ/сек,
для набора дисков с MDF-файлами - порядка 170 МБ/сек,
а там, и там SAS-диски на 15000 rpm.

Проверка Викторией набора дисков с MDF-файлами завершилась, проблем с дисками нет, этот вариант можно отбросить.

Прогнал ещё на всякий случай SQL-сервер портабельным антивирем CureIt - чисто.

Попробовал создать отдельную БД на этом же сервере в режиме совместимости 100 и восстановил в неё копию рабочей базы уже с глюками.
Как ни странно, 1с запустилась без ошибок и работала на этом SQL очень быстро.
Ничего не понимаю ...

Возможно БД работает быстро только потому, что это было восстановлении из копии с созданием новых файлов, а не из-за режима совместимости, уже и не знаю.

(57)
Хм, создавалась она в режиме SQL 2008, а в окне свойств базы теперь показывает SQL 2000.

(59)
Что интересно, все 4 системные базы данных в режиме SQL 2008.

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

Дело в том, что Смарт отдельного диска он считать не может, пока диски находятся в RAID-массиве.

Я ничего не понимаю, но сервер с утра стал работать снова с нормальной скоростью.
Всё, что поменялось с ночи - это я создал на нём ещё 1 тестовую БД и загрузил в неё копию рабочей базы, а также ночью на рабочей базе прогналось задание "Обновление статистики + реиндексация". Но само это задание ежедневное, оно выполнялось и в предыдущую ночь.

У процесса SqlServ загрузка с постоянных 13% (100% для одного ядра) стала плавающей от 3 до 20 % и судя по графику, нагрузка стала распределяться на разные ядра процессора, а не на одно, как было вчера.

(62) Ну так у вас оснасти над рейдом нет что ли? В от производителя контролера обычно есть все. Можно конкретный диск и посмотреть и проверить и смарт прочитать.

(65)
Есть RAID Web Console, но там нет возможности просмотра Смарта отдельных дисков, а Виктория Смарт отдельного диска не видит, а при выбранном RAID-диске пишет, что данное устройство не поддерживает технологию Смарт.

В итоге,вы викторинй проверялм raid-мкссив,что смысла не имеет.

(67)
Ну почему же ?
При проверке Викторией массива я так понимаю он проверял параллельное чтение из обоих дисков пары, разве нет ?

(68) Виктория понятия не имеет о структуре массива, она видит блочное дисковое устройство.

(69)
Ну раз так, тогда проверить отдельный диск можно будет только после удаления RAID.

Но только как всё это связано с тем, что через ночь сервер стал работать в обычном режиме ?

Пока грешу именно на ночные задания SQL-агента.

(66) Покопайся в ней. Должна быть оснастка для чтения SMART.

(34) Пора на SSD переходить

А рейд контроллер с BBU?
Бывает что контроллер устраивает батарейке тренировку и при этом отключает кеширование записи.
Смотреть надо в логи рейда спец утилитой.

(73)
Погуглил по Intel RAID Web Console 2, на аналогичном нашему контроллере Intel RAID Controller RS2BL080 люди Смарт отдельного диска получить не могут, советуют CrystalDiskInfo, но она тоже не дружит с RS2BL080.

(74)
См. (51)

(75)
Да, контроллер с BBU, по ней ситуация следующая:
https://ibb.co/YWh8hX1

Цикл обучения стартует сам RAID-контроллер 1 раз в месяц, последний раз это было 29.06, следующий 29.07, последний глюк был с 23.07 на 24.07, в это время никаких обучений BBU не было.

По поводу режима совместимости:
попробовал в тестовую БД развернуть рабочую информацию, выставить этой БД режим SQL 2008,
после этого в конфигуратор зайти даёт, схранить конфигурацию даёт,
а при входе в 1с - серая пелена, а при клике в неё сразу https://ibb.co/LJCybkQ
вернул режим на 80, и 1с стала запускаться корректно.

Возможно это как-то связано с DLL, загружаемыми у нас ПриНачалеРаботыСистемы:
1CPP.dll
Formex.dll
TurboMD.dll
RWidjets.dll
vk_Hook1C.dll
v7plus.dll
SpreadSheet.dll
Scaner1C.dll

Надо использовать секретный релиз

(80)
Он и стоит, версия 1.0.0.7.

С этим тебе определенно надо разобраться. Он должен работать с БД в нативном режиме сервера

(82)
Закомментировал подключение абсолютно всех сторонних DLL в ПриНачалеРаботыСистемы(), но 1с всё равно падает уже на старте с БД в нативном режиме сервера.

(83) Ну может падает т.к. ты "Закомментировал подключение абсолютно всех сторонних DLL"?

(84)
Раскомментарил все сторонние DLL, и 1с упала в процедуре ПриНачалеРаботыСистемы() на вполне безобидном коде:

Спр = СоздатьОбъект("Справочник.Пользователи");
Если Спр.НайтиПоКоду(ИмяПользователя()) = 0  Тогда
    Спр.Новый();
    Спр.Код = ИмяПользователя();
    Спр.Наименование = ПолноеИмяПользователя();
    Спр.Записать();
ИначеЕсли СокрЛП(Спр.Наименование) <> ПолноеИмяПользователя() Тогда
    Спр.Наименование = ПолноеИмяПользователя();
    Спр.Записать();
КонецЕсли;
глПользователь = Спр.ТекущийЭлемент();

На обычной программной записи в справочник.

С каким сообщением падает?

(85) какое там ИмяПользователя() на котором падает?

(87)
https://ibb.co/LJCybkQ

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

(0)
всё не читал. Какой там скуль у тебя ? Если >2000 как лечил, какой режим совместимости в скуле стоит (надеюсь, его хотя бы не понижал) ?

ЗЫ: и да, ромиковское изделие, сразу в костёр

(89) после перевода 80->100 нужно обновить dds
Не просто сохранить конфу, а потрогать что-нить приводящее к Статус: БД*

(57) (59) режим 80 у тебя в бекапе.
Не важно с каким режимом база создана, если поверх накатить бекап с 80, то будет 80.

Нужно так:
восстановить из бекапа
установить режим 100
зайти в конфиг, реструктуризировать

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

(85) а нафига если спр. существует переписывать ему наименование? я бы еще понял если бы там была периодика код. менеджер наименование Вася, Петя и т.д. А так там всегда будет храниться последний пользователь и отделить косяки от предыдущего не реально.

(91)
SQL 2008 Ent R2
в БД режим SQL 2000, на режиме SQL 2008 1с падает

(92)
какое именно ?

(93) (94)
Обновил dds, не помогло, 1с всё так же падает сразу при запуске.

(95)
Нет, сервак без выхода во внешний мир.
Да и сеть, судя по монитору, нагружена по минимуму, серваки между собой общаются по 1Гбит.

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

(96)
Сам факт, что падает именно Спр.Записать();

(97) 1с как дружил с 2008 ? надеюсь, никакие библиотеки самого скуля не подменял/патчил, а поставил только солюшен 7 ?
ЗЫ:
1.выкинь ромиковское изделие
2. установи чистый скуль и ничего в нём не меняй
3. установи солюшен 7
4 разверни свой бэкап или приатач базу, подыми в ней уровень совместимости до максимума
5.сделай реструктуризацию в пофигураторе.
6. наслаждайся, кушай печеньки

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

(103) большой плюс

(104) вот и я тоже пытался ТС намекнуть, что каталог ИБ на 7.7 все равно болтается в файловом режиме и многопользовательском доступе, что и являлось причиной появления тормозов изначально. Но он этих намеков или не заметил или проигнорил, начал оптимизировать и дооптимизировался, судя по свежим записям в этом бложике

(102) А в справочнике Пользователи тип значения кода, число или строка? Длина кода какая? Спр.Записать() случайно не в Попытке делается?
Может элементарно справочник закончился...

(107) если бы так было, то прога не крашилась бы, выдавало бы ошибку на записи.
а ТС говорит именно о краше.

Мне кажется подобный тупняк когда то победил - удалив файлы настроек из каталога пользователя. Но у меня была файловая база

(109) в том и же и фишка у 7.7, что файлы эти есть, даже если база не файловая.

(109) кстати, да. стоит попробовать! удалить файлы cfg

(103)
Что в Вашем понимании "Ромиковское изделие" ?
Делала всё именно так по пунктам, ничего не помогло, 1с так и падает на старте.

(104)
OrdNoChk нет в каталоге ИБ.

(107)
Строка.50
Не в попытке.

(109)
Какого именно пользователя, их очень много.

(110)
О каких именно файлах идёт речь, уточните пожалуйста.

В общем на сегодня ситуация такая:
1с снова благополучно легла как по часам в ночь с субботы на воскресенье, документы снова обрабатывались крайне заторможенно, и это притом, что задание "Реорганизация" в эту ночь не выполнялось (грешил ранее на него, т.к. именно оно выполняется раз в неделю именно в эту ночь).
На SQL-сервере как и ранее процесс SQlServ кушал 100% одного ядра и ровно 13% общей нагрузки процессора, нагрузка не менялась ни в большую, ни в меньшую сторону.
Вчера всех выгнал из 1с и попробовал выполнить "Реорганизацию" вручную - ничего не поменялось.
Далее попробовал вручную прогнать задание "Обновление статистики + реиндексация", хотя оно и так выполнялось в ночь с субботы на воскресенье.
Крутанулось оно за 1:03, хотя обычно занимало примерно 1:30 по времени.
Запустил 1с, попробовал поиск по журналу - всё работает моментально.
Запустил обработку документов - всё также стало работать моментально.
НО, прошла ещё одна ночь с воскресенья на понедельник и ситуация повторились, сегодня после ночного выполнения задания "Обновление статистики + реиндексация" - аналогичные тормоза.

Получается, что задание "Обновление статистики + реиндексация" приводит к этим тормозам, но оно же и устраняет их при следующем своём выполнении.

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

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

Это список выполнявшихся заданий для общей картины:
https://ibb.co/MNmc0TG

+(119) "Перестроение индекса" и "Реорганизация индекса"

(121) Смотреть нужно в "Управление / Планы обслуживания".

(123)
https://ibb.co/yyFDNWh
https://ibb.co/Khk1zSn

Конкретно по реиндексации:
https://ibb.co/kcsy2Sc

(112) vk_Hook1C.dll

(124) Еженедельное же у тебя проблемы вызывает, ну вот значит реорганизация индекса - это оно тяжелое и есть.

А вообще, переходите на 8.х - там этой проблемы не будет. :)

(127)
В (117) я писал: задание "Реорганизация" в эту ночь не выполнялось (грешил ранее на него, т.к. именно оно выполняется раз в неделю именно в эту ночь).

(126)
Закомментарил загрузку vk_Hook1C.dll в ПриНачалеРаботыСистемы(), и 1с крашится перестала.
Это уже хоть что-то.

Теперь вопрос:
1.выкинь ромиковское изделие
2. установи чистый скуль и ничего в нём не меняй
3. установи солюшен 7
4 разверни свой бэкап или приатач базу, подыми в ней уровень совместимости до максимума
5.сделай реструктуризацию в пофигураторе.
6. наслаждайся, кушай печеньки
7. выкинуть всякие ордночек из каталога иб и прочий непотребный мусор для кодовой странички.

Данная инструкция может что-то повлечь за собой, кроме краша 1с ?
Может что-то нужно учесть предварительно, чтобы не посыпалась уже сама БД или это безопасная операция ?

(128) там просто всё будет неторопливо работать ;-)

У меня есть одна база на 7.7 крутится на Win2012 + SQL 2008R2 , регламент вот такой https://s.mail.ru/JY7c/uyg6FgKGh , подключение к базе через сеть, машины начиная от XP до Win 10, база 70 гигов. Из всех перечисленных советов, я считаю самый правильны развернуть тестовый комп + поднять бэкап и проверить.

А логи выполнения заданий SQL не смотрели?
Может задание выполняется несколько суток - вот и проблемы.

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

По поводу SSD.

Покупаете PCI-E NVME рейзер (например Supermicro AOC-SLG2-2TM2, искать нужно попроще без рейда и большим кол-вом портов, новые все с драйверами минимум под Win2012, на старые обычные драйвера не нужны) 2-х портовый, в биосе ставим режим работы PCI-E 4x4x4x4 (или 8x8)
Покупаем 2 NVME SSD Samsung PM983 объединяем их в софт рейд виндой
(можно взять 1 и настроить архивы почаще делать)
Ставим готовый отредактированный драйвер или берем готовый

Переносим все темпы, сам sql и его базы на новые SSD

Прирост конечно будет не очень ощутимым из-за того, что PCI-E старой версии не даст нужной пропускной способности.

По цене можно уложиться в 100-200 тысяч.

(133) https://winraid.level1techs.com/t/recommended-ahci-raid-and-nvme-drivers/28310/2
Ссылка на драйвера

(133) Да 1 момент, загрузиться с таких винчестеров не удастся.
Только под данные.

Загрузочный оставляете старые винты.

Даже нашел их еще в продаже
https://www.nix.ru/autocatalog/ssd_samsung/SSD-384-Tb-M2-22110-M-Samsung-MZ1LB3T8HMLA-OEM_448573.html
https://www.oldi.ru/catalog/element/01081802/

Вот такой-бы объема в 2 раза меньше, они подешевле.
Может где поискать, завалялись еще.

(133)
Самое долгое задание выполняется за полтора часа:
https://imgbb.com/MNmc0TG

(133)
Так если прирост будет не ощутимым, то смысл перехода на SSD ?
По логу Монитора ресурсов диски SQL-сервера по минимуму.

(138) Ну имеется ввиду по сравнению с тем, что могут эти SSD

А так 250-300 МБ/с будет, т.е. прирост в 2 раза от текущего.

Мне кажется смысла нет, тут узкое место совсем не диски.

На дисках с MDF скорость чтения и так в районе 200 МБ/с была.

(141) А будет такая скорость записи.

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

(141) Меня и других смущает 25-30 МБ на 1 вашем рейде, при этом на втором 100+
Явно что-то не так с дисковой.

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

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

(144)
25-30 МБ на дисках с LDF, поэтому думаю это не критично.

Купить комп на хорошем проце+NVME не дороже 100к выйдет.
Все на него перенести за 1 день можно.
Только винду придется минимум 2012 ставить.

Или взять аренду на месяц помощнее - еще дешевле получится.

К тому же, ну какая вероятность проблем с дисками конкретно в данном случае ?
Если бы диски были проблемные, то работа бы глючила и в течение дня, и в рабочие дни, а этого нет, всё происходит чётко на выходные, а точнее говоря после 7 ежедневных запусков задания "Обновление статистики + реиндексация".
Ну вот скажите, причём тут диски ?

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

(148)
По аккумулятору уже поднимали вопрос выше:
https://ibb.co/YWh8hX1

(137) зачем реиндекс пихать в с обновлением статистики ? Делайте реиндекс раз в неделю. незачем его каждый день делать

И выгрузка БД - это поди фулл бэкап и база в симпл у вас, да ?

Ёпрст, подскажите по (130) пожалуйста.

(150)
Как я и писал в (120), регламенты обслуживания создавались не мной, но по факту они проработали тучу лет вот в таком виде на сервере и никогда не вызывали проблем.

(151)
Да, это фулбэкап 2 раза в сутки, днём и ночью.

(152) что там особо не ясно на счет инструкции ? Это минимум, который надо сделать. Ромиксовское изделие вы выкинули, ужо хорошо.
(154) ну..это же п..ц :))

База, в симпл стоит, да ?

(155)
Насчёт инструкции хотелось бы понять:
Данная инструкция может что-то повлечь за собой, кроме краша 1с ?
Может что-то нужно учесть предварительно, чтобы не посыпалась уже сама БД или это безопасная операция ?

(155)
Поясните пожалуйста, в чём проблема фулбэкапа ?
С ним никогда не было замечено никаких проблем.

(158) зачем его так часто делать? Есть же диф

(156)
На сегодня вот такая ситуация:
https://ibb.co/yXdvBNT
https://ibb.co/dkLr0MY

(159)
Да как-то привыкли уже за все годы.
Да и восстановление так гораздо проще, 1 файл подсунул и поднял базу.

По итогу сегодня не дождался ночи, крутанул "Обновление статистики + реиндексация" прямо посреди дня при работающих пользователях, пока 1с вернулась в свой обычный режим.

(150)
Реиндекс Вы предлагаете вынести в еженедельное задание "Реорганизации" ?

(163) как минимум да.

(160) Покажи картинку с файлы этой базы

На счет модели восстановления, лучше выставить в фулл, + 3 задания в планировщике - фулл бэкап раз в неделю, дифф раз в день (исключая день фулл бэкапа), архивирование лога раз в 10-15 минут + шринк лога в этом же задании.
Итого имеешь базу за любую мс на любой день.

(157) какой еще "краш" ?

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

Ну и скуль, можно хоть до 2019 поднять при желании

(164)
Вкладка "Файлы":
https://ibb.co/DQxvWWn

(168) ну хоть не в % приращение, и то хорошо. Но лучше выставить по 512 и мдф и лдф..и в темпе тоже

В свойствах самого сервера, максимальная степень параллелизма какая стоит ?

+ в процессорах, какое максимальное число потоков выставлено ?
+память как ограничена ? И сколько памяти физически на этом сервере ?

ТС, ты базу то перевел в нативный режим сервера иди еще нет?

(172) неа..боится краша)

(169)
https://ibb.co/Rb3S3W1
https://ibb.co/H4849Qg

(170)
https://ibb.co/YB2p65x
Но это не особо помогает, в течение дня бывают нередко сообщения о том, что "Транзакция вызвала взаимоблокировку и стала жертвой блокировки ...".

(171)
https://ibb.co/TBTFXWN
https://ibb.co/Dr0jmGQ
Физически памяти - 32 ГБ.

(172)
Пока нет, выберу какие-нибудь выходные поспокойнее для этого.

(173)
Вам-то смешно, а я опасаюсь последствий таких кардинальных решений.

(164)
А как лучше сделать: сначала реорганизация индекса, а потом перестроение или наоборот ?
Или вообще не принципиально ?

(176) максимальное число рабочих потоков выстави 2048. И попробуй убрать галку с приоритета скуля.

Темпдб, желательно на другой диск..ну да ладно

(180)
https://ibb.co/StQg9Dg

(181)
tempDB сейчас на диске F, это тот RAID, где лежат LDF-файлы базы, и как раз он показывал пониженную скорость чтения про проверке диска.
Могу попробовать tempDB переселить на диск E, это другой RAID, где лежат MDF-файлы базы, и он показывал скорость чтения в районе 200 МБ.

(183) давно надо перейти на контейнер из пары ссд дисков..

(184)
Как я писал выше, уже поднимался вопрос о замене дисков на SSD, но получили ответ, что на корзину нашего сервера они не встанут.
Ёпрст, а по (179) могли бы что-то подсказать ?

(189) восстановление индекса (перестроение) надо делать только если индексы фрагментированы >30%, а вот реорганизацию желательно делать всегда планово, раз в неделю.

вот, готовые поделки
https://infostart.ru/public/308762/

(187)
Попробовал выполнить первый же запрос на показ текущей фрагментации индексов базы.
В результате вывод пустой, обработано строк - 0, странно как-то.

(188) для какой базы ты сделал запрос ? В Студии на нужной базе пкм - создать запрос. Или явно в теле укажи use databese

(185) "Как я писал выше, уже поднимался вопрос о замене дисков на SSD, но получили ответ, что на корзину нашего сервера они не встанут."

А чем обосновывают? Так то SAS-коннектор это расширенная версия SATA и потому SSD должен влезть без проблем.
https://www.ixbt.com/storage/sas-sata.shtml

(189)
Вот попробовал на основной базе MAIN:
https://ibb.co/JQ0RGvK

(190)
Уже по помню: то ли физически они в корзину не встают, то ли корзина их распознавать не будет, вроде как слишком старое железо.

(191) потому что база в режиме 80

(193) семён семёныч ! )))))
точна

(194) я, кстати, только этой зимой! переполз с такого же динозавра как у ТСа на какую-то современную железку.

Серваку было лет 10. Рейд контроллер с кешем с BBU, корзина, диски SAS 15krpm, win2k, sql2k. И ведь работал - есть не просил. И проработал бы еще хз сколько. Только вот это "хз сколько" админов сильно беспокоило, т.к. запчастей, если что не найти.

Поэтому мигрировал на "секретный релиз" + sql2k8r2. Вообще без каких-либо проблем

(192) Если ты внимательно почитаешь ссылку в (190) то там четко написано:
"Разъем SAS является универсальным и по форм-фактору совместим с SATA. Это позволяет напрямую подключать к системе SAS как накопители SAS, так и накопители SATA и таким образом использовать систему либо для жизненно важных приложений, требующих высокой производительности и оперативного доступа к данным, либо для более экономичных приложений с более низкой стоимостью в пересчете на гигабайт."
и
"Набор команд SATA является подмножеством набора команд SAS, что обеспечивает совместимость устройств SATA и контроллеров SAS."

По крайней мере я у себя на серваке с САС-дисками воткнул обычный САТА на 1 Тб для бэкапов. Распознало без проблем.

(196)
Там стоят и SAS для баз SQL, и SATA для системы, работают без проблем.
Вопрос не в этом, по мнению экспертов там не взлетели бы именно новые SSD.

(197) пиз..дешь

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

И можешь сжатие включить для всех табличек, она сама ребилд сделает

Ну и база твоя похудеет, раз в 5..


EXEC sp_MSforeachtable 'ALTER TABLE ? REBUILD WITH (DATA_COMPRESSION = PAGE)'
EXEC sp_MSforeachtable 'ALTER INDEX ALL ON ? REBUILD WITH (DATA_COMPRESSION = PAGE)'

(201)
Это нужно разово выполнить после повышения уровня совместимости до 100 для рабочей БД ?
Или поставить как регламентное задание для базы ?

(202) разово и этот процесс не быстрый

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

Потом шринк..в окошке шринка оценишь насколько база уменьшилась в размерах.

(201) а как сильно влияет сжатие на скорость, не замерял?

(206) замерял, в снеговике порядка 1.5-2%

на одном сервере, на одном винте 2 базы развернуты ну и тупо перепровод 1 вида дока

А щас, без сжатия, тупо места нет (

(204)
Затестил:
общий размер базы - 55200 МБ
до скрипта:
свободное пространство - 3628 МБ (6%)
после скрипта:
свободное пространство - 38499 МБ (69%)

Длительность выполнения примерно 3 часа 20 минут.

А вот запрос по ней на определение текущей фрагментации индексов базы.
М снова вывод пустой, обработано строк - 0.
https://ibb.co/JQmGv8q

И ещё момент: такой скрипт должен выполняться, когда в БД нет ни одного пользователя ?

(210)
Всё, понял, в чём дело, поменял
WHERE avg_fragmentation_in_percent > 10
на
WHERE avg_fragmentation_in_percent > 0

Результат:
https://ibb.co/7zxJB9m

(210) а уровень совместимости поднял хоть?

(211) желательно

(213)
Поднял пока только на тестовой базе.

На неё всё и гоняю.

Провёл эксперимент с тестовой БД в режиме 2008 и закомментаренным vk_hook в ПриНачалеРаботыСистемы().
Специально под одним пользователем создал транзакцию в ПриПроведении(), а под другим попытался провести ещё один документ.
Секунд десять 1с подумала, а потом выдала это:
https://ibb.co/yBvJMZv
Причём в эти 10 секунд одно из ядер терминального сервера как раз и грузилось почти на 100%.
И если обычный пользователь ещё сможет нажать "Повторить" или "Не повторять", то с роботами, обрабатывающими сотни документов прямо в консоли терминального сервера всё будет совсем печально.
Любая их транзакция выдаст такое же окошко, и вся обработка документов роботом встанет колом.
Да и обычные пользователи изойдут на маты, крича, что ранее таких предупреждений у них не было, 1с тихо и без загрузки процессора ожидала окончания транзакции и работала дальше.

(217) грамотно написанный робот нормально всё отработает и при проблемах с транзакциями.
Для снятия загрузки ядра 100% при блокировке - есть и другие вк, аналогичные ремиксовый.
.
Сначала надо добиться нормальной работы базы в штатном режиме, а потом уже разруливать транзаации и прочее сугубо прикладное гуано

(218)
Я пытаюсь избежать возможных проблем при повышении с 2000 на 2008, а в данном случае о каком повышении можно говорить, когда транзакция минут на 10 и 20-30 пользователей положат процессами 1с терминальный сервер на лопатки. Так что это ни разу не "прикладное гуано".

(217) Теперь меняй ВСЕМ пользователяв время ожидания на 0 (ноль)..и наслаждайся.
А в своих поделках перепроведения втыкай код на количество попыток записи..штук 20, к примеру.
И всё полетит

И никто никого не ждёт

(219) когда у вас транзакция "минут на 10" в оперативном режиме работы - у вас в консерватории что-то не то...

(220) + к этому между попытками можно поставить паузу 100-500 миллисекунд (подобрать) что повысит "устойчивость" системы.

(220)
Не летит, при обнулении времени ожидания всё та же нагрузка 100% на одном ядре и всё то же окно предупреждения, но не через 10, а через 5 секунд.
И это при 2-х пользователях.
Как я и писал, 20-30 пользователей, 1 транзакция и все ядра сервера будут в трансе.

(222)
Не постоянно, но такие обработки есть несколько раз в месяц, в которых без общей длительной транзакции не обойтись.

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

(225) дирижёра в консерватории поменять...

(226)
Описываю то, что вижу в реальном тесте, задержка примерно 5 секунд после сообщения в трее "Ожидание блокировки таблицы "Журналы ..."" и окно с предупреждением и запросом повтора транзакции.

(227)
Дирижёр и так работает за еду :)

(229) теперь понятно... Диридер-бетонщик ;-)

Короче пока есть проблема загрузки 100% ядра, повышение до 2008 нереально, надо думать что-то другое.

(231) еще раз, такой проблемы нет. Есть только проблема в г-коде.

И клюшки, даже на mssql 2019 летают/

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

(232) проблему с прокладкой ещё забыли упомянуть...

(218)
А могли бы посоветовать какие-либо поделки, кроме vk_hook, которые могут помочь с проблемой без переписывания километров кода ?

(235) Ну вот же есть https://infostart.ru/public/83504/ или вы этим и пользуетесь?

(236)
Да, таким и пользуемся.

(205)
Сделал шринк, снова проверил фрагментацию, а там:
https://ibb.co/WzS5KX7

Это так и должно быть ?
Или после шринка снова крутить
EXEC sp_MSforeachtable 'ALTER TABLE ? REBUILD WITH (DATA_COMPRESSION = PAGE)'
EXEC sp_MSforeachtable 'ALTER INDEX ALL ON ? REBUILD WITH (DATA_COMPRESSION = PAGE)'

(238) нет.
но нужно поставить триггер на реструктуризацию табличек, что ежели новая появляется, то она автоматом с компрессией ставится

(239)
Не силён в этом деле. Подскажете, как именно ?

(240) На нимфостарте поищи, по ключевым словам сжатие таблиц SQL, там валялся готовый скрипт

(218)
Искал другие ВК, ничего не нашёл: есть старый Ромиксовый релиз vk_hook, есть наш текущий vk_hook, есть vk_sleepTerminal, но он тоже тестировался только на 7.7.25.
Ничего новее увы нету, чтоб стакалось с секретным 7-м релизом.

Ёпрст, а по (179) могли бы что-то подсказать ?

Подскажите пожалуйста всё же кто-нибудь:
если менять регламентные задания и убрать реорганизацию индекса из ежедневного задания в еженедельное, то
как лучше сделать: сначала реорганизация индекса, а потом перестроение или наоборот ?
Или вообще не принципиально ?

(243) см(186)

Я не совсем то хотел уточнить:
на сегодня у нас ежедневное задание "Обновление статистики + реиндексация" + еженедельное задание "Реорганизация индекса"
если "Реиндексацию" убрать из ежедневных в еженедельные, то сделать "Реиндексация + Реорганизация", "Реорганизация + Реиндексация" или порядок вообще не принципиален ?

Ваш вариант "восстановление индекса (перестроение) надо делать только если индексы фрагментированы >30%, а вот реорганизацию желательно делать всегда планово, раз в неделю." пока не реализуем, т.к. скрипт на проверку фрагментированности в процентах работает только для нативного режима совместимости SQL 2008.

(246) я не понимаю вашего не желания поднять уровень совместимости выше.
Реиндекс последним

(247)
Это не моё нежелание, это попытка избежать блокировочного кошмара без переписывания километров кода записей всех справочников, документов и прочего.
Пока пытался найти альтернативу vk_hook, работающую под 7-й секретный релиз и пока безрезультатно.

(248) а откуда берется этот т.н. "блокировочный кошмар"?
зы. работала достаточно приличная база, с достаточно ощутимым количеством юзверей, и приличным документооборотом - и как-то обходилось и без ромиксовской поделки (хотя она на каком-то раннем этапе использовалась для подмены запросов), и без "кошмаров".

(249)
См. (217)

(247)
Сделал отдельно статистику, ежедневно
https://ibb.co/YbSfQDK + FREEPROCCACHE

и отдельно реорганизацию + перестроение, еженедельно
https://ibb.co/DwT47Lf

Ещё заброшу tempdb на более быстрый RAID и послежу за результатом.

Пока же в субботу снова всё было печально, причём даже не помогло вручную прокрутить задание "Обновление статистики + реиндексация".
Сегодня пришлось её же крутить с утра уже при работающих пользователях, и 1с снова заработала нормально.

(250)
"-доктор, когда я вот так делаю, у меня в ухе стреляет!
-- а вы так не делайте!!!"©
Если создать транзакцию - она тормознет остальное хоть с хуком, хоть без хука.
пользователи и так увидят, а роботы это должны обрабатывать...
впрочем, я не вижу особой надобности перезаписывать роботом "сотни документов"...

(253)
Предприятие торговое, в течение всего дня роботами забрасываются тысячи чеков в БД.

(253)
+ пользователи-то увидят, но пока они будут ждать этого окошка, процессор на терминальном сервере потихоньку наберёт 100% от всех пользователей, и всё станет совсем печально.

(254) Если чеков "тысячи", то надо нормально переписать этот процесс. Значит, предприятие не совсем уж мелкое, и должно смочь это себе позволить. (я не имею ввиду исключительно "код", я имею ввиду весь процесс в целом, от появления чеков до их отражения). Правда, у меня было, емнип, всего лишь не более 9000 доков в день.
(255) про проблему с терминальником слышал, но вот не сталкивался. правда, большинство работало "на клиентах", а не в терминале

Для каких конкретно целей используется vk_hook?

(257)
Чтобы при любой транзакции:
1) не грузились ядра терминального сервера с 1с.
2) пользователь не жмакал постоянно "Повторить транзакцию", а спокойно ждал, пока его документ проведётся в порядке очереди.

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

(259)
Это уже откровенные костыли будут.
Опять же с переписыванием километров кода всех модулей проведения во всех местах.

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

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

(261) угу.

(259)
Т.е. один робот, обрабатывая чеки, создаёт документ и ставит его проведение в очередь к другому роботу, ожидает его отклика, чтобы знать, что делать ему самому.
Это ли не костыли ?

(264) ВСЕ ДОКУМЕНТЫ при проведении становятся в очередь.
еще раз - нагруженная система - а у тебя такая ибо рефакторить ты ее не хочешь - требует других подходов.
если тебе делать лень - так и скажи мне влом.
купите супер-пупер мега сервер и херачьте... без костылей.
если взять 10 тыс доков в день за 9 часов - то за минуту получается 18 документов. вполне некритичная нагрузка.

(248) Покажи ЧТО ты пишешь в транзакции, например. В 96% случаев она не нужна .

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

(266)
В основном это глобальные документы типа "Закрытия месяца", есть ещё парочка типа товарных отчётов за месяц по каждой торговой точке.
В момент их формирования не должно быть вообще никаких движений ни по регистрам, ни по счетам.
А формируются они увы не быстро.

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

(268) и..вы эти отчеты в транзакции выполняете что ле?!

(270)
Заполнение их табличных частей со всеми движениями - да, в транзакции.

(271) ТКВ.

(272)
ТКВ — табло котировок валют
ТКВ — Терское казачье войско
ТКВ — термостат для определения кинематической вязкости жидкостей
ТКВ — Теченский каскад водоёмов
ТКВ — точка кипения воды
ТКВ — температурный коэффициент вязкости

Что выбрать ?

(273) ТКВ™ - Традиционный Китайский Вопрос, звучащий примерно так: "анахуа?"

(271) Че за табличные части отчета ?

Ну и да, ТКВ ?

(275) да, ХЗ! (Хотим Знать!)

(265) Но есть же еще всякие программные а порой и интерактивные создания элементов справочников и документов - это же тоже транзакционные процедуры и их тоде в очередь? А потом что значит в очередь? С какого момента она начинаетс? Не может ли быть так что в очереди останутся документы вчерашнего дня например? Обработка такого проведения понятно что в отдельном сеансе. И работает как обработка ожидания?

(267) ---Если что, у нас часто пользовались групповыми обработками для записи или перепроведения, более того, часть логики затрагивала несколько доков, НО никаких транзакций не было и никто никого не ждал.
И было фиолетово, что кто-то что-то перепроводит за год, когда остальные колотят и проводят доки---

А как вы этого добивались?

(220) можно поподробней на тему "А в своих поделках перепроведения втыкай код на количество попыток записи..штук 20, к примеру." - как это в коде выглядит ?

(278) запись самого документа/элемента проста и коротка. А вот проведение документов - уже, как правило, требует вычислений т.е. времени, в течение которого база поддерживается в заблокированном состоянии для сохранения консистентности.
в очередь - значит, "в очередь, $укины дети!". как работает очередь - зависит от реализации. можно тупо в календарно-временной последовательности, а можно с учетом приоритетности документов...

(280) чего уж подробней? попытка-исключение в цикле. если в попытке провелось, значит цикл прерывается. Можно еще в один обернуть, в котором после серии попыток - пауза

Вчера вечером выгнал всех пользователей из 1с, сделал необходимое обновление конфигурации (добавлял реквизиты в ТЧ документа), а потом перенос tempdb на более быстрый RAID.
Запустил пользователей, и 1с ... снова стала глючить напропалую.
Причём непонятно, какое именно действие привело к этому, грешу всё-таки на перенос tempdb.
После прокрутил вручную задание "обновление статистики + FREEPROCCACHE" https://ibb.co/YbSfQDK , уже без переиндексации.
Крутанулось оно минут за 25, и 1с ... взлетела с нормальной скоростью.
Отсюда вопрос: может мы зря грешим на индексы, пытаясь играться с заданиями переиндексации и реорганизации, похоже виновата именно статистика.
Она же теперь апдейтится каждую ночь по расписанию и как вариант, после определённого числа её апдейтов 1с снова ляжет на лопатки (обычно происходило ровно через 7 прогонов, в ночь с субботы на воскресенье).

И может как вариант поставить "обновление статистики + FREEPROCCACHE" в очереди выполнения после "переиндексации и реорганизации" в ночь с субботы на воскресенье, а не до неё ?

(283) "глючат напропалую" одни и те же запросы?
посмотри план запроса при "глюках напропалую", и при "нормальной работе".
Ну и индексы "разваливаются" обычно при весьма, хм, нетрадиционнной работе (например, с кучей заднего числа).
у меня на моей базенке реиндексация делалась раз в неделю, хватало.

(285)
Вообще абсолютно всё, даже банальный поиск по журналу по введённому номеру документа.
Ну и соответственно всё загрузки документов роботами, в нормальном режиме 1 чек проводится за 1 секунду, при глюках - 13-16 секунд.
Реиндексацию теперь и поставил на еженедельное обслуживание по схеме "переиндексация + реорганизация", ранее она была в ежедневном обслуживании вместе с обновлением статистики.

(286)
UPD. Т.е. не "переиндексация + реорганизация", а "реорганизация + переиндексация", перепутал малость.

Наймите Ёпрста. Но имхается, ваши жабы вам бюджета не  дадут.

(286) планы запроса - отличаются?

(289)
Увы, не силён, где именно можно это проверить.

Внесу свою лепту:
1. На старых серверах пристальное внимание необходимо уделить рейд контроллеру
типа LSI MegaRAID или Intel(построенных на этом же железе, но прошитых собственной прошивкой).
Лет пять назад я столкнулся с проблемой, что backplane не поддерживает скорость в 3gb/s.
заниматься модернизацией backplane - неблагодарное занятие, остается использовать
рейд-контроллер pcie, но на нем обязательно должна быть возможность установки в старые платы.
2. Если вы когда-нибудь сталкивались с отвалом дисков в процессе работы, то эта проблема (скорее всего)
перегрева рейд-контроллера. Я решил её с помощью установки в pciе-слот самодельного вентилятора на основе
вентилятора для корпуса Noctua, имеющего высокий ресурс.
https://vk.com/dmrsan?ysclid=l6nb5zu22f507887278&z=photo111663024_457239223%2Fphotos111663024
Помогло капитально, сервер практически перестал отключаться.
Я думаю, что у вас проблема тоже может быть связана с перегревом рейд-контроллера.

(290) отловить - профайлером.  посмотреть на план - https://olegon.ru/google/?q=как%20посмотреть%20план%20выполнения%20запроса%20ms%20sql

(284) Делайте обновление статистики каждую ночь, а разные реиндексации оставьте на выходные

(292)
Так а что именно ловить, там запросов тьма будет.

(293)
Сейчас так и выставлено, ранее было ежедневно кроме статистики ещё и реиндексация.

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

(296)
ок, попробую глянуть при следующих лагах.

(296) В общем-то и с одинаковыми планами может то тормозить, то нет, вне зависимости от индексов и железа. Зависит от того, с какими параметрами закешировалось при первом вызове

В ночь с субботы на воскресенье лаги закономерно повторились, причём в эту ночь делалось только "Обновление статистики", даже не было традиционного "реорганизация + переиндексация".
Взял самые ресурсоёмкие запросы из списка и открыл план одного из них:
https://ibb.co/gZ0tKN0
https://ibb.co/0XXW67k

крутанул вручную "обновление статистики", 1с отпустило, но план этого же запроса не поменялся:
https://ibb.co/wyG2whM
https://ibb.co/YZ70ydK

Что ещё интересно, нашёл 1 запрос с интересным сообщением об отсутствии индекса:
https://ibb.co/dJZZnGs

Всё воскресенье 1с отработала нормально, с утра понедельника - та же песня, снова кручу "Обновление статистики".
Как правило, это помогает до следующей субботы :(

(299) А как вы посмотрели план реально выполненного запроса? Запрос, выполненный в тестовом режиме из утилиты, может выполнится иначе, чем запрос, который вызвала 1с.

(299)
А вот сегодня после ручного "Обновления статистики" план запроса с отсутствующим индексом:
https://ibb.co/C7mcXpr

Изменения всё же есть.

(300)
ПКМ на запросе в списке последних ресурсоёмких запросов и там "Показать план запроса".

(299) 9898 чего за регистр хоть, в котором останки считаются ?
Поди наглухо и незакрыт еще

(303)
#==TABLE no 644    : Регистр ОстаткиТоваров
# Name    |Descr                         |SQLTableNam|RecordLock
T=RG9898  |Регистр ОстаткиТоваров        |RG9898     |          
#-----Fields-------
# Name                  |Descr               |Type|Length|Precision
F=PERIOD                |Period Registr      |D   |0     |0        
F=SP9893                |(P)МестоХранения    |C   |9     |0        
F=SP9894                |(P)Товар            |C   |9     |0        
F=SP9895                |(P)Количество       |N   |14    |3        
F=SP9896                |(P)Сумма            |N   |17    |2        
#----Indexes------
# Name                           |Descr         |Unique|Indexed fields                                              |Type      
I=PK_RG9898                      |PERIOD+PROP   |1     |PERIOD,SP9893,SP9894                                        |1          
I=VIA9894                        |VIA9894       |0     |PERIOD,SP9894                                               |0          
#

Да тут дело не в конкретном регистре.
Ведь баги наблюдаются вообще во всём в эти моменты.

В момент, когда опять появятся тормоза, позапускайте DBCC FREEPROCCACHE, возможно поможет

(305)
Ок, попробую.
DBCC FREEPROCCACHE стоит кстати 2-м шагом в задании "Обновление статистики".

(299) У вас похоже прямые запросы. Тогда можно первый запрос сюда в человеческом виде? Ну тот, который с [пЦена $Число]

+(307) И еще, было бы любопытно
Select count(*) from rg9898
и
select count(*) from ra9898

у регистра, измерения МестоХранения и Товар надо местами поменять
и у измерения Товар установить "Отбор движений"

(307)
Уточните: этот https://imgbb.com/gZ0tKN0 или этот https://imgbb.com/dJZZnGs

(308)
Select count(*) from rg9898
3.074.158

select count(*) from ra9898
19.001.889

(309)
Поясните пожалуйста смысл смены местами измерений.
У измерения Товар "Отбор движений" установлен.

(312) в PK_RG9898 будет первым Товар..хотя, и так VIA9894 задействован в запросе, раз галка стоит

(312) доступ к итогам, с отбором по товарам, был бы сразу по кластерному индексу PK_RG9898 без VIA9894

(313) при использовании VIA9894 все равно будет lookup к кластерному

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

https://ibb.co/dJZZnGs
https://ibb.co/C7mcXpr

я бы убрал отбор движений по измерению МестоХранения

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

(310) Так вроде четко написано: "Тогда можно первый запрос сюда в человеческом виде? Ну тот, который с [пЦена $Число]"
И в ваших картинках он Первый. Но он нужен не из Профайлера, а из 1С-ки. Найти, что за запрос и код здесь показать.

(319)
Я боюсь, что по тексту из профайлера я не смогу найти нужный запрос именно в 1с, их очень много будет схожих.

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

сделай это (317)

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

в выходные производится массовое перепроведение доков?
кажется я вспомнил одну древнюю штуку..

(323) ты про замедление проведения. которое наблюадлось на SQL2000...?

(324) да
Вот только не помню, это было общее замедление сервера или только проводящего сеанса
И не помню как было на sql2k5+ если база в режиме 80

Думаю, коллеги напомнят

(325) реконнект нэйтив был поправлен в 2005

конечно "ошибка" 2000 присутстует. ведь база в режиме 80.
ну и вообще понижение базы - этот режим не должен применяться на продакшен,
режим понижения базы оставлен для отладки чтобы перенести плавно во времени приложения на новую базу.
Основное что при понижении релиза оптимизатор запросов не работает от слова совсем.
Это как бы на каком нибудь крутом мерседесе Вы едете по автобану и у Вас зашито ограничение скорости 60 км/ч

(323)
Нет, всё то же стандартное поступление чеков, как и в рабочие дни, но в меньших количествах.

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