July 26, 2012 at 12:40 am
Comments posted to this topic are about the item Leaving Some Headroom
July 26, 2012 at 7:37 am
"I'm not sure how I'd want this to work on my SQL Servers. After all, any load I placed on them wouldn't necessarily just occupy CPU. It would also impact the buffer pool, as the type of process I chose would influence what would stay (or go) in that bit of memory."
You can throttle and control individual processes (CPU & Memory) in SQL Server now. It's called the Resource Governor.:-D
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
July 26, 2012 at 8:32 am
Putting an artificial and unneeded CPU load on a server, putting large files that are not needed on the disk, and generating unneeded disk or network IO seem like things that could cause as many problems as they fix.
July 26, 2012 at 11:27 am
TravisDBA (7/26/2012)
"I'm not sure how I'd want this to work on my SQL Servers. After all, any load I placed on them wouldn't necessarily just occupy CPU. It would also impact the buffer pool, as the type of process I chose would influence what would stay (or go) in that bit of memory."You can throttle and control individual processes (CPU & Memory) in SQL Server now. It's called the Resource Governor.:-D
Resource governor doesn't limit CPU and memory for individual processes. It works with groups of logins, and it doesn't provide any ability to prevent resources from being used without a competing group.
So if your web site uses a common login, or all logins from your website, then you do not limit resources between these processes. If one pegs the server, they all suffer. They are all in the same pool.
Potentially you could use a second workload group to stick an artificial load on the server and remove it when you needed more resources.
The memory limits are not for the buffer pool, but query memory. Important, but not the same thing.
July 26, 2012 at 11:28 am
Michael Valentine Jones (7/26/2012)
Putting an artificial and unneeded CPU load on a server, putting large files that are not needed on the disk, and generating unneeded disk or network IO seem like things that could cause as many problems as they fix.
They can. Or they can save you in a crisis, especially disk issues. As with most things, it depends.
July 26, 2012 at 12:15 pm
It makes sense in the same way a reserve tank made sense on old VWs. Sure, you could consolidate it all into one fuel tank and get the same total capacity, but having it separate and only accessible if you flipped a switch or whatever, saves you from "oops, I wasn't watching the fuel gauge and now I'm totally out" situations.
And with modern servers able to go from "c'mon, gimme something to do" to "he's dead now!" pretty fast under the right (wrong) circumstances), you don't have to take your eye off that "fuel gauge" very long for it to count as "not watching it".
So, yeah, I can see the value to this kind of thing. Would definitely have to be documented and drilled as part of your DR/BC plan, or it wouldn't be any use. (Walk five miles to the nearest gas station, buy and fill a gas can, get someone there to give you a ride back to the car, only to be told by that person, "you do know your car has an emergency reserve tank, right?")
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
July 26, 2012 at 1:56 pm
I presented this idea to my SAN admin. I don't think he's was very enthusiastic about the idea.
(? °?°) ????
July 27, 2012 at 7:49 am
The memory limits are not for the buffer pool, but query memory. Important, but not the same thing.
Good point Steve , it is query memory, and they are not the same thing. i stand corrected.:-D
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply