помогите обосновать руководству (далёкому от ИТ) необходимость закупки нового оборудования.
Есть "минимальные" или "рекомендуемые" параметры для оборудования, под сервер предприятия 1С, SQL?
хотелось бы увидеть как официальные рекомендации, так и практические (последнее даже важнее)

с ув. наутилус

WildSery,

спасибо, экспертизу заказывать, да ещё и в москве пока не хочется.

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

Программист 1с,

давайте о технике подумаем ) зп дело вторичное )

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

А сколько строчек в документе? Делает ли он движения по бух. регистрам (это важно)
не по бух. регистрам. по другим регистрам делает. проблема в том, что начинается запись, производятся расчёты, потом записи "коммитятся". всё это держит следующие записи. т.е. проблему с самим документом тоже будем пытаться решать (либо разнести табличные чести в регистры, либо на несколько документов), но это дело времени, а очередь дисковую и блокировки наблюдаем сейчас.

DmitriyZ,

сейчас в базе 161642 документа данного типа
последние 5000 документов имеют такое кол-во строк (в среднем) в табличной части:
тч1 - 29
тч2 - 16
тч3 - 2
тч4 - 79
тч5 - 0
тч6 - 0

DmitriyZ,

последние 5000 документов имеют такое кол-во строк (максимально) в табличной части:
тч1 - 507
тч2 - 441
тч3 - 831
тч4 - 3026
тч5 - 61
тч6 - 45

DmitriyZ,

ну вот хотим предложить руководству "аренду" дисковой подсистемы. что бы оценить улучшения. но улучшения точно будут.

AHDPDmitriyZ,

Наверное надо что-то меня в подходе к проектированию БД. Сотни и тысячи строк в разных ТЧ одного документа, коих тысячи не есть гут :(.

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

AHDP,

вот и хочется понять сколько "раз" выиграет. всё равно, из проанализированных данных - самое узкое место - диски, дисковая очередь.

AHDP,

Жесткие диски: 6x 450GB Seagate 15k rpm 32MB Cashe SAS
Тип массива дисков: три Raid1

AHDP,

два дня назад был RAID10 (один диск, побитый на логические). сейчас разделили на три рейд массива.
очередь самая большая к лог. диску Д. на нем лежит tempdb.

WildSery,

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