the #sqlserver production and perf/scale test systems i work with have recommended configs based on models and observations by my colleagues. those recommendations are solid :-)
but not every non-prod vm needs to have production-level perf/scale.
but not every non-prod vm needs to have production-level perf/scale.
today i was asked about a non-prod #sqlserver instance used as a first stop for report-writers and developers. For schema exploration, ensuring queries are correct logically.
Two vcpus, 8 gb vRAM.
Two vcpus, 8 gb vRAM.
That's *way* smaller than any production or perf/scale test #sqlserver system i've worked with. production schema, but small test data set. #sqlserver 2019.
i completely understand the value of such a resource. still, at first i was a bit frightened :-)
i completely understand the value of such a resource. still, at first i was a bit frightened :-)
but i thought a little bit.
ok. Let's frame it as not needing 1:1 perf/scale behavior as production. That's already the case since in production for most of these queries the target is DOP 8 and this system only has 2 vcpus.
ok. Let's frame it as not needing 1:1 perf/scale behavior as production. That's already the case since in production for most of these queries the target is DOP 8 and this system only has 2 vcpus.
then disabling BMoR and LPIM should make this non-prod dev 2 vcpu 8 gb vRAM vm suitable to task unless it experiences high developer user concurrency. in which case my main expectation would be resource_semaphore waits, not crash of the vm. (note: this is a rowstore only system) 
• • •
Missing some Tweet in this thread? You can try to
force a refresh
