В УПП  около 130-150 аткивных пользователей - размер БД 180 гигов.   сейчас вижу тонкое  место именно дисковое пространство.

PS:    оперативы  сейчас 32 Гига. планирую прокачать до 128.

10+

(1)   10  это рейд, а что такое  50?

(0)
0,10

(5)   вот это непонятно : "контроллер с >=512 мегабайтами кэш + 6 рейд."  ОЗУ   уже сейчас  как  я понимаю  уписывается в норму :-)  но я думаю что 32   мало для таких объемов БД. но если  прироста  от увеличения  ОЗУ не будет скажите  я лучше дисков больше куплю.

На данные 10. темп дб 10, лог можно на 0. Патом можно индексы вынести на отдельный массив

(9) Есть же счетчик хит кєш рейтинг который показывает достаточно ли ОЗУ

(7) 5+0
Так же как и 10 = 1+0
У нас 1+0. Вроде довольны.

(7)  бгг, а ты кто вообще админ или уборщица?

(9)
тогда уж кэш до гига докупите.

при таких объемах конфигурация рэйда любая
просто 6-й престраивается быстрее.+ незабыть запасной диск

нужно читать форумы о контроллерах.
есть варианты при дисках > 4 либо > 8 > 16
тормозящих.

(11) +1
(0) только поправка - надо проверить насколько эффективен кеш для скл, диски скорее следствие и не факт что сможете рейд Ом закрыться. Не надо соотносить размер бд и размер озу, это неправильно.
П.с. вы видите узкое место, но почему то не ищите причину

2 рэйд 10. Если бабки есть.

ССд из дисков еще прикольнее.
Но там запасных сразу купить штуки 3

почему 2 рэйда? под данные и логи разные.
Для темпа наверное уже жирно еще один.

ну и система на рэйд 1

(0) я думаю 10 вполне достаточно

(11)   а где сие чудо (хит кєш рейтинг) посомтреть

(13)  я админю 1с  мне  тяжеловато с конфигурацией.

(15)  с удовольствием  поучусь искать причину, как проверить " проверить насколько эффективен кеш"  ?

(14) А чем 6 уровень лучше 10?

(0)а как тс определил что узкое место диски?

(22) в мониторе  скорость  обмена  достигает 180 Мб/с кажется  и упирается.

(23) А сейчас-то как организована дисковая система?

(24)  админ  утверждает что зеркало

(25) в перфмоне счетчики "cache hit ratio" и "buffer cache hit ratio" в разделе SQL:memory manager

нашел perfmon - я как лох пользховался монитором ресурсов :-(   а вот :  счетчики "cache hit ratio" и "buffer cache hit ratio" в разделе SQL:memory manage   не нашел :-(    подскажит еплз как найти

http://s1.ipicture.ru/uploads/20130226/8iTRTOXJ.jpg

(26)  это конечно круто :-), но как найцти  эти данные у меня  - вот в чем был вопрос :-)

(29) на скуль сервере - добавить счетчики - дальше по скриншоту

(30)   ок.    а можно узнать что из этих цифирь следует?

(0)
1.система на отдельный массив дисков
2. данные на отдельный масив
3. лог на отдельный массив
4. темп на отдельный массив
5. бекап на отдельный массив

(31) первая должна быть в идеале 100, но в самых плохих случаях не меньше 96-97-98.. как-то так.
вторая - просто общий объем памяти, который sql забрал под себя

вообще, если первая меньше 100, то уже означает, что оперативки для текущих объемов баз - не хватает

(32)   1,2,3 и 5   понятно   , а где  настраивается  расположение tempdb  ?

(31) Найдите счетчик Page life expentancy - его значение (в первом приближении) равно средней длительности нахождения страницы данных в кеше (в секундах). Чем больше, тем лучше - когда все хорошо выглядит пилообразно (рост, потом небольшое падение и т.д.) Значение не должно опускаться и быть долгое время менее 300 с (5 минут) - следовательно, кто-то из кеша страницы выдавливает.

настроил  - пособирал 5 минут

http://s1.ipicture.ru/uploads/20130226/aAVYSrmf.jpg

(37) Интересна динамика (график) и где Page life expentancy?

(0) настраиваешь из максимума количества дисков (которое поддерживает рейд-контроллер и позволяет бюджет) один рейд 1+0, его делишь на LUNы каждый для своей нужды, например как в (32). Вообще рекомендую почитать теорию про рейды, от чего в них зависит скорость чтения и записи - станет все намного яснее, масса вопросов уйдет.

+(39) тут еще надо учитывать важный момент про соотношение операций записи или чтения, которое у тебя будет с базой, то есть от того, что пользователи больше делают в УПП.
И еще про дисковую подсистему много написано в MS TechNet в документации по MS SQL, также рекомендую ознакомиться, чтобы понимать принципы, а не гадать на кофейной гуще.

(38)  ща все будет

(38)
http://s1.ipicture.ru/uploads/20130226/ZxUhUIw9.jpg

Page life expentancy

(39)(40)   хотелось бы знать  вообще из практики сколько оперативы нужно и как понять что она нужна tit? и сколько ее нужно. диски нужны оператива нужна, но и того и второго в достатке не пробью я сейчас.

про рейды все понял, какую инфу, где искать и что читать.  как определить минимальный  и нормальный объем ОЗУ на SQL сервере?

(42), (43) - про память для SQL читай там же. Хотя принцип простой - чем больше, тем лучше. Хотя с другой стороны еще крайне важный момент скорость процессора.
На самом деле лучше тебе в поисковиках посмотреть про обзоры, сравнения, тесты и т.п. Есть масса информации о влиянии конкретных параметров железа на быстродействие и в общем и применительно к 1с. Возможно необходимо поработать над сервером 1с, а не над sql, ведь все работает в связке.

зеркальный рейд

(42) Это PLE - на картинке другие счетчики?
Но если у PLE такие значения минимальные, то теперь надо проанализировать какие запросы приводят к этому (то есть вытесняют данные из кеша).
Для этого профайлер SQL запустить надо и в запросах ориентироваться на колонку Reads (логические чтения).
Чем число больше для запроса, тем он существеннее на кеш влияет. Из профайлера SQL должен собрать информацию по таким запросам и их анализировать (по индексам, плану выполнения). Из практики: отбираешь запросы с большим 1 млн. reads.

(32) локальный бэкап можно хранить на обычном диске.

Нифига не понимаю, зачем смотреть счетчики, когда и так понятно,
что УПП на > 100 пользователей, на зеркале работать нормалаьно не может.

Кроме файлов своей базы 1С может нехило грузить tempdb на больших запросах. По сути в ней хранятся временные таблицы и при выполнении запроса идет запись в эту БД.

+47 Подробнее так:
1. система - на зеркале (2 диска).
2. данные - на 10м рейде (4 диска).
3. лог - на 10м рейде (4 диска).
4. темп - на отдельном рейде. Тут возможны варианты. Можно на обычный диск. Можно прикрутить РАМ-диск и в настойках SQL указать в качестве первого пути - рам-диск. В качестве второго - диск. (считаем по-максимум, 4 диска).
5. бекап на отдельный диск. (Один диск).

Итого: 16 дисков (один запасной).

(23) Очередь к HDD есть? Уверен на 100%, что есть.
128 оперативы на сервер в наше время - это минимум. 32 - это обычный десктоп.

(50) Чем два 10-х раида по 4 диска, лучше 1 1-го раида на 8 дисках?

(52)+
Чем два 10-х раида по 4 диска, лучше одного 10-го раида на 8 дисках?

(48) Счетчики смотрят, чтобы как раз понимать что происходит и что необходимо делать. "УПП и количество пользователей больше 100" - слишком большой уровень и не о чем не говорит, кроме организации работы.
На мой взгляд план анализ должен быть следующий:
1. Смотрим на счетчики (показатели системы) по диску, процессору, сети, памяти (кеш).
2. Если диск узкое место (очереди огромные), это не значит что надо покупать новое СДХ (не на этом этапе анализа), посмотреть причину.
3. На сервере СУБД (как правило) причина в "проседании" кеша (по графику PLE выше), но пока из этого нельзя сказать, что надо покупать ОЗУ дополнительное.
4. Посмотреть кто вытесняет данные из кеша, окажется есть ряд запросов, которые неоптимальны по READS. Останется оптимизировать запросы.
А дальше:
- Не запросов тяжелых, кеш не проседает, диск не тормозит.

Я не говорю, что покупка диска или доп. ОЗУ не повлияет на ситуацию, но большая вероятность, что улучшение с таким подходом будет недостаточное.

Другая ситуация - если все оптимально по запросам и алгоритмам, но информационный поток на сервер БД огромный и диски не выдерживают, то оптимизируют СДХ и прочее.
1С создает 95% нагрузки на чтение, 5% на запись. Скорость чтения очень сильно зависит от кеша СКЛ, а скорость записи - от диска.

(54) Для такой работы квалификации ТС может и не хватить, значит нужно будет привлекать исполнителя. Возможно его придется привлекать при каждом обновлении УПП.

С другой стороны разовое вложение в железо.
Если ТС в столице, то можно взять сервер на прокат
и провести нагрузочное испытание.

(55)  ни понял при чем тут обновление УПП.

квалификация  такая  вещь  , ее можно наращивать.

Подскажите какие счетчики поставить чтобы определить очередь на чтение с дисков?  замерю выложу данные

(46)  на картинке PLE  некрасиво?

займусь  профайлером  сейчас.

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

(57) поддерживаю, именно об этом я и говорил еще в (39).

(57) Теоретически все верно, но есть ньюансы (с). Тут встает вопрос что там за контролер и как он настроен. Вполне возможна ситуация, когда число шпинделей увеличили вдвое, а скорости чтения и записи не возрасли (а возможно даже упали), потому что узким местом является сам контролер (или слабый сам по себе или настройки выставлены кривые). В мощных контролерах настроек чуть менее чем дофига, многие уникальны для данной фирмы и модели. Настройка "крутых" дисковых массивов - это отдельная специальность, причем с заточкой под конкреного производителся, помимо "общей теории рэйдов" требуется изучение фич и багов конкретных моделей девайсов - в обшем все как у всех.
А вот поставив еще один точно такой же контролер и распредлив файлы между ними, ты рискуешь только в призводительность системной шины уперется, а так хоть какой-то эффект гарантирован.

(59) Не обязательно RAID-контроллер самому настраивать.
Пусть поставщик настраивает.

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

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

(62) Ну если брать с IP KVM, проблем с доступом к специалисту не будет.

(62) имхо - через >|<опу как-то - наращивание числа контроллеров.

(64) Наличие IP KVM - возможность удаленного доступа, что не гарантирует
1) Наличия бюджета на оплату специалиста.
2) Доступа к грамотному и ответсвенному специалиста.
3) Наличия разрешения от безопасников на удаленный доступ.

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

отсортировал в Profiler  reads на более миллиона
за 15 минут  вылезло 10 строк.
7 из них статусом  -  Audit Logout
2 SQL:BathCompleted

и на этот момент уже  
3 RPC:Completed
уже   5 - RPC:Completed   2,1 миллиона записей :

exec sp_executesql N'INSERT INTO #tt146 (_Q_000_F_000RRef, _Q_000_F_001) SELECT
T1._Fld21426RRef,
T1._Fld21422
FROM _InfoRg21421 T1
WHERE (T1._Fld21424RRef = P1)',N'P1 varbinary(16)',0xA09D9FE5517B4DF649D47CC439FDDCA4

вот пример SQL:BathCompleted  на 3 миллиона записей, вопрос  как выдернуть этот запрос в 1с

exec sp_executesql N'INSERT INTO #tt3 (_Q_007_F_000RRef, _Q_007_F_001RRef, _Q_007_F_002RRef, _Q_007_F_003RRef, _Q_007_F_004) SELECT
T1._Q_000_F_000RRef,
T1._Q_000_F_001RRef,
T1._Q_000_F_002RRef,
T1._Q_000_F_003RRef,
CASE WHEN (ISNULL(CAST(T2.Q_006_F_002_ AS NUMERIC(38, 8)),0.0) >= ISNULL(CAST(T2.Q_006_F_003_ AS NUMERIC(27, 3)),0.0)) THEN (T1._Q_000_F_004 + CAST((CAST(ISNULL(CAST(T2.Q_006_F_003_ AS NUMERIC(27, 3)),0.0) AS NUMERIC(38, 8)) - ISNULL(CAST(T2.Q_006_F_002_ AS NUMERIC(38, 8)),0.0)) AS NUMERIC(38, 8))) ELSE T1._Q_000_F_004 END
FROM #tt2 T1 WITH(NOLOCK)
LEFT OUTER JOIN (SELECT
T3.Q_001_F_000RRef AS Q_006_F_000RRef,
T3.Q_001_F_001RRef AS Q_006_F_001RRef,
CAST(SUM((T3.Q_001_F_002_ + CAST(ISNULL(CAST(T5.Q_003_F_002_ AS NUMERIC(21, 3)),0.0) AS NUMERIC(38, 8)))) AS NUMERIC(38, 8)) AS Q_006_F_002_,
CAST(SUM(ISNULL(CAST(T9.Q_005_F_002_ AS NUMERIC(21, 3)),0.0)) AS NUMERIC(32, 8)) AS Q_006_F_003_
FROM (SELECT
T4._Q_000_F_000RRef AS Q_001_F_000RRef,
T4._Q_000_F_001RRef AS Q_001_F_001RRef,
CAST(SUM(T4._Q_000_F_004) AS NUMERIC(38, 8)) AS Q_001_F_002_
FROM #tt2 T4 WITH(NOLOCK)
GROUP BY T4._Q_000_F_000RRef,
T4._Q_000_F_001RRef) T3
LEFT OUTER JOIN (SELECT
T8._Fld21906RRef AS Q_003_F_000RRef,
T8._Fld21907RRef AS Q_003_F_001RRef,
CAST(SUM(T8._Fld21913) AS NUMERIC(26, 8)) AS Q_003_F_002_
FROM (SELECT
T7._Q_000_F_000RRef AS Q_002_F_000RRef,
T7._Q_000_F_001RRef AS Q_002_F_001RRef
FROM #tt2 T7 WITH(NOLOCK)
GROUP BY T7._Q_000_F_000RRef,
T7._Q_000_F_001RRef) T6
INNER JOIN _AccumRg21903 T8
ON ((T6.Q_002_F_000RRef = T8._Fld21906RRef) AND (T6.Q_002_F_001RRef = T8._Fld21907RRef))
GROUP BY T8._Fld21906RRef,
T8._Fld21907RRef) T5
ON ((T3.Q_001_F_000RRef = T5.Q_003_F_000RRef) AND (T3.Q_001_F_001RRef = T5.Q_003_F_001RRef))
LEFT OUTER JOIN (SELECT
T12._Fld22228RRef AS Q_005_F_000RRef,
T12._Fld22229RRef AS Q_005_F_001RRef,
CAST(SUM(T12._Fld22233) AS NUMERIC(26, 8)) AS Q_005_F_002_
FROM (SELECT
T11._Q_000_F_000RRef AS Q_004_F_000RRef,
T11._Q_000_F_001RRef AS Q_004_F_001RRef
FROM #tt2 T11 WITH(NOLOCK)
GROUP BY T11._Q_000_F_000RRef,
T11._Q_000_F_001RRef) T10
INNER JOIN _AccumRg22225 T12
ON (((T10.Q_004_F_000RRef = T12._Fld22228RRef) AND (T10.Q_004_F_001RRef = T12._Fld22229RRef)) AND (T12._RecordKind = P1))
GROUP BY T12._Fld22228RRef,
T12._Fld22229RRef) T9
ON ((T3.Q_001_F_000RRef = T9.Q_005_F_000RRef) AND (T3.Q_001_F_001RRef = T9.Q_005_F_001RRef))
GROUP BY T3.Q_001_F_001RRef,
T3.Q_001_F_000RRef) T2
ON ((T1._Q_000_F_000RRef = T2.Q_006_F_000RRef) AND (T1._Q_000_F_001RRef = T2.Q_006_F_001RRef))
WHERE (CASE WHEN (ISNULL(CAST(T2.Q_006_F_002_ AS NUMERIC(38, 8)),0.0) >= ISNULL(CAST(T2.Q_006_F_003_ AS NUMERIC(27, 3)),0.0)) THEN (T1._Q_000_F_004 + CAST((CAST(ISNULL(CAST(T2.Q_006_F_003_ AS NUMERIC(27, 3)),0.0) AS NUMERIC(38, 8)) - ISNULL(CAST(T2.Q_006_F_002_ AS NUMERIC(38, 8)),0.0)) AS NUMERIC(38, 8))) ELSE T1._Q_000_F_004 END > P1)', N'P1 numeric(1,0)', 0

(0) Зеркало на систему, 10-ку на файлы бд, SSD или 0 на TempDB

сейчас вот пробежал Audit Logout  с 13 миллионов записей !!  

что это за чудо событие  с таким  кол-вом чтений

(70) Audit Logout собирать не надо, это READS всей сессии.
Надо собирать только RPC:Complete и Batch:Complete.
"На 3 млн. записей" - это в колонке READS 3 млн.?

"exec sp_executesql N'INSERT INTO #tt146 (_Q_000_F_000RRef, _Q_000_F_001) SELECT
T1._Fld21426RRef,
T1._Fld21422
FROM _InfoRg21421 T1
WHERE (T1._Fld21424RRef = P1)"
Какого размера таблица _InfoRg21421 ?
+ Duration, CPU - тоже интересны колонки по нему.

Один хрен запросы в 1С встречаются чудовищные, всё не перепишешь.
В любом случае - добавлять ОЗУ и ставить RAID 10 с кэшем.

(71)  конечно READS   сказали куда обращать внимание  туда и смотрю.    

сейчас гляну на таблицу  "_InfoRg21421"

(73) практически всегда из-за того, что не могут обнаружить запрос - покупают оборудование. Потратить 2 часа на анализ, проиндексировать поле и проблема будет решена.
Все переписывать не надо (и все запросы), обычно проблемы сосредоточены в очень ограниченном списке запросов (3-5), на них направить силы и ресурсы.
Это как в медицине: болит голова у человека (возможно это следствие), вместо того, чтобы найти причину - ну, так давление улучшить, сердце полечить, пьют таблетки от головы и "вроде" как не болит. Эффективность такого "лечения" похоже с рассматриваемой ситуацией.

(74)
Тогда пишите корректнее (68)
"вот пример SQL:BathCompleted  на 3 миллиона записей, вопрос  как выдернуть этот запрос в 1с " - ваша фраза. При чем тут записей?
Запись если что Write, а чтение Read)))

О_о
через 10 лет,
1Сики понял, что нужен 10 рейд
это успех

(77) Ну, 10 лет назад и зеркала хватало.

RPC:Completed  
CPU - 13353  
Reads - 3.3 миллиона
Duration - 2340


exec sp_executesql N'SELECT
T1._IDRRef
FROM _Reference263 T1
WHERE T1._Fld3686RRef IN
(SELECT
CASE WHEN T2._Q_001_F_000_TYPE = P1 AND T2._Q_001_F_000_RTRef = @P2 THEN T2._Q_001_F_000_RRRef ELSE @P3 END AS Q_002_F_000RRef
FROM #tt67 T2 WITH(NOLOCK))
GROUP BY T1._IDRRef',N'P1 varbinary(1),@P2 varbinary(4),@P3 varbinary(1)',0x08,0x0000016F,0xFF

+ (76)

SELECT
T1._Fld21426RRef,
T1._Fld21422
FROM _InfoRg21421 T1
WHERE T1._Fld21424RRef = 0xA09D9FE5517B4DF649D47CC439FDDCA4

Выполните в Management Studio , как долго, сколько строчек вернет и сколько READS будет (профайлер фильтруйте по спиду MS)

(78) они 10 лет подряд 5й предлагали, если вообще понимали о чем речь

_InfoRg21421

1 621 325 записей
1 000 621 зарезервировано кб
346 800  данные
646 784  индексы
7 024  не используются

DBCC SHOWCONTIG('_InfoRg21421')

Выполните под правами админа и скиньте эту информацию в ветку

(82)
Там запрос надо выполнить в (80) пункте.

(75) "обычно проблемы сосредоточены в очень ограниченном списке запросов (3-5)"
Это какие-то совсем запущенные случаи, тогда бы автор прибежал с конкретными документами/отчетами.
В УПП столько таблиц используется, что любое проведение документа - тяжелая операция с несколькими десятками таблиц.

(84)  ну я обещал  описать объем  таблицы  я описал :-)

80  ща попробую исполнить,   пока не совсем знаю  как но приложу все усилия :-(

83  как я понимаю  исполнять там же  где и 80

DBCC SHOWCONTIG scanning '_InfoRg21421' table...
Table: '_InfoRg21421' (466204811); index ID: 1, database ID: 43
TABLE level scan performed.
- Pages Scanned................................: 43350
- Extents Scanned..............................: 5588
- Extent Switches..............................: 7670
- Avg. Pages per Extent........................: 7.8
- Scan Density [Best Count:Actual Count].......: 70.64% [5419:7671]
- Logical Scan Fragmentation ..................: 23.73%
- Extent Scan Fragmentation ...................: 80.42%
- Avg. Bytes Free per Page.....................: 1788.4
- Avg. Page Density (full).....................: 77.90%
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

(87) Переиндексацию таблиц давно делали? Судя по статистике - давно. Надо сделать переиндексацию (в частности этой таблицы), но сначала выполнить (80) и сведения до нее мне прислать.
(85) Это иллюзия, что проблем бесконечно много, запросов конечно не единицы, но... групп запросов не много (3-5). Чтобы было понятнее - есть ряд запросов в 1С (то есть запросов одного и того же вида), которые влияют на ресурсы, в том числе и диск 20,30,40%.
И к нам приходят очень большие клиенты с проблемами производительности, поэтому для меня это очевидно.

+ (88) - переиндексацию только в нерабочее время)

+ (88) с ребилдом

(80) отработал 3 секунды  вернул 494958 строк.  reads не отловил.  не проскочил он в профайлере . там сейчас апликейшн нейм    никто  кроме 1cv82 server  не появился.   а я в студио от sa

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

Реорганизация индекса раз в сутки
обновление статистики раз в сутки
перестроение индекса раз внеделю

SQL:BathCompleted   - понятно  это запрос
а что есть RPC:Completed  ?
строчек  раз два и обчелся  а объемыы.

"InfoRg21421"    "РегистрСведений.Штрихкоды"

мы с ним  действительно очень активно работаем.  я ведь могу  индексировать время от времени именно этот регистр?  как  это в консоли sql сделать ?   не думаю  что один  РС   будет долго индексироваться

выцепил SQL:BathCompleted  на 29 миллионов  записей.    остались мелочи перевести его в 1с и идентифицировать :-(

(94) Запросы на скл можно двух видов отправлять: RPC:Completed один из них. Обычно когда sp_executesql

(95) Как часто изменяются данные в этом регистре?

(96) Давайте еще раз поясню как надо поступать:
1. Собираете трассу по фильтру READS более 50000 целый день.
2. Сложно, но можно - определить по группам запросы одного вида (для этого можно использовать первую часть запроса) и оценить их затраты на READS,CPU (например, 25% READS приходится на запросы одного вида).
3. Выбираете группу с максимальным потреблением и с нее начинаете .
4. Анализируете конкретный запрос - аналогично выше рассмотренному запросу.

ПО (95)
Часто запрос выполняется по штрихкодам (оценить его вклад в нагрузку требуется п.2. выше)? Смысл запроса не ясен - зачем в виртуальную таблицу копировать треть всех записей!!!?

3 гибридных RAID 10 (из 8 дисков каждый), один под систему, второй под базу, третий под логи. Тока понадобятся специальные контролеры которые умеют работать с SSD и HDD.

(98) + ну и естественно SAS интерфейс

(97)  дописываются постоянно как при проведении заказ покупателя  так и при раскрое материалов.  каждому куску по штрихкоду.  целесообразность попробую понять.

(100) если не разберетесь, то обращайтесь, есть бесплатное экспресс - обследование, можно сделать более глубокий анализ: softpoint.ru

спасибо буду иметь в виду.  обращусь скорее всего в любом случае  , как минимум чтобы сверить результат. квалификация  как уже упоминалось :-)

хотя как я понимаю фразу : "По результатам обследования Вам представляется краткий отчет о выявленных проблемах и коммерческое предложение с указанием возможных вариантов повышения производительности"


Вы для выставления коммерческого предложения соберете статистику, рассказывать и показывать нам наши косяки Вы не будете :-(

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

(97)  прежде чем анализиривоать более 50 тысяч   толпу запросов  я разберусь хотя бы  более полумиллиона :-)