как оценить требования к ГИС железкам

Наверное многих гисостроителей интересует тема "как подобрать/посчитать" железо под систему? Вот взгляд на тему, по следам переписки по электропочте:

цитата из письма первого:

На самом деле я и сам давно в ГИСовской тематике, вы наверняка натыкались и на мои статьи...но общаясь с очередным заказчиком вдруг заполучил вопрос о возможной связи между некими статистическими параметрами объекта, подлежащего ГИСизации (мера, степень, глубина..) и "железными" параметрами сервера.
Я-то привык это решать по принципу "начните с такого-то минимума, а там посмотрим как пойдет", но настырный клиент не отстает...Не натыкались на какую-то оценку?

Спасибо заранее за любой ответ,


вот цитата из ответа:

Я попросил сказать пару слов по Вашему вопросу одного из коллег, получилось примерно так:

"...да, вопрос туманен.
Что может дать объект гисизации в плане требований к железу?
Убьем хранимых/обрабатываемых/выдаваемых данных? В единицу времени?
Типы данных (растры, вектор, атрибутика)?
Скорость роста объема данных?

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

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

Можно ли параметры объекта гисизации отобразить на эти параметры сервера? Только на основе опыта построения аналогичных систем. И только очень грубо.
А, кроме того, ГИС становится частью КИС, с взаимной диффузией данных и функций между подсистемами, в какой-то момент уже и не скажешь, данные и серверы гисовые или не только. Кстати, именно поэтому так популярны серверные фермы и хранение данных в SAN - всегда можно недорого добавить еще выч. мощности, объемов к хранилищу.

Простой ответ такой: безусловно, связь есть между параметрами объекта и требованиями к железу. И наиболее очевидная - масштабы объекта прямо пропорциональны размерам подсистемы хранения".

В общем, я могу только присоединиться к этим формулировкам.
От себя добавлю, что мы когда-то прикидывали конфигурацию серверной группы для одного из Заказчиков, просчитывая приведенные выше параметры, но проблема в том, что Заказчик не мог сам оценить, что у него есть и как он с системой собирается работать. Быть может Ваш принцип: "начните с такого-то минимума, а там посмотрим, как пойдет" можно сдобрить предложением сначала Заказчику помочь подумать о конфигурации, которая его устроит на какое время развития и роста системы, а потом, когда мощности не смогут сильно масштабироваться, просто перенести используемую технику на другие задачи. Ротация оборудования она же всегда идет.

В общем, вот такие мысли, ничего нового...


ну и финальная цитата:

Re: про ГИСовы " железки"

спасибо за пространный ответ, вы утвердили меня в собственном мнении, а это немало :-)
Мне-то, по большому счету, это совсем не нужно, но мы вышли на "поляну" ххх кадастра. а большие "дяди и тети" часто необоснованно умничают, вместо того, чтобы просто слушать мнение экспертов, к коим я отношу нас обоих.
Вот у нас идет сейчас промышленная эксплуатация системы в ххх, одновременно на редактировании вращаются до 4 миллионов графических объектов, десятки пользователей...начали с некой разумной конфигурации, теперь стало видно, что стоит в первую очередь подумать о гигабитной сети, в общем, все в процессе.
А в другом регионе мне с апломбом заявляют: это почему это для неодинаковых муниципальных образований вы предлагаете одинаковые железки? Для чего ж вы, песьи дети, делали обследование? вот и вычислите нам теперь индивидуальные для каждого города мегабайты и гигагерцы...на дурацкий вопрос, конечно, и ответ должен быть дурацкий, но что-то я и зацепиться ни за что не могу...



Напоследок могу привести пример расчета серверных мощностей по известным (собранным статистически на этапе пилота) параметрам:

Данные, принятые к расчету	Расчетный	Ожидаемый	Пиковый
Количество пользователей (чел.)	200	40	200
Максимальное допустимое время ответа (сек.)	30	3	3
Среднестатистический размер ответа на запрос (Мб)	1	1	1
Общий объем данных, обрабатываемых системой (Мб)	5000	5000	5000
Поддержка сессии пользователя в оперативной памяти (Мб)	5	5	5
Средний объем данных обрабатываемых сервером для ответа на запрос (Мб)	500	400	600
Память, используемая операционной системой (Мб)	300	300	300
Память для кеширования информации файловой системы (Мб)	300	300	300
Коэффициент запаса	2	2	2

Расчет объема оперативной памяти на кластер (Мб)

4200

2400

4400

по формуле: (кол.пользователей*памятьНаСессию+обьемОбрабатываемыхДанных+памятьОС+обьемКэша)*запас

Расчет системы ввода-вывода на кластер
Внутрисерверный ввод-вывод (Мб/сек.)	6666,67	10666,67	80000
Ввод-вывод к клиентам (Мб/сек.)	13,33	26,67	133,33

по формулам: пользователи*обьемОбрабатываемыхДанных/времяОтвета*запас
пользователи*размерОтвета/времяОтвета*запас

Данные для расчета вычислительной мощности
Частота процесора (Ггц)	3,5
Запросов	1
Время ответа (сек.)	1
Загрузка процессора (%)	40
Ггц на запрос, чтобы ответить в секунду	1,4
Нагрузка (Ггц)	9,33	18,67	93,33

формула: пользователей/времяОтвета*ГгцНаЗапросДляОтветаВСекунду