База знаний Одина – Одинэсника Форумы ODIN – Форум по 1С Предприятию Торможения отчетов и регламентных заданий

Просмотр 0 веток ответов
  • Автор
    Сообщения
    • #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 отъедает выделенную ему память) также в норме.

      Уважаемое сообщество, подскажите, куда ещё можно копнуть. Теряюсь в догадках.

Просмотр 0 веток ответов
  • Для ответа в этой теме необходимо авторизоваться.