So the scenario we have is we have 4 front facing SSAS Tabular servers spread across a number of data centres to help us with worldwide geographic challenges and to provide redundancy.
We process a pair of new cubes overnight on a processing Server (no end users on this), we then SYNC these with the 4 front facing servers and a redundant processing spare. So we do 10 cube syncs (2 cubes on 5 servers)
This is all undertaken within a SSIS package by issuing a set of TMSL SYNC commands.
This has been fine for months moving both models in about 15 mins (models are 12gb and 15gb compressed)
We often see the servers taking a while to "spin up" the VMs are running in an uncontested mode so they have the requisite RAM allocated and aren't being starved in any way by the underlying tin.
An example of this, is if we connect in SSMS we connect immediately but if we expand the Databases folder in the Object Explorer tree it can often take several minutes to give us the expanded DB list. If we monitor the server concerned we can see the RAM used by SSAS on the server spinning up from a fairly low level (CPU is often 15% during this phase) as it loads the two models. Eventually it reaches a footprint of about 52Gb (both cubes loaded with some overhead I assume) at which point it will start responding to queries.
This spin up delay seem to occur after a sync is undertaken for the first user that hits any given server, after that it seems to be fine. We do have some anecdotal evidence that if a server isn't active for a period we get the same "spin up" behaviour.
Does anyone have any ideas as to what might be causing this behaviour and or how we can prevent it?
regards
Steve
BI Addict!