Forum Discussion
On-premises gateway throttling issue
Why are you torturing the VM? Gateway cluster members should have at least 16GB, but better 32GB. 8GB will always lead to memory starvation.
Super UserWhy are you torturing the VM? Gateway cluster members should have at least 16GB, but better 32GB. 8GB will always lead to memory starvation.
It's test environment, but I wanted to validate that throttling works as intended. But, apparently the test is not valid because of these limitations.
Actually, a good point about memory in general. In my experience, 32GB instance is more CPU than memory limited, but maybe 8GB is just not enough.
Related, do you think that scaling out brings some additional efficiency benefits compared to scaling up? Can two instances handle requests more efficiently with the same total power, or is it just about raw cpu / memory power?
- lbendlin
There is a lot more to it.
Agree that 16GB is _mostly_ sufficient. However we have seen plenty of situations where a production cluster with 5 VMs and 32 GB each is running red hot - we actually had to set the memory limit at 0.95 to prevent the OS from locking up. Memory is cheap, production downtime is not.
You need to look into the workloads. Mashups have very (VERY) different requirements than spools or direct query passthroughs.
You will want to have at least 8 cores, but 16 are (much) better. Mainly important for mashups, not so much for queries.
Network card speed plays an outsized role in queries but is not as important for mashups. Physical VM location in relation to the data sources has a massive impact. Unfortunately this creates an dilemma where you have to decide between performance and business continuity. For best performance all cluster members must be as near to the data sources as possible. For best BCP they should be geographically diverse 😞 We chose performance, and we have instead separate gateway clusters for each data "region".
Load balancing works really well, but you must make absolutely sure that all cluster members are configured exactly the same, unless you want to chase ghosts for days just because one of the cluster members is missing an ODBC definition (for example).
The gateway logs are
crapnot very useful, and they lag behind reality for up to 24 hrs. We ended up creating our own telemetry processes.Very interesting in deed, would love to see what your monitoring actually consists of.
I interpret what you say about performance so, that it's hard to set any definite rules, and it's more based on the the actual workloads. We have many datasets or dataflows of varying sizes and of varying amount of data sources, but very few direct queries. So I guess the mashup performance is the most important aspect (maybe also spooling?)..
Memory has never been a problem based on instance monitoring (after we optimized some too complex queries).
Can you clarify what you mean about "configured exactly the same". Isn't the gateway-software abstracting away the actual machine running it? - Isn't it enough that the gateway sw-versions match, and their settings are ok?
- lbendlin
The cluster members must have the exact same driver versions for your connections, the TNS entries must match, the ODBC system DSNs must match, the gateway config files must match (all of them), they must all be on the same Windows patch level and and and. The moment you have the slightest difference something will break in a random fashion and you will waste a lot of time chasing it down.