Проблема производительности 1С и MSSQL

Question

[axis_ua]

Имеется 1С Предприятие 8.2, 100 активных пользователей, работает в связке с MSSQL 2012, на двух физических серверах. В принципе скорость работы устраивает всех, но есть несколько пользователей, которые выполняют действия, требующие от базы выборки большого количества информации, и при этом крайне критична скорость выполнения (планирование закупок). Конфигурация сервера БД: hp dl380g8 (2хXeon E5-2650/128GB RAM/6xSAS 15k rpm). В планах переход на FC СХД, и покупка более производительного сервера. Как я понял, высокопроизводительный кластер на MSSQL сделать не получится. Подскажите, какие есть варианты наращивания производительности MSSQL?

Comments

[dbmaster]

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

[axis_ua]

они никому не мешают, работают долго с точки зрения пользователя, т.е. выполняется запрос 3-5 секунд, т.к. он большой, если выполнять те же действия, когда активных пользователей нет, но выполнение запроса происходит за 0.5-1 секунду, что очень даже приемлемо.

Answer 1

[xrd]

1. Дописать конфу так, чтобы в свободное время (ночью) регламентным заданием данные для тяжелых отчетов подготавливались, т.е. упрощалась структура данных, проводились расчеты. В результате человек будет получать уже сформированные данные. Судя по описанию — отчет не просто огромная простыня с данными и там есть что оптимизировать. Но 3-5 секунд — я бы не стал заморачиваться, у Вас пользователи разбалованы (=

2. Если у Вас конфа работает не в режиме совместимости — посмотрите агрегаты, возможно выиграете некоторое количество времени после настройки. Не требует конфигурирования.

Answer 2

[Ivan Arxont]

1. 1С очень критична к частоте процессора. Так что, чтобы делалось быстрее, нужно процессоров не больше, а мощнее :)
2. Попробуйте отключить hyper threading. В некоторых случаях с 1С даёт очень серьёзный прирост (шаманизм конечно, но помогает)
3. В своё время подобных товарищей (которым нужны были сложные отчёты) вывели в отдельную рбд. БД на raid-0 SSD (важнее была скорость, чем надежность и даже если бы упала, заново выгрузили бы из центральной). Ещё один плюс (но это был косяк нашей конфы и отчётов) — работа не мешает остальным в плане блокировок
4. настройки БД на скуле (к примеру infostart.ru/public/65955/ +коменты).
5. Если сервера разнесены, то как вариант заменить сетевые на 10G

А вообще надо садиться и смотреть счётчики производительности (как заметили выше) и устранять «бутылочное горлышко» — это может быть и проц, и оперативка (скулю сколько дай, всё съест :) ), и дисковая подсистема, и сетевая подсистема, и настройки софта.

Comments

[axis_ua]

По первому пункту, критично для сервера 1С или SQL? Конфигурация сервера 1С довольна скромна: 2xE5405, 12GB, 3xSATA 7k
3й пункт интересен, сколько SSD было, часто ли приходилось менять диски? Насколько значителен был прирост производительности?
По 4му пункту — все настройки еще пару недель назад сделал, по рекомендациям из статьи.
По 5му пункту, сервера соединены напрямую по 1G, мониторинг показал, что больше не нужно.

[Ivan Arxont]

Критично как раз для 1С (для скуля больше оперативка и дисковая подсистема). SSD было 4, за год заменили только один диск и то не от износа, а видимо от брака. Прирост вырос до 9 раз, но там отчёт очень большие данные поднимал, к примеру среднюю сумму покупки в день при количестве продаж в 4-6 тысяч, и так за месяц к примеру. То есть очень тяжелые отчёты связанные с большими дисковыми операциями. Если у вас идёт какой-либо расчёт, то тогда лучше в связку процессор+память копать.

[Ivan Arxont]

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

[axis_ua]

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

Answer 3

[shagguboy]

осмотреть счетчики производительности. сделать выводы

Answer 4

[dbmaster]

Варианты такие:

• Добавить CPU
• Оптимизация расчётов планов закупок (views, procedures, indexes)
• Materialized Views
• Вторичные таблицы и предрасчёт планов

Answer 5

[erp_shnik]

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