← На главную

При возникновении проблем с производительностью в системе 1С, особенно когда кажется, что мощное оборудование работает не так, как ожидается, важно провести всестороннюю диагностику. Рассмотрим ситуацию, когда новый PCI-e SSD показывает низкие результаты в синтетических тестах, а сама система 1С сталкивается с постоянными блокировками и замедлением работы.

1. Почему синтетические тесты NVMe SSD могут показывать некорректные результаты?

Прежде всего, давайте разберемся с первой частью проблемы: почему тест Гилева показывает неожиданно низкие результаты для высокопроизводительного накопителя, такого как Intel DC P3600 NVMe SSD, в сравнении с более медленным SAS SSD.

1. Особенности NVMe и шины PCI-e. Накопители NVMe (Non-Volatile Memory Express), такие как Intel DC P3600, используют шину PCI-e для прямого взаимодействия с процессором. Это обеспечивает значительно более высокую пропускную способность (вплоть до 13000+ МБ/с для Gen5) и значительно меньшие задержки (70–100 мкс) по сравнению с SAS (500–800 мкс) и SATA. Протокол NVMe разработан специально для флеш-накопителей, обходя узкие места традиционных контроллеров SATA/SAS.
2. Несовершенство некоторых тестов. Как показали обсуждения, некоторые синтетические тесты, включая тест Гилева, могут быть "кривыми" или неоптимизированными для корректной работы с современными NVMe-накопителями, особенно если они подключены через переходники M.2 или работают в виртуализированной среде. Такие тесты могут неверно интерпретировать скорость обмена данными или не полностью задействовать потенциал NVMe. Некоторые пользователи отмечали, что на том же оборудовании другие синтетические тесты (например, CrystalDiskMark) демонстрировали ожидаемо высокие результаты, в то время как тест Гилева показывал низкие значения (24-27 вместо 65, как на более старых системах).
3. Влияние драйверов и настроек BIOS. Для NVMe SSD крайне важно убедиться в наличии актуальных драйверов для операционной системы. Также настройки BIOS, такие как режимы работы PCI-e слотов, энергосбережение, могут влиять на производительность. Убедитесь, что все включено на максималках: экономия электроэнергии (Intel SpeedStep/AMD Cool'n'Quiet) отключена, максимальное потребление включено, а Turbo Boost/Turbo Core активен.

Вывод: Мы рекомендуем не полагаться исключительно на один синтетический тест, особенно если его результаты противоречат логике или другим бенчмаркам. Используйте несколько инструментов для оценки производительности и, что более важно, ориентируйтесь на реальную производительность вашей рабочей нагрузки 1С.

2. Диагностика и оптимизация общих проблем производительности 1С и SQL Server

Когда система 1С начинает "тормозить", возникают постоянные ожидания на блокировках, а дисковая подсистема работает не так эффективно, как хотелось бы, требуется комплексный подход к диагностике. Рассмотрим основные аспекты, которые могут вызывать проблемы.

2.1. Анализ и оптимизация дисковой подсистемы

Ваша текущая конфигурация включает "СХД на fibre-channel, Raid-6 с кэшированием на запись", а также "RAID 10 из 4-х древних Cheetah 15K6 146 GB" для базы. При этом вы экспериментируете с NVMe SSD. Давайте проанализируем этот аспект.

1. Ограничения старого оборудования. Использование современных SSD/NVMe на старых серверах с древними HDD в RAID-10 может стать узким местом из-за ограничений пропускной способности старой шины или контроллера. Древние диски Cheetah 15K6, хоть и были производительными в свое время, значительно уступают современным SSD по скорости случайного доступа и пропускной способности. Это может быть причиной низкой общей производительности, даже если часть данных кэшируется.
2. Роль NVMe SSD. NVMe накопители идеально подходят для хранения "горячих" данных, временных баз данных (TempDB), файлов логов транзакций SQL Server, а также самой базы данных 1С, если она помещается на такой диск. Их низкие задержки и высокая пропускная способность могут значительно ускорить операции ввода-вывода.
3. Использование SSD в качестве кэша.
   • Для TempDB: Использование SSD (или даже Ram-диска, как в вашем случае) для TempDB — это отличное решение, которое может значительно ускорить операции, требующие временных таблиц. Если TempDB находится на Ram-диске, это убирает дисковое узкое место для временных операций.
   • Дополнительный кэш: В некоторых SAS RAID контроллерах, например, LSI MegaRAID, существует технология CacheCade, которая позволяет использовать SSD в качестве кэша для HDD-массивов, значительно увеличивая производительность на операциях случайного доступа. Мы можем рассмотреть возможность использования NVMe как дополнительного кэша для "горячих" данных, которые постоянно запрашиваются системой.
   • Кэширование на RAID-контроллере для SSD/NVMe: При использовании SSD (особенно корпоративных с собственной защитой от потери питания) кэширование на RAID-контроллере может быть неэффективным или даже приводить к снижению производительности. Скорость случайного доступа у SSD часто сравнима со скоростью работы кэша контроллера, что может приводить к промахам кэша. Для файлов логов транзакций особенно полезно безопасное кэширование записи на диск с использованием NVDIMM-N, что позволяет включать кэширование записи без риска потери данных при отключении питания.
4. RAID для NVMe SSD. Для NVMe SSD в большинстве случаев RAID-массив не является необходимым для ускорения или повышения надежности, особенно для сервера 1С/СУБД. Они сами по себе обладают высокой производительностью, а избыточность обеспечивается на уровне СХД или резервного копирования. Если вы все же хотите использовать RAID для NVMe, мы можем рассмотреть программные реализации или специализированные аппаратные решения, поддерживающие NVMe.

2.2. Оптимизация SQL Server и 1С

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

1. Обновление статистики.
   • Частота: Регулярное обновление статистики базы данных SQL Server критически важно. Мы рекомендуем обновлять статистику не реже одного раза в день, особенно для часто изменяемых таблиц. Ваша ситуация, когда обновление статистики занимает 5 часов и происходит редко, является серьезной проблемой. Мы можем рассмотреть возможность оптимизации процесса обновления статистики, например, обновлять статистику только для измененных таблиц или использовать инкрементальную статистику. Оптимальная частота должна быть определена экспериментально, исходя из интенсивности изменения данных.
   • Опции обновления: Использование опции WITH FULLSCAN при обновлении статистики обеспечивает максимальную точность, но может быть ресурсоемким. Мы можем попробовать комбинировать FULLSCAN для критически важных таблиц с опцией SAMPLE для менее значимых, чтобы сократить время выполнения.
   • Очистка процедурного кэша: После обновления статистики целесообразно очистить процедурный кэш SQL Server, чтобы запросы компилировались с актуальной статистикой. Мы можем выполнить команду DBCC FREEPROCCACHE.
2. Блокировки.
   • Причины: Избыточные блокировки могут быть вызваны множеством факторов:
     • Неоптимальная работа запросов, приводящая к сканированию больших объемов данных.
     • Методические ошибки в использовании объектов конфигурации 1С (например, блокирующее чтение остатков в начале транзакции).
     • Изменение большого количества данных в одной транзакции.
     • Внутренние механизмы СУБД, такие как распараллеливание процессов, которые могут создавать дополнительные блокировки при определенных условиях.
   • Инструменты диагностики: Для анализа причин блокировок мы будем использовать следующие инструменты:
     • Технологический журнал 1С: Позволяет отслеживать длительные транзакции, ожидания, блокировки со стороны 1С.
     • Средства мониторинга СУБД: SQL Server Profiler, расширенные события (Extended Events), Activity Monitor в SQL Server Management Studio. Эти инструменты помогут нам выявить запросы, вызывающие блокировки, их длительность и используемые ресурсы.
   • Решения: Мы можем рассмотреть следующие меры для борьбы с блокировками:
     • Повышение уровня изоляции транзакций в 1С (например, до READ COMMITTED SNAPSHOT), если это применимо и поддерживается конфигурацией.
     • Минимизация длительности операций и транзакций.
     • Разделение больших транзакций на более мелкие.
     • Оптимизация проблемных запросов, выявленных с помощью профилировщика.
3. Оптимизация запросов. Вы упомянули, что оптимизировали уже пучок запросов, но легче не стало. Это не означает, что оптимизация запросов бесполезна. Это скорее указывает на то, что существуют другие, более критичные узкие места в системе. Тем не менее, работа по оптимизации запросов должна продолжаться, так как она является фундаментом для стабильной работы любой высоконагруженной системы. Мы можем сфокусироваться на самых ресурсоемких запросах, используя данные из технологического журнала 1С и SQL Server Profiler.

2.3. Настройки сервера и аппаратных ресурсов

Ваш сервер, хоть и не новый (2x E5-2680, 128 ГБ ОЗУ, Intel RAID Controller RS2BL080), все еще обладает значительной мощностью. Однако, есть несколько аспектов, которые мы должны проверить.

1. Гипертрейдинг (Hyper-threading). Вы подтвердили, что Hyper-threading включен. Его влияние на производительность SQL Server зависит от рабочей нагрузки. Для OLTP-нагрузок (транзакционные системы, характерные для 1С) он может быть полезен, но в некоторых случаях (например, при большом количестве мелких запросов или неоптимизированных настройках) может приводить к снижению производительности из-за накладных расходов на переключение контекста. Мы можем провести тестирование производительности с реальной рабочей нагрузкой как с включенным, так и с выключенным Hyper-threading, чтобы определить оптимальные настройки для вашей конкретной системы. Microsoft утверждает, что SQL Server полностью функционален в среде с Hyper-threading, но рекомендует использовать последние сервисные пакеты и обновления безопасности.
2. Оперативная память. 128 ГБ ОЗУ для базы в 250 ГБ и 100 пользователей может быть достаточно, но мы должны убедиться, что SQL Server имеет достаточно памяти. SQL Server требует значительного объема оперативной памяти – в идеале не менее 2/3 от размера базы данных, чтобы кэшировать основные данные. Убедитесь, что для SQL Server не установлено жесткое ограничение по максимальному потреблению памяти, которое может мешать ему использовать доступные ресурсы.
3. Настройки BIOS. Помимо Hyper-threading, мы можем проверить другие настройки BIOS, которые влияют на производительность:
   • Отключение Intel SpeedStep/AMD Cool'n'Quiet: эти функции регулируют частоту процессора для экономии энергии, что может негативно сказаться на производительности под нагрузкой.
   • Включение Turbo Boost/Turbo Core: эти технологии позволяют процессору временно повышать тактовую частоту выше базовой, что полезно для однопоточных и многопоточных нагрузок.
   • Режим работы контроллера памяти и PCI-e шины.
4. Общий аппаратный апгрейд. Хотя NVMe может отложить необходимость полного апгрейда CPU и RAM, если дисковая подсистема была основным узким местом, мы должны помнить, что "древние Cheetah 15K6" могут быть серьезным узким местом. Мы можем рассмотреть возможность обновления дисковой подсистемы целиком, заменив старые HDD на современные SAS SSD или NVMe SSD, если это позволяет бюджет и инфраструктура.
5. Разделение ролей сервера. Для высоконагруженных систем мы можем рассмотреть разделение ролей сервера: отдельные серверы для SQL Server, сервера приложений 1С, и терминального сервера. Это позволяет более эффективно распределять ресурсы и изолировать проблемы.

Заключение

Решение проблем производительности — это итеративный процесс, требующий систематического подхода. Мы начнем с проверки некорректных показаний синтетических тестов для NVMe, затем перейдем к глубокой диагностике SQL Server (статистика, блокировки, запросы) и аппаратных настроек сервера (Hyper-threading, BIOS). Помните, что комплексная проблема требует комплексного решения, и последовательная изоляция узких мест приведет нас к стабильной и производительной системе.