Forum Discussion

anttijarvinen's avatar
anttijarvinen
Frequent Visitor
2 years ago
Solved

On-premises gateway throttling issue

Hi,   I encountered a problem while testing load balancing with two on-premises gateways, with the other instance throttled.   Following these instructions https://learn.microsoft.com/en-us/data-...
Need Help
  • lbendlin's avatar
    lbendlin
    2 years ago

    Why are you torturing the VM? Gateway cluster members should have at least 16GB, but better 32GB. 8GB will always lead to memory starvation.

lbendlin's avatar
lbendlin
Icon for Super User rankSuper User
2 years ago

Your mashup workloads still need to fit into memory.  How much is 30% in actual MB ?

anttijarvinen's avatar
anttijarvinen
Frequent Visitor
2 years ago

It's 0,3x8GiB=2,4GiB

Idle memory consumption is in 40%.

-> I wanted to have queries always "fail" in this instance.

  • lbendlin's avatar
    lbendlin
    Icon for Super User rankSuper User
    2 years ago

    Why are you torturing the VM? Gateway cluster members should have at least 16GB, but better 32GB. 8GB will always lead to memory starvation.

    • anttijarvinen's avatar
      anttijarvinen
      Frequent Visitor
      2 years ago

      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's avatar
        lbendlin
        Icon for Super User rankSuper User
        2 years ago

        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 crap not very useful, and they lag behind reality for up to 24 hrs.  We ended up creating our own telemetry processes.