Notes on Linux's blktrace
Blktrace is a tool that captures detailed traces of what's happeningin the kernel's block layer. In other words, think of it as a tcpdump for disk IO. This is just the kind of thing you need todeal with the fact that averages are misleading ; since blktrace can tell you about thetiming of every request, you can use it as the starting point forall sorts of detailed analysis. Or you can simply use it to verifythat you don't have any timing outliers in your
Averages mislead: an illustrated example
Over about an hour recently, while backups were running, one of our Solaris fileservers had anaverage iSCSI operation completion time of 33 milliseconds. Notgreat, especially since its iSCSI backends are SSD-based, but not terrible. This is pretty typical for thisfileserver under load and while these particular numbers weregathered with DTrace, they agree with the output of things like' iostat -zxn 60 ' (individual iSCSI disks could sometimes be slowerover a 60-second period, but not hugely so and
DTrace: notes on quantization and aggregates
Following on the same theme as yesterday , here'ssome things about DTrace's aggregates and quantization that I want toremember. As a bonus I'm going to throw in random bits and pieces aboutusing printa() .
(I should mention that all of this is on Solaris 10 update 8. Yes, thisis almost fossilized by now. No, we're not interested in upgrading.)
As I mentioned yesterday, I've come around to the view that you shouldnever use
Some notes on getting durations in DTrace
One of the things you commonly wind up doing in DTrace is computingdurations, how long things take; this gives you latencies, among otheruseful things. Since we have a significant performance problem with ourmail spool right now, durations and latencies have very much been myfocus recently. In the process of trying to apply DTrace to the problemI've wound up with some things that I want to remember about this.
What I've seen as the standard or classic DTrace pattern for gettingdurations is to timestamp
A new anti-spam precaution after our local spam incident
When we had out local spam incident , I of courseimmediately started thinking about mail configuration changes we'd wantto make to lessen the impact of another such incident. One of them wasto arrange it so that another IP address was used when sending out useremail that did not come from a local address.
Our mail submission machine ( which handles almost all outgoing email ) is one of our most importantmail machines to keep off blocklists and to maintain with a goodreputation, because it's the machine that
What I would like in colour-specification interfaces
There are a lot of programs and systems and so on that let you specifywhat I'll call 'absolute colours'; this RGB value for the foreground,this RGB value for the background, and so on and so forth. My personalopinion is that this approach to specifying colours is too low-level formost uses.
We know a fairly large amount about how people perceive colours inrelation to each other; some of it comes from scientific research anda great deal of it comes from the surprisingly pragmatic
A recent spam oddity that I've been mulling over
One of my habits is that I don't directly subscribe to mailing lists;instead, I subscribe aliases to them and forward the aliases to me.These aliases are generally purely collection points that are almostnever used as the From: address or explicitly copied on messages. Asa result of all of this, these aliases should never get spam and almostalways don't. All of this is background.
A couple of weeks after our phish compromise incident , one of those aliases received a distinct burstof spam
fork() versus strict virtual memory overcommit handling
Unix's fork() is in many ways a wonderful API, but people who want strict virtual memory overcommit handling findit deeply problematic. This is because, as I've written before , fork() is probably the leading way on Unix systems to(theoretically) allocate a lot of memory that you will never use.The more allocated but unused memory you have, the stupider strictovercommit gets ( cf ); itincreasingly denies allocations purely for accounting reasons, insteadof from any danger that the system
Microkernels and device drivers
A commentator on my entry on microkernel modularity asked a good question:
One common argument pro microkernel is that they are more robust,because individual drivers can crash without taking the whole systemdown. What's your take on this?
I don't know if anyone has done practical studies on this and certainlyI have any personal experience myself, but I'm dubious about this claimfor several reasons.
To start with, drivers control hardware and hardware itself isextraordinarily powerful. On most machines, hardware can do
Microkernels and modularity: do microkernels ever make sense?
Here's a question that I've been mulling over for a while , stated here as a thesis and argument.
The meta-goal of microkernels is to make it easier to write OSes and tomake them more reliable by isolating OS components from each other;this increased isolation and modularity is achieved by limiting theirability to talk to each other and affect each other. In a conventionalkernel, you have global variables, shared global data structures, andpotential semi-random function calls as the flow of control