Например, формируем ОСВ подвисание на 10-40 секунд. или проводим документ - тоже висит дольше чем скажем это было до обновления...
конфигурация изменена, но сильно.. пару реквизитов добавлено,  и несколько расширений)
SQL Сервер проц почти все время на 90-98% нагружен
intel(R) Xeon(R) Silver 4215 CPU  @ 2.50GHz (2 processors) 64 gb memory

Размер базы 370 гб

Смотрели запросы, которые в SQL дольше всего выполнялись, то это запросы к регистру бухгалтерии, и счет-фактурам...
в регистре бухгалтерии Хозрасчетный порядка 28 млн записей.

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

Есть ли смысл купить 1С ЦУП и посмотреть какой запрос или обработка дольше всего выполняются?
Можно ли сказать что мощности текущего железа априори мало?
Спасет ли ситуацию свертка базы? (скажем из 10 лет - 7 лет свернуть, пусть даже ссылки останутся в базе данных, документы будут просто помечены на удаление, а остатки скажем на 2019 год введены вводом остатов/операцией в ручную)

Проц точно дохлый. Турбо работает?
База большая, но что в ней? Записи таблиц или файлы. База на ssd? Или древний raid 5 на hdd.
Распределение памяти 1с vs sql.
Поставь MAXDOP =1, замерь время, по стабильней может быть.
% нагрузки высок. Один пользователь или 300? База на сервере 1 или есть другие.

Да и 20 секунд приемлемо...

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

(3) да, так и есть.

Сервер виртуальный. на нем 64 гб, из которых sql разрешено брать 54 гб максимум. Диспетчер задач показывает, что оперативка использована всегда на 86%, ну то есть как раз на эти 54гб.. Сейчас будем добавлять оперативной памяти. Есть предположение что 64 гб, для двух баз - малова-то. Сеансов активных порядка 170-220 штук...

(1) База большая, но что в ней? Записи таблиц или файлы. - записи таблиц. База на ssd?  - нет, sas 10k
Распределение памяти 1с vs sql - и там и там по 64 гб оперативки
Поставь MAXDOP =1, замерь время, по стабильней может быть. - ок, изучаю
"% нагрузки высок. Один пользователь или 300? База на сервере 1 или есть другие." - пользователей порядка 150, на sql 2 базы. (ЗУП  и БУХ ), соответственно когда начинает висеть бух, тут же начинает зависать и зуп. Но сервера 1с у них разные.

сейчас увеличили с 64 до 128 гб оперативки на sql сервере, и стало все летать, но! уже конец рабочего дня... и это не показатель.. Теперь надо ждать завтрашнего дня

(0) >Есть ли смысл купить 1С ЦУП и посмотреть какой запрос или обработка дольше всего выполняются?
ЦУП не нужен, можно самому тех.журнал посмотреть


План запроса в SSMS на стороне MSSQL можно посмотреть через:

SELECT TOP 100 SUBSTRING(qt.text, (qs.statement_start_offset/2)+1,
        ((CASE qs.statement_end_offset
          WHEN -1 THEN DATALENGTH(qt.text)
         ELSE qs.statement_end_offset
         END - qs.statement_start_offset)/2)+1),
qs.execution_count,
qs.total_logical_reads, qs.last_logical_reads,
qs.min_logical_reads, qs.max_logical_reads,
qs.total_elapsed_time, qs.last_elapsed_time,
qs.min_elapsed_time, qs.max_elapsed_time,
qs.last_execution_time,
qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
WHERE qt.encrypted=0
ORDER BY qs.total_logical_reads DESC

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

intel(R) Xeon(R) Silver 4215 CPU  @ 2.50GHz (2 processors) 64 gb memory,
Сервер виртуальный,
Размер базы 370 гб,
пользователей порядка 150...

странно, что раньше не тормозило

(7) какой техжурнал? Не факт что чел в курсе про планпитания, про обслуживание СУБД и 1С.... а он вообще бэкапы-то делает?

(8) + куча левых задач на этой виртуалке

(8) да, странно, но факт. На мои вопросы: а не нуждается ли наш сервер в апрегрейде? отдел IT отвечает - что сервер достаточной мощности... Но вот завтра проверим , решится ли вопрос одним увеличением оперативки.
А подскажите, какой минимум по параметрам нужен для такой базы? Чтоб я мог админам намекнуть, к чему стремится надо.

(9) бэк апы делаются, конечно. В плане обслуживания на sql все задания рекомендуемые разработчиком делаются каждую ночь. Речь про переиндексацию и дефрагментацию индексов, обновление статистики + DBCC FREEPROCCACHE (который кэш плана запросов чистит)
Насчет тех журнала, вы правы, пока только пытаюсь разобраться, как его настроить.

(11) чего тут намекать?
ОЗУ никогда не лишняя и будет утилизирована
добавили памяти, если загрузка процессора упала, а скорость стала приемлемая, то значит норм )
если ресурсы позволяют, то можно поэксперементировать, чтобы добиться баланса между вашими хотелками и жадностью админов

sas 10k - это дно.
Надо столько памяти, чтобы всё используемые таблицы в ОЗУ уместились.

(0) 1С на виртуальном сервере сразу предъявляет к админам требования компетенций тонких настроек этих самых серверов, в которых они обычно ни бум-бум, приходится жрать кактус так.
https://habr.com/ru/post/675398/

да, по ОЗУ теперь запас есть небольшой, но ЦП все равно сильно нагружен под 90-100 большую часть времени. Сделали запрос из (7) и в топе самых жирных оказался запрос к таблице _AccRg561
это и есть таблица регистр бухгалтерии Хозрасчетный. Он у нас большой. Там 28 млн записей.

Но если выполнять запрос в ssms с фильтром по таблицам без индекса, то он показывает что типа эта самая таблица _AccRg561 без индекса...
Хотя ночью мы уже не раз запускали как полную переиндексацию базы так и отдельно этой таблицы...
То что индекс слетает с этой таблицы это нормально?
вот сам запрос в ssms
-- Captures the Total CPU time spent by a query along with the query plan and total executions
SELECT
    qs_cpu.total_worker_time / 1000 AS total_cpu_time_ms,
    q.[text],
    p.query_plan,
    qs_cpu.execution_count,
    q.dbid,
    q.objectid,
    q.encrypted AS text_encrypted
FROM
    (SELECT TOP 500 qs.plan_handle,
     qs.total_worker_time,
     qs.execution_count FROM sys.dm_exec_query_stats qs ORDER BY qs.total_worker_time DESC) AS qs_cpu
CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS q
CROSS APPLY sys.dm_exec_query_plan(plan_handle) p
WHERE p.query_plan.exist('declare namespace
        qplan = "http://schemas.microsoft.com/sqlserver/2004/07/showplan";
        //qplan:MissingIndexes')=1

У меня упп, 1.2++ ТБ. Разумеется самая большая таблица субконто хозрасчётного.
Ускорил и уменьшил базу не трогая эти регистры. Посмотрел другие побольше, в основном РС всякие, заказы и прочие. Обрез по 2020 год, позакрывал незакрытые остатки, настроил регламенты и прошелся по рекомендациям 1с.
+ полный пересчет итогов, где сперва truncate все таблицы остатков.
С хозрасчетным можно , к примеру, частями(помесячно) закрывать по ночам. Есть оьработка по закрытию счетов. То есть документы не трогаем, просто движения чистим и пишем остатки. До этого не дошел, база и так легче дышать стала.

(17) то есть как вариант мой регистр хозрасчетный по ночам резать? скажем, удалять обработкой движения по организациям (их там порядка 60 шт) до, например, 2020 года, и вводить их Операцией в ручную?

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

(19) да, это получается некая лайт версия штатной обработки свертка остатков... только без пометки на удаление документа и свертки не всех остатков, а только регистра бухгалтерии..
в sql регламенты все настроены, полный пересчет итогов делали (правда без truncate ).. не помогло..

1) рекомендации 1с по настройке скуля
2) посмотреть оборотку. Преспокойно могут висеть товары и т.д. с лохматых времен, бухгалтерам пофигу
3) что показывают верхние таблицы в скуле? Что после хозрасчетного идёт? Неужели все 300гб это хозрасчетный?
Я бы наверное так начал. Мне помогло.

или к примеру, в 10 счет субконто добавили руками, приход заполняют, на расход забили. 10 сходится если не смотреть по субконто, да и так сойдет

(0) Сервер виртуалка?
Проц вижу что говно а дисковаая подсистема где база по тесту CrystalDiskMark на 4к блоках как?

Проверь бенчмарками СPU-Z проц и CrystalDiskMark диски

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

глупый вопрос: размер логфайла влияет на что то? сейчас вижу что лог файл 65 мб при размере базы в 350 гб
сколько он размером оптимально должен быть?

https://pastenow.ru/dafee9c8c53c57697af94439d581b71b
у нас режим логирования simple, то есть по сути логирование не ведется... видимо это админы сделали для ускорения.

Подскажите по опыту, на последний платформах имеет смысл обновить sql до 2016 ? или новее? Или это никак не повлияет на скорость работы? сейчас sql 2012

(24) глупый. 65 mb значит Recovery model базы simple? Я б не рискнул.

(25) админы суицидники

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

(26) да.. почитал...
https://kuharbogdan.com/stati-po-1s/prostaya-i-polnaya-model-vosstanovleniya-v-ms-sql/

Уточню админов, почему так ... видимо разрастался лог файлов.. и с эту проблему побороли таким путем

На копии базы сделал процедуру выгрузки DT из копии базы, затем в копию залил dt пустой базы, затем в ssms запустил команду шринк, база стала пустой (27 мб), затем залил в нее dt, и база усохлась с 357 ГБ до 287 ГБ.

Как думаете стоит аналогичные действия проделать на рабочей базе? даст это какой то эффект в плане скорости ее работы?

(30) скорей всего, что какой-то эффект будет, но мало заметный.

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

(31) эээ а как же поля неограниченной длины?

Вопрос про SQL и таблицу, которая не освобождает место.

(32) я вижу только то, что указано в этой ветке. БП КОРП 3.0.121.23. Так что злоупотребления неограниченными строками в ней не должно быть. И не они там тормозят, наверное.

(16)
>это и есть таблица регистр бухгалтерии Хозрасчетный. Он у нас большой. Там 28 млн записей.
Это немного, у клиента на 4Гб ОЗУ SQL + 2 ядра с >30млн записей и 50Гб БД (без лога) только перестали использоваться кластерные индексы на 100 пользователях онлайн.

>Но если выполнять запрос в ssms с фильтром по таблицам без индекса, то он показывает что типа эта самая таблица _AccRg561 без индекса...
Не очень понятно. Кластерный индекс в любом случае должен быть, использовать его или нет при выполнении запроса решает MSSQL (на основе ОЗУ и настроек - может туда что-то вносили) либо полное сканирование таблицы, либо индекс.

[Есть предположение что 64 гб, для двух баз - малова-то. Сеансов активных порядка 170-220 штук...]
Это 1-е, что должно было озадачить)

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

(36) админ смотрел в забиксе - говорит не выросли... Сейчас странная ситуация: ОЗУ использовано 35 гб из 128 гб, при этом процессор нагружен на 100% - и в базе работать невозможно, все висит.
Если скидываю все сеансы 1С - то процесс разгружается полностью, то стоит всех запустит - снова 100% загрузка

(37) а релиз платформы уже указал тут? Может я невнимательно посмотрел...

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

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

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

(38) платформа 8.3.20.1674, но она у нас уже давно, и работала стабильно... все сеансы тонкие. Заходят 90% с локальных машин - под тонким клиентом. (39) рестарт в последние дни делаем 1-2 раза в день, но сейчас рестарт вообще ни на что не повлиял.
Сейчас сделали рестарт - все пользователи зашли и все сразу зависло... понятно, что многие начали закрывать месяц - но еще месяц два назад такого не было... А сейчас в лучшем случае долго выполняется проведение или любое действие , а в худшем случае пользователю  приходит сообщение типа произошла не предвиденная ошибка sql ошибка субд Microsoft SQL Server Native Client 11.0: Invalid object name '#tt1'

Сейчас админ экспериментирует с параметрами виртуального сервера SQL. В частности поставили распараллеливание на 16 ядер, вместо 8 - и вообще все повисло... Сейчас вернули на 8...

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

(41) к сожалению, да... еще есть база ЗУП, она также объемная 45 гб (основные регистры имеют порядка 1 млн записей), в ближ дни админы будут ее выносить на отдельный свой SQL сервер (потому что судя по статистике - запросы из ЗУПа тоже неплохо нагружают sql)
Я сейчас развернул конфигурацию 1С ЦУП, настраиваю ее , хочу включить мониторинг, посмотреть , может он что мне покажет...

(41) а на какой? 8.3.22? Типа обновили базу , надо и обновить платформу?

(42) я имел ввиду, что скорей всего, что поведение другой базы будет отличаться от того, как сейчас ведет себя база БП.

А насчет обновили базу... БП у вас идет довольно давно. Когда платформу заменяли, то предварительно (перед этим обновлением) была радикальное повышение режима совместимости в конфигурации.
И там в базах встречались неприятные некоторые ошибки. Не буду сейчас вспоминать какие конкретно, но ошибки были. Некоторые Заказчики на эти грабли наступили.

И в этом году тоже прошло повышение режима совместимости в БП. Это странным образом совпадает с выявлением траблов именно в конфликтах между релизом платформы и релизом конфы.

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

Теперь в базе какие-то ошибки есть. Может быть перезагрузка через ДТ и спасает. Это нужно проверять.

(40) maxdop = 1 ставили?

(45) нет.... было 0.... потом поставили 16, и стало ппц.. ваще все встало... сейчас поставили 8, и стало работать лучше... но не так, как хотелось бы.. Поставить 1 попробовать? как это можно обосновать для админов?

(46) один отчет от одного пользователя грузит 1 проц или кладет все 16 ядер. Выбирайте. Плюс при некоторых запросах выполнение быстрее в разы на 1 ядре чем на большем кол-во.
https://its.1c.ru/db/metod8dev/content/5945/hdoc