One question I get a lot is about performance and how systems can run well for years and then suddenly just stop performing well. That’s an understandable question and one that’s both easy and complicated to answer.
The short answer is that there’s a huge margin for error in these types of things. However, the margin is only huge if you’re not doing anything about it. Let me explain.
It’s like being on a diet. When you’re watching what you eat every little bit matters. That extra helping of fries, that bowl of ice cream, and that soda are all death to a strict diet. Even little things can be harmful when you’re on a diet and the more strict the diet the more the little things matter. That’s why professional athletes of all kinds watch their intake like hawks. So in their case that extra ounce of potatoes, or that extra ounce of meat can really make a difference. And that’s not even to mention diabetics and other people on strict medical diets. Think about someone with severely high blood pressure. Their diet is extremely important and the slightest wrong food can have serious blowback on their system.
Now look at someone who’s already grossly overweight. This guy eats whatever he likes up to thousands of extra calories a day. He eats only fried and fatty foods and eats as much of it as he likes. So that extra helping of ice cream or that extra few fries really doesn’t matter much on top of everything else. That’s not to say that it doesn’t have a cumulative effect, just that day to day it doesn’t matter much. Eventually though, it will take its toll as he get heavier and heavier and starts to feel health effects from it. So while those extra fries do eventually catch up with him, they don’t cause any real immediate effect on top of all the other stuff he’s eating.
Well, that’s much the way it is with servers too. If you have a bunch of stuff that runs kinda poorly or just not as well as it could, it’s not really that important on a daily basis because the server itself runs slow and what’s one more mediocre process going to hurt? So a server can run for quite a while like that and nobody will ever really notice the difference. Part of the problem is that so few people bother to investigate better ways to do things so they get used to their DB performing slowly. It’s not necessarily their fault and these things can sneak up on them. Even a fairly good DBA can have wrong decisions go undiagnosed for a long time and the poor performance can sneak up on him and next thing he knows his system is just dragging. And it’s hard to go back and find that one thing that started the whole thing. I find typically that performance problems are systemic. By that I mean that whatever mistake is made, is made throughout the whole system. It’s quite often not an isolated incident unless someone new comes into a shop where things are already running smoothly.
So anyway, a server can put up with a good deal of abuse before it goes belly-up, but it will eventually happen. What you want to try to get to is a point where you can treat your server like it’s got diabetes. You want it on a very strict code diet where you watch every single I/O, every single MB going into RAM, every CPU cycle, etc. On servers like this, one single process that doesn’t behave can have a noticeable effect on many other processes and you’ll know you did something wrong right away. But if you’ve got a system that’s slow to begin with, who’s really going to notice if it’s running a little slower or if the CPU is hitting 81% instead of 76%?
This is why I’m not only stressing performance considerations on servers, but also why I’m always answering this question.
This of course has to play hand in hand with tomorrow’s post on reasonable performance.
Watch my free SQL Server Tutorials at:
Read my book reviews at:
Blog Author of:
Database Underground – http://www.infoworld.com/blogs/sean-mccown
Follow my Twitter: