где почитать (или может кто так знает) по требованиям к памяти на кэширование (SE/FE) в зависимости от количества пользователей/кубов в базе и SSAS баз на сервере (и их размеров) ? не в смысле - чем больше = тем лучше, а реальное обоснование (хотя и тут от самих на лету расчётов зависит)

вопрос именно по SSAS и нагрузке при запросах от пользователей, а не по SQL DB Engine или на Агрегации/Процессинг.

для простоты допустим 64проца, 1К юзверей, 100 измерений 1000 атрибутов (по четверти миллиона элементов полюс properties), 1TB на 10 баз (40 кубов с 30тью ролями) для условно-быстрых дисков

Был когда-то FastTrack, но что-то мёртвые M$ ссылки

Критик,

я-бы с удовольствием пошел по пути чем больше - тем лучше, но последнее серверное (сертифицированная именно для этих машин плюс ECC/Buffered) - не из дешевых удовольствий, да и у департамента всё в пределах бюджетов, так что надо для них как-то обосновать прежде чем рекомендацию делать что надо именно столько.. вот скажу что надо треть от кубов - тут-же спросят: а почему?

хотя треть - уже какое-то реальное число

забыл написать что это для MultiDimensional

просто не хотелось-бы PerfCounter писать и потом тыркать пальцем в график - вот видите - тут нехватает .. не поймут, было-бы удобнее "потому что гладиолус M$ так сказал" или по опыту множества крупных организаций..

по и-нету всё разбросано мелкими кусками типа такого где ещё авторитетность источника придётся доказывать.. :\

товарищъ,
Да, спасибо, погоняю конфигурации на схожесть по аналогиям, примерно такой-же путь указывает M$ FastTrack - т.е. на расчёты вендоров.

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

ладно, похоже буду по студенчески тестировать, ограничить память на 32/64ГБ - раз 5 отпроцесить замерив время, чистка кэша каждый раз, ограничить на 128Гб - тоже самое, 192ГБ - опять, дальше экстраполяция..
на 4х конфигурациях по 5 тестов .. просто не хотелось пол дня убивать..

sergeyns,

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