ΔΕΞΑΙ!

Okay, after today, I just have to say, "If you love bloody knuckles, buy Craftsman."

I have had craftsman tools for quite a while as many of them were given to me as gifts as a teenager and throughout college (since my wife and I have always too freaking poor to buy much other than groceries, and pay somebody rent. People figure that at least I can maybe fix stuff that I can't afford to replace if they buy me tools). Things haven't changed much, and I still have to wrench on old cars every now and then.

The one tool I have had the most problems with is the dreaded Craftsman ratchet. The ratchet mechanism has an underpowered spring that doesn't actually click the lock back inside the ratchet head all the way. Somehow or another, it will suddenly let go when you are exerting all kinds of force on it, and the handle flies free to let your hand and most notably your knuckles go flying with it, so that you punch large jagged metal object with all your might. If that weren't really enough, you have to manually hold the direction switch over for the thing to even work after a while. I've returned one particular ratchet several times now, figuring them to be flukes. I must admit the lifetime warranty can make you forget the bloody knuckles one or two times. But today, I've determined that they just plain suck.

As Huey Lewis put it, "Sometimes bad is bad." Craftsman ratchets are the badest ratchets around.

We have a mix of Centos 4 & 5 boxes at work. These servers are loaded to the gills. Quite a few time we will need to track down load issued caused by IO wait. These buggers are hard since they don't come up with "top". We started using atop since it can show per process disk usage stats (not to mention the ability to go back in time an examine a problem we couldn't catch when it happened). This only works on Centos 4 though.

For some reason, the people over at Redhat thought it would be cool to remove /proc/PID/io from the kernel stats, and it wound up in Centos 5. I have no idea why this happened. I couldn't find the functionality anywhere, but I could be an idiot too. All these things could be solved by a simple kernel patch, but changing our kernels isn't that simple.

To compensate for this, I wrote a patch that helps us out by showing which process is waiting for IO. It doesn't explicitly show you who is using how much disk IO, but it is just about as useful for our purposes. Since the problems are caused by a lot of IO wait, knowing which process is doing all the waiting is a pretty good indication of who is causing it (not always mind you). Depending on your IO scheduler, everything may look like it is waiting the same amount of time. If you have something hosing up your system pretty bad though, you can increase the sample interval to make it stand out from the processes that have a short lifespan. After that, you'll have to use good old experience and intuition. The patch isn't a great solution, but it certainly helps.

If you think it might be useful, give it a try. atop patch

Just remember this line:

• #define __STDC_LIMIT_MACROS

Without this line, you can include stdint.h all you want, and ifo_types.h will still complain that it isn't included. That's because dvdread won't work with C++ code without __STDC_LIMIT_MACROS defined. stdint.h will not define the macros that ifo_types tests for when compiling with a C++ compiler. This triggers the warnings even though you can see that stdint is indeed included.

Do a "grep STDC_LIMIT_MACROS /usr/include/stdint.h" to see what I am talking about.