maljaev писал(а) 15. Апреля 2015 :: 10:38:


Начинать надо этим смотришь  длину очереди к дискам.
после
Все равно надо начинать с сервера - с железа.
у тебя должно быть как минимум
raid 1   для системы  ( 2 диска )
raid 10   для бд  ( 4 диска )
raid 1     для журнала транзакций ( 2 диска )
raid 1    для tempdb ( 2 диска )
т.е. как минимум 10 дисков

(а у тебя их 6 )
причем для ос стандартный размер сектора
для всех остальных размер сектора кратен 64К

Далее выставить на максимальную производительность твой raid
контроллер

trad писал(а) 15. Апреля 2015 :: 11:38:

Ты сам ответил на свой вопрос отвечая про батарейку. Это зависит
насколько "умный" контролер
Если контролер суперумный то выигрыш raid10 перед raid 1
в два раза
Если контролер тупой то raid10 по скорости равен raid 1

trad писал(а) 15. Апреля 2015 :: 11:38:


Почему на журнал транзакций raid 1 потому что журнал транзакций пишеться последовательно и уже не будет никакого выирыша для него от raid10 .
а бд случайный доступ с диску.

maljaev писал(а) 15. Апреля 2015 :: 09:00:


Посмотрел у себя - на самых тяжелых Z-ках (по 1200 строк) - примерно 15-20 сек. загрузка идет в Центр. базу.

установи sqlio
http://www.microsoft.com/en-us/download/details.aspx?id=20163

запусти

sqlio.exe -kW -t1 -s60 -f1 -b8 Х:\testfile.dat > res.txt
где Х: - диск где лог базы

покажет скорость записи одним потоком 8к блоков


на моем сервере
при -b8, MBs/sec: 103.24
при -b64, MBs/sec: 251.74

(0) перчитал твои посты еще раз.
Берешь ссылку (я не утверждаю что там истина в последней инстанции - ну я просто описал как делал у себя)
http://www.1cpp.ru/forum/YaBB.pl?num=1353441536

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

Как бы в теории все просто :
1.Сначала надо настроить макcимально железо и ms sql
2.После этого оптимизация sql запросов.

А на счет ускорения, то повторюсь. Z-отчеты хоть и долгие, но на общем фоне документов их вклад был не более 20%. Меня больше раздражало тормозное проведение документов "Регистрация счет-фактуры" и "Счет-фактура" после одного из обновлений релизов. Там ребята с Астора сменили алгоритм, и прежде чем перепроводить документ рассчитывают - какие движения документ может создать и сравнивают их с текущими движениями. Документ перепроводится только если будут изменения в движениях. Вот эта проверка и тормозит.
В результате запросы в модуле "ОмУчетНДС" переписал с

		|	ИЗ
		|		Документ.РасходнаяНакладная.Состав КАК Накладные
		|	ГДЕ
		|		Накладные.Ссылка В
		|				(ВЫБРАТЬ РАЗЛИЧНЫЕ
		|					ВЫРАЗИТЬ(Фактура.Основание КАК Документ.РасходнаяНакладная)
		|				ИЗ
		|					Документ.СчетФактура.Состав КАК Фактура
		|				ГДЕ
		|					Фактура.Ссылка = &Ссылка
		|					И Фактура.Основание ССЫЛКА Документ.РасходнаяНакладная
		|					И Фактура.Основание.Валюта = &Руб)
 

на

		|	ИЗ
		|		Документ.РасходнаяНакладная.Состав КАК Накладные
		|
		|		ВНУТРЕННЕЕ СОЕДИНЕНИЕ (ВЫБРАТЬ РАЗЛИЧНЫЕ
		|				ВЫРАЗИТЬ(Фактура.Основание КАК Документ.РасходнаяНакладная) КАК Расходная
		|			ИЗ
		|				Документ.СчетФактура.Состав КАК Фактура
		|			ГДЕ
		|				Фактура.Ссылка = &Ссылка
		|				И Фактура.Основание ССЫЛКА Документ.РасходнаяНакладная
		|				И Фактура.Основание.Валюта = &Руб) КАК Условие
		|			ПО Накладные.Ссылка = Условие.Расходная
 

(в этом модуле подобных кусков много, по разным видам документов и проч. - поэтому детально не указываю).
Прирост порядка 50 раз.

Z1 писал(а) 17. Апреля 2015 :: 15:19:

Счф не на Z-отчет, а на остальные документы, типа "Возврат поставщику" или "Реализация" стороннему юр. лицу. Кроме того - аналогичный код отрабатывает и на полученных Счф от Поставщиков. Все в сумме приводит к сильному падению производительности.
Вот, еще пример, жутко тормозила обработка "Управление ценообразованием" при открытии. Запускалась минут 15 на наших данных.
Чуть подправил элементарный кусок запроса с:
Цитата:

на
Цитата:

и обработка стала запускаться за 10 секунд.