Планирую перевод УПП на скл (сейчас файловая)
Пока тестирую, кручу, верчу...
Интересует увеличение скорости проведения закрытия себестоимости (налоговый учет в частности).
На данный момент - это порядка 45 минут (причем как в файловом варианте, т.к. и в серверном).
База всего 3,5 Гига. Причем что характерно: проведения закрытия себестоимости начала 2009 года - 10 минут, конец года - 45 минут. Неужели УПП каждый раз просчитывает все данные?????
Хар-ки жедезки: 8 виртуальных процов xeon 2.49ггц, 12 Гб оперативы, с винтами - сложнее, пока всего два (если решим переходить - докупим).
Сервер 1С и sql стоят на этой железке.
На данные момент темпдб лежит там же где и система, там же лежит лог базы, файл базы лежит на другом винте. Вариаций по разным расположениям файлов рабочей БД и темпбд перепробывал множество, заметных изменений в производительности не заметил (с двумя винтами много не намутишь).
Включён режим pae, включён awe, на sql-сервере стоит минимум использовать 2гб, макс - 6 гб. Хотя вариантов с памятью так же использовано множество, в т.ч. и отключение awe и тп. Заметных различий также не обнаружено :-(
Кстати, как вы уже, наверное, догадались, платформа - 32-битная.
С удовольствием и безмерной благадарностью выслушаю ваши предложения.
Какие нужны замеры и тп - заказывайте, сделаю.
Ваще, у меня сложилось впечатление, что sql с своей задачей при данных параметрах справляется на отлично, главный затык в 8ке. Большую часть времени sql ваще не напрягает процессор, а вот процесс rphost грузит все время процессор на практически на 100%.
Главный вопрос: почему себестоимость начала года закрывается за 10 минут, а чем дальше к концу года - время растёт до 40 минут???
Пробывал секционировать таблицы затрагиваемых этим документом регистров - результат опять 0. Опять камень в оргод УПП?

З.Ы. Предвосхищая вопросы почему не стоят СП на sql: нет под рукой :-) Ставил сп3 английский (sql русский) - появились жуткие тормаза.

Dolter,
а чего вообще было терять время с СКЛ, если сразу сказали что разницы между скульным и файловым вариантами никакой
У меня такой уверенности нету. Откуда черпается ваша?

Siemargl,
Нужно выносить отдельно tempdb и следовать совету "каждому ядру свой tempdb"
На счет "каждому ядру свой tempdb" - сделано. Изменений в производительноти 0 (в моем конкретном случае).
На счет отдельно выносить - пока некуда. Покупать винты, а потом обнаружить, что это проблемы не решило - тоже вариант сомнительный.

из вагих слов в (0)
авторНа данный момент - это порядка 45 минут (причем как в файловом варианте, т.к. и в серверном).
[/quot]
Мой пример не очень показательный :-)
Если брать базу от 100 гигов, думаю, что разница будет. В серверном варианте хоть есть что подкрутить, "помаштабировать". В файловом - только железо.

Процесс sqlservr - % процент использования процессора макс 73, сред 2,6
Процесс rphost - % процент использования процессора макс 103, сред 97
Т.е. получается, что сервер 1С пользует процессор всё время на 100%!

Процесс sqlservr - ошибок станиц/сек макс 51, сред 2,28
Процесс rphost - ошибок станиц/сек макс 898, сред 30
И памяти не хватает серверу 1с?

Dolter
Не забывайте про "внутреннюю кухню", т.е. про код - соврешенству нет предела, всегда можно что-то улучшить.
ну это то относится к обоим вариантам))

DmitriyZDmitriyZ1) Ставим на скуль 3 сервис пак
2) Обновляем платформу до последней
3) Обновляем УПП до последней
4) Тестим все это дело

Сделайте сначала это! Потом будете проценты мерять.
ОК, ставлю всё что нужно качаться.
А пока жду ещё идей.

DmitriyZРАУЗ включен?
расшифруйте :-)
я в упп не силён (это же про неё?)

SiemarglDionX
На счет отдельно выносить - пока некуда. Покупать винты, а потом обнаружить, что это проблемы не решило - тоже вариант сомнительный.

Для tempdb достаточно и одного. Например поставить запасной (он то есть?)
Есть, завтра утром, пока ни кого не будет, подцепим. Спасибо за идею на счет запасного)))

DionXDmitriyZРАУЗ включен?
расшифруйте :-)
я в упп не силён (это же про неё?)

Нет, не включена.
Раскажите вкратце о её влиянии на производительность + что измениться в учете для бухов.

DmitriyZ,
dionx @ mail.ru

спасибо, пришло