1c sql & кластер - возрастет ли производительность?

[jvl]

Добрый день, уважаемые!
В нашей организации используется MS SQL 2000 EE и 1с 7.7 sql.
Одновременно работает до 140 пользователей.
Можно ли ожидать повышения производительности при внедрении кластера?
Или за счет того, что сервера должны оповещать друг друга об изменениях время выполнения транзакции возрастёт?

Вадим

[a_shats]

Нет. Дело в том, что в Windows 2000 и 2003 предусмотрен только fail-over cluster (т.е. тупое поднятие на standby сервере сервисов другого-упавшего) - и все .
Надежность - да, улучшится.
Что же касается повышения производительности - распишите конфигурацию текущего сервера, посмотрите, где "узкие места" - perfmon'ом, напишите здесь - попробуем что-нибудь порекомендовать.

[gs]

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

Кстати, кластер требует внешнюю дисковую систему, которые как правило намного мощнее внутренних. Так что возможен рост скорости из-за этого "вторичного" фактора.

[jvl]

Сервер такой:
2 xeon 2,4 ГГц, 3 Гб ram, мама SuperMicro P4DL6, raid 5 Adaptec 2000s, hdd IC35L018USD210-0
Обращений к дисковой подсистеме мало, в основном загружены процессоры.
Когда загрузка (на несколько минут) превышает 60..70% - клиенты начинают жаловаться на блокировки (наверное, из-за роста времени выполнения транзакций).
Для отчетов держим второй сервер близкой конфигурации с xeon 1,6 ГГц.
Но замучили частые падения репликации с кодом ошибки 9004.
Из-за чего - не понимаем. За последние пару лет поменяли всё - и железо и софт.
Есть ощущение, что по мере подъёма производительности железа репликация падает чаще. Консультировался на sql.ru - выполнил рекомендации - вначале показалось - реже падает. Теперь не кажется.

[a_shats]

1. Указанный характер нагрузки говорит о, скажем так, не совсем корректном построении запросов (молотится многократно относительно малый объем данных, сравнимый с объемом кэша RAID). При нормально построенных запросах нагрузка раскладывается - относительно равномерно - на все компоненты сервера (процессор (%загрузки) - память (объем) - дисковая п/с (длина очереди обращений)).
2. Откуда берутся блокировки: это, выходит, у Вас 1С ? Ну, там все просто: "не зная" о том, что на другом конце (SQL или "просто" файлы) 1С при записи (проведение документов-> обновление регистров) блокирует таблицы целиком, о чем пишет в файлик *.lck . Остальные пользователи получают сообщение типа "идет транзакция". На самом деле, SQL способен выполнять блокировки на уровне строки.
Т.е., возможно, среди прочего, у Вас отключен WB кэш на Transaction Log MSSQL-а. Верно ?

[jvl]

1. Изменить характер нагрузки я конечно не могу (Как бы не плоха была 1с - мне с ней всё равно придется жить.). Памяти ms sql съедает естественно всю какую может - а именно 2 786 640 К. Average disk queue length - не более 35 (пики изредка).
2. 1с построена так - что таблицы блокируются целиком в основном при добавлении новых строк. Плохо, что перегружена таблица 1sjournal.
Она использует и блокировки SQL и файл *.lck (кот. у нас лежат на нетвари)
wb кэш у нас включен.
Размер базы - 5,5 Gb

[gs]

По репликации сказать ничего не могу - не спец. Но насколько наслышан, вещь сама по себе не совсем стабильная.

По серверу - может быть разделить сервер приложений (1С собственно) и SQL? Это самый прозрачный путь повышения производительности. Можно держать их на разных нодах кластера, если нужна ЕЩЕ и отказоустойчивость. Но можно и просто два сервера.
Можно четырехпроцессорную машину поставить, но два двухпроцессорника намного дешевле обойдутся. Но на всякий случай посмотрите перфмоном соотношения процессорной нагрузки SQL и 1С. Если поровну - ставьте два сервера. Если один из них ест львиную долю - тогда только четырехпроцессорка.

Увеличить производительность одной базы в варианте микрософта за счет кластеризации не выйдет. Придется делить базу на части, которые будут обрабатываться на разных нодах кластера. Мне кажется, что это Вас не устроит. Делить нагрузку между узлами умеет только Oracle RAC.

[gs]

Извиняюсь - я почему-то безосновательно решил, что 1С в терминале.

Имхо вам надо четырехпроцессорную машину. По цене это будет примерно так же как и кластер (15-30тонн). Но в отличие от него заведомо даст прирост скорости.

[gs]

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

[jvl]

Да мы всегда по ночам восстанавливаем репликацию - если упала - при этом на втором сервере всегда получается как минимум вечерняя база.
К сожалению нам этого не достаточно - по второму серверу работают операторы многоканального телефона, интернет (онлайн-прайс). Опять же душу грело наличие копии с задержкой в ~5 с.
Новый сервер мы планируем собирать где-то в марте. Смысл собирать конечно есть - если можно удвоить производительность.

[a_shats]

Комментарий: 1С НЕ использует блокировки SQL. Она обращается к нему через ODBC и попросту "не знает", что на другой стороне .
1С 7.7 таки использует собственные блокировки. Механизм блокировок MSSQL срабатывает по-любому - это да, но - таки независимо от 1С.
Изменить характер нагрузок - Вы, может и нет, а программеры (1С-ники)- могут , хотя работы немало будет - это да. Например, аналитику (счета) можно вынести на OLAP-кубы. Для регистров использовать т.н. "быстрые регистры" (от third-party производителей софта), которые вполне корректно работают с SQL. Это все, конечно, потребует затрат денег и времени, да и 1С 8 на подходе... Возможно она как-то решит Вашу проблему.