База знаний Одина – Одинэсника › Форумы › ODIN – Форум по 1С Предприятию › Торможения отчетов и регламентных заданий
- В этой теме 0 ответов, 1 участник, последнее обновление 2 недели назад сделано
komiak.
-
АвторСообщения
-
-
19 сентября 2025 в 14:48 #33458
komiak
УчастникЗдравствуйте. На БД (весом 150гб+) начали долго выполняться отчеты и проводиться некоторые операции, а также стали долго отрабатывать регламенты (“Групповое перепроведение ИПЧ”, вдруг знакомо).
Проблемы тормозов совпали (?) с переведением БД из “простой” модели восстановления в “полную”, с включение обрезки ЖТР MSSQL (по времени, раз в час), а также включением зеркалирования на другой, аналогичный по характеристикам, сервер (немного различается размер кластера диска с БД и ЖТР на основном и зеркальном сервере, т.к. разные диски (NVME SSD), в остальном – идентичные).
Вводные:
1. ОС Windows Server 2022
2. MS SQL 2022 Enterprise
3. Версия платформы 8.3.27.1688
4. Конфигурация 1С:УНФ 8. Управление предприятием общепита, редакция 3.0 (3.0.5.184)Какие были попытки решения проблемы:
1. Пауза зеркалирования – не помогло
2. Отключение зеркалирования – не помогло
3. Перезапуск платформы – не помогло
4. Перезапуск платформы с очисткой сеансового кеша – не помогло
5. Отключение прочих БД, которые расположены на том же сервере и подключены к той же СУБД, с отключение регламентов с перезапуском СУБД и платформы – не помогло
6. Перезагрузка сервера полностью – не помоглоПри этом, если восстановить эту БД на другом сервере (на который осуществлялось зеркалирование) – то всё ок, показательный отчет формируется за 1-1.5 минуты, при том, что на проблемном он формируется 20-25 минут %)
Финт с бекапом на проблемном, разверткой на нормальном, и обратным бекапом и разверткой на проблемном – не прокатил, результаты те же, медленно. По словам 1с-программиста, в других базах (а их рядом ещё 3) таких тормозов нет
Снова перевел проблемную БД на “простую” модель восстановления в MSSQL (считай вернулся к исходному её состоянию) – также медленно.
Рядом с боевой сбойной базой есть такая же, как типа демо, там проблемы воспроизводятся тоже – медленное выполнение отчетов и т.п.
На этой проблемной и других БД, подключенных к этому же серверу СУБД, проводится регламенты по реорганизации индексов (если фрагментация более 5%) и перестроение индекса (если фрагментация >30%) с перестроением планов запросов по этим индексам, а также обновление статистики 2 раза в день.Параллельно, на ныне сбойный сервер (будем его называть так) также было сделано зеркалирования с зеркального сервера другой БД.
После чего в логах MSSQL появились записи вида:
There have been 60160 misaligned log IOs which required falling back to synchronous IO.
В журнале ОС соответственно: Имеется 60416 операций ввода-вывода журнала с неверным выравниванием, что привело к необходимости возврата к синхронному вводу-выводу.
Примеры сообщений выдернуты в разное время из журналов.После чего проверил параметры дисков на этих двух серверах.
На сбойном параметры диска с БЖ и ЖТР такие:
C:\Windows\system32>fsutil fsinfo sectorinfo E:
LogicalBytesPerSector : 512
PhysicalBytesPerSectorForAtomicity : 4096
PhysicalBytesPerSectorForPerformance : 4096
FileSystemEffectivePhysicalBytesPerSectorForAtomicity : 4096
Выравнивание устройства : Выровнено (0x000)
Выравнивание разделов на устройстве : Выровнено (0x000)
Без штрафа за поиск
Очистка поддерживается
Не поддерживает DAX
Без тонкой подготовкиНа нормальном такие:
C:\Windows\system32>fsutil fsinfo sectorinfo E:
LogicalBytesPerSector : 512
PhysicalBytesPerSectorForAtomicity : 512
PhysicalBytesPerSectorForPerformance : 512
FileSystemEffectivePhysicalBytesPerSectorForAtomicity : 512
Выравнивание устройства : Выровнено (0x000)
Выравнивание разделов на устройстве : Выровнено (0x000)
Без штрафа за поиск
Очистка поддерживается
Не поддерживает DAX
Без тонкой подготовкиВот собственно и вся разница) попытался форматированием диска Е на сбойном привести размеры соответствие – не вышло, форматированием не решается. Пишут, что особенности используемых дисков.
Сейчас все зеркалирования отключены.
Также добавлю, что, судя по виндовым счетчикам производительности, большой нагрузки на дисковую подсистему нет. Утилизация дисков минимальна, лишь в редкие моменты подскакивает до больших значений.
TempDB MSSQL и ЖР 1С выведены на отдельный, от файлов БД и ЖТР, диск, более быстрый.
Нагрузка по ЦПУ и ОЗУ (MSSQL отъедает выделенную ему память) также в норме.Уважаемое сообщество, подскажите, куда ещё можно копнуть. Теряюсь в догадках.
-
-
АвторСообщения
- Для ответа в этой теме необходимо авторизоваться.