Тормозит 1С v8

[master13]

Сервер на windows 2003 x64 R2, SQL Server 2005. Пользователи работают в 1С v8.1, кто терминально (RDP) на этом сервере, кто со своего компа. База весит 3.3 гига, свободного места на дисках много. Сервер является только терминальным и файл-сервером (роли).

Мониторинг производительности показывает, что идёт большой обмен данными в оперативной памяти и идёт небольшая, но почти постоянная запись на диск, иногда с большими пиковыми значениями. И такое же чтение. Процессор почти не задействован.

При копировании файлов (локально внутри сервера) сильно используется оперативная память, и как только она забивается под завязку, сервер начинает жутко тормозить. После окончания копирования оперативка постепенно освобождается, при этом продолжается запись на диск. Кеширование на запись отключено (соответствующая галочка в диспетчере устройств ставится, но не сохранятся), BBU не поддерживается RAID-контроллером.

Железо: 2x Xeon E5405, Supermicro X7DVL-3, 12gb DDR2, LSI SAS 3041X-R и на нём два RAID-1. Один массив на двух ST3300657SS (там OS, сам SQL с базой и логами) и два ST3320620AS (тут бэкапы), кондиционер и UPS есть.

Решил проверить, а связано ли торможение с работой из-под терминала. Поставил на компьютер пользователя 1С v8.1. При создании "отчёта мастера производственной смены", всё также тормозит, как и в терминальном доступе. По 30+ секунд (в среднем) думает над каждой галочкой. При этом наблюдается сетевая активность, которая меняется от 0 до 14% (на компе), и небольшая загрузка процессора. Комп: C2D E8400, 4 gb оперативки, сетка 100mbps, windows XP SP3 32 bit. В отчёте несколько десятков позиций, с ростом позиции торможение увеличивается. То есть первая позиция делается за ~ 8 секунд, вторая дольше и так далее. Как сказали сотрудники, тормозить стало после расширения ассортимента товара. То есть раньше позиций было меньше, и вроде как не тормозило. Также при создании отчёта ругается на отсутствие артикулов, иногда показывает окна об ошибках проверения товара.

Дело было в 9 вечера, локальная сеть не загружена, в базе сидел только один пользователь. Включение кеширования на запись в утилите к RAID-контроллеру проблему не решило (да, перезагружал). Делали три отчёта, один раз с включенным кешированием и два раза с выключенным - одинаково. В это время на сервере бэкапы не делались, и вообще ничего, кроме SQL не запускалось.

Несколько вопросов:

1) Какие шаги предпринять, чтобы хоть как-то ускорить процесс создания отчётов?
2) Может ли проблема быть связана не с сервером, а с самой базой 1С? Как проверить?

[GansXA]

Несколько вопросов:

1) Какие шаги предпринять, чтобы хоть как-то ускорить процесс создания отчётов?
2) Может ли проблема быть связана не с сервером, а с самой базой 1С? Как проверить?

1. Купить веревку и мыло (это для себя)
2. Купить пулемет (это руководству таблетки от жадности)

Ну а если по существу, то купите ПО SERVER 2008 R2 x64 и ставте на него SQL и базы 1С, а для Server 2003 x64 найдите комп и сделайте из него терминальный сервак - тем самым разгрузите работу HDD RAID-массива основного сервака.
И вопрос встречный RAID-1 - это запись с чередованием или зеркало? Иногда встречается путаница в этом вопросе с терминологией.
Если зеркало - тогда тормоза...
Если чередование - тогда ВЫ не боитесь что в один прекрасный день один из хардов глюкнет (у нас весь RAID-5 ушел на покой 30 декабря из-за работы местных электриков:mad:, а бекапов ничерта несталось из-за самонадеяности руководства фирмы IT-спецы вот такие:p:cool: - по русски сапожник, а сам без сапог:drinks:)

[CaptainZolch]

была такая проблема на УПП. бился долшо и упорно.для начала, делаешь ли ты переиндексацию табицы? какого объема лог?
У меня решилось так, разобрали RAID, разнесли по дискам (отдельно) систему, лог SQL, базу SQL и tempDB. производительность увеличелась в разы. так же, посмотри в консоли 1с, сколько у тебя процессов (должно быть не менее 4х).

[AlexRein]

Ну может уже не актуально, но все же видел не однократно, что такие тормоза случаются именно из-за Скуля.
Перейди на dbf и попробуй. Было только один раз но когда скуль упал и сказал что база нечитаема ну никак было ну далеко не до смеха, а с dbf ни разу.
А мало скорости GIGABYTE I-Ram вам в помощь, ну и что, что всего 8 Гб места, для баз больше и не надо, за то 266(300 МАХ) МБпс и скорость доступа 1 мс. Большенство народа так работает. Ну правда и бэкап базы В 12 и 18.

[CaptainZolch]

Ну может уже не актуально, но все же видел не однократно, что такие тормоза случаются именно из-за Скуля.

не со всем согласен. траблы бывают и из-за самой 1с. А на скуле база работает быстрее. www.sql.ru, там много чего на этот счет написано. грамотная настройка и обслуживание баз, а так же своевременый бэкап = проблем нет.

[AlexRein]

Ну поддерживаю, что тут возможно и сама 1С виновата, но судя по описанию:
"Как сказали сотрудники, тормозить стало после расширения ассортимента товара."
Больше склоняюсь к траблам в БД, ну или на край работа 1С с БД.
На счет скорости спорить не буду, как говориться имхо, тестировал несколько раз, dbf быстрее. Ну и на счет скорости выбрал I-Ram.
Проблем с бэкапом не имел и сам видел как скуль падал. Кому как нравиться конечно, предпочитаю старые топорные методы.
Я просто предлогаю попробовать, а результаты тут выложить, так для всеобщего познания.

[CaptainZolch]

афтар забил на тему... а жаль

[AlexRein]

А давайте тестилку для 1С заделаем, чтоб поочередно загружала железо разными задачами(обработка больших таблиц в памяти, заполнение бальшим количеством данных спавочника(работа ФС), запрос к справочнику(отбор, перебор данных, запросы), очистка справочника, ну и компоненты системы поочередно), а результаты по каждому из тестов выложим тут(с описанием и х-ками железа).
Получится маленький такой наглядный пример, можно будет выбрать, кому что лучше. От себя могу написать под 7.7.

[master13]

афтар забил на тему... а жаль

А меня уволили, поэтому и забил. Увольнение не связано с этим, они давно хотели, собирали косяки, чтобы придраться и не выплачивать лишние деньги. Например: не приехал на другой конец города, чтобы бесплатно отфотошопить картинки.

А касательно 1С - вызвали программиста, который нашёл множество косяков в самой базе. Изначально там что-то заполняли неправильно, и теперь, косяков стало больше. Бухи в курсе, и очень ждут светлого ума, который всё исправит. Ну, успехов им. А я теперь отошёл от этого.

ps дело не в железе и не в SQL, косяки в базе. Вот вердикт программиста.

[AlexRein]

А меня уволили, поэтому и забил.

Не ну сожалеем конечно что тут сказать. А руководство оно разное бывает.

А на счет косяков в базе, да это в принципе вполне возможно. Хотя в прочем если железо позволяет этого можно просто не замечать.

Вопрос на счет тестилки я так понимаю тоже потух?

Добавлено через 6 часов 45 минут 11 секунд
Кому если еще интересно, про тестер:

Накидал по скоренькой 2 простых теста.
1) Создает таблицу значений с 10 колонками, заполняет 1 млн строк случайно(Значения времени). Перебирает на предмет значений секунд и ссумирует, вычитает остальные колонки. Все просто.
2) Создает и записывает документ с 10 реквизитами шапки и табличной части, не заполняя. Потом все это удаляет. Так же все просто до не могу. В качестве фиксатора времени пользовал ВК.

Результаты дома на Е7400 разгон до 3150, 2 Гб оперативы, винт баракуда 500 Гб.
1) 147.761 сек; 2) 41.172 сек.
На работе все конечно лучше, но не так как ожидал. i7 950, 9 Гб оперативы, Винт I-Ram 8Гб.
1) 112.382 сек; 2) 0.461 сек.
Не адоптированность кода к х64 и много ядерности просто удручает.

Добавлено через 21 час 37 минут 58 секунд
Ну вот при использовании turbobl.dll домашние показатели улучшелись до 85.735 и 39.046 соответственно.