помогите обосновать руководству (далёкому от ИТ) необходимость закупки нового оборудования.
Есть "минимальные" или "рекомендуемые" параметры для оборудования, под сервер предприятия 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,

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

AHDPТогда вам надо память добавлять в сервер а не на полку деньги тратить ;)

ЗЫ Что же вы там такое при проведении рассчитывате?
почему память? максимально память не загружается, понятно, что постепенно сиквел пытается выжрать всю память. но
с чего начался вопрос. сейчас
Процесор: Intel Xeon E5530 2.40Ghz (2 unit)
ОЗУ: 48 GB
про диски уже знаете. и вот финансовое руководство грит "аргументируйте покупку новых серверов". сошлись (между собой, разработчиками), что пока что самое узкое место - диски. и убедить потратить деньги ТОЛЬКО на диски будет проще, чем на весь новый сервак. + попутно переписывать узкие места.

Палянаутилус
про диски уже знаете. и вот финансовое руководство грит "аргументируйте покупку новых серверов". сошлись (между собой, разработчиками), что пока что самое узкое место - диски. и убедить потратить деньги ТОЛЬКО на диски будет проще, чем на весь новый сервак. + попутно переписывать узкие места.
Это хорошо что вы между собой договорились. серверу не забудьте сообщить что ему придётся быстрей работать а то вдруг он вас спалит!
какому серверу? стёб - хорошо, но хочется аргументов. при чём не айтишных.
вот мы говорим "будет быстрее" - вопрос "на сколько быстрее прирост, что это даст, может вообще не надо покупать"?... понимаете, у человека есть возможность (например) купить погрузчик новый. или сервер. вот как убедить, что сервер нужен. сразу весь сервер новый - "больно". хотим дисковую систему. неправильно думаем?

а какого размера у вас база, если озу 48гб?
116107,73МБ

AHDP,

т.е. таки вынести темп-дб на отдельные диски. возможно даже без зеркала?

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

AHDPНо если проблема в tempdb, то целесообразнее добавлять оперативки. Версию сервера огласите пожалуйста.
Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) Apr 2 2010 15:48:46 Copyright (c) Microsoft Corporation Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7600: )

AHDPОгласите пожалуйста модели контроллеров и структуру базы (с размерами) относящуюся к этому документу. Если вы не подрезаеете базу, то оперативки Вам должно хватать заглаза.
модели контроллеров узнаю.
структуру базы - это как?

AHDPПока крепнет ощущение, что вы при проведении лопатите "лишние" данные.
да. данных при записи (даже не проведении) рассчитывается очень много. перезаписывается.

RustamZzКакая конфа и какой режим управления блокировками данных?
Этот документ типовой или собственной разработки?
Блокировки в момент записи документа или все таки проведения?
самописка.
собственной разработки.
записи.

RustamZzЕсли конфа написана неаккуратно, то никакое вложение в железо не улучшит картину.
пытаемся улучшать где можем конфу.

просто ща активных пользователей ~600 днём. ночью до 100.

ЕВА 2000Ещё можно попробывать, темп-дб запихать на виртуальный диск в оперативной памяти, при таком его количестве...
(у нас трудится RamDisk Plus 8.0)
вариант!

наутилусЕВА 2000Ещё можно попробывать, темп-дб запихать на виртуальный диск в оперативной памяти, при таком его количестве...
(у нас трудится RamDisk Plus 8.0)
вариант!
хотя. не вариант. погорячился.
смотрите, по идее сервер ведь что может - всё в памяти держит. если уже не хватает - начинается использование темп-диби. так? если памяти "мало", да ещё откусить под темп.... ?

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

Что же у вас за документ-то такой? Неужели не возможно разбить его на части, и проводить отдельными кусками (подчинёными документами)?
был отдельными. ещё в 7. сейчас один, потому что логически так связано всё.

HoBTIDнаутилусAHDP,

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

AHDPА чем обоснованы записи и пересчёты при сохранении этого документа!?!?!?!

Какой объём информации из БД (сколько занимают таблицы, индексы и какой их процент обрабатывается) используется при записи, проведении документа? Это нужно для понимания куда девается память и что твориться с архитектурой базы.

ЗЫ И мне не совсем понятно, как пользователь вводит столь объёмный документ. Откуда беруться данные?
может не так выразился. при перезаписи документ перепроводится.
информацию по БД ща попробую достать.
этот документ создаётся полу-автоматически на основании других документов, потом пользователем правится, потом вносятся дополнительные данные. вобщем один из самых сложных документов в системе. (вкратце: маршрутные листы развозов на основании заказов на развоз)

HoBTIDнаутилусну совсем не использовать временные таблицы дюжэ сложно =(((
Что делать, лучше напрячь мозг, чем сервер.
Результат и вам и руководству больше понравится.

Временные таблицы действительно нужно использовать в 1 из 10 - 20 случаев, когда их используют.
ну может быть и так. попробуем и это направление оптимизации записать

AHDP,

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

HoBTID,

выше я писал размер базы

AHDP,

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