While brushing up on TCP today, ancient synapses fired leading me to recall my first forays into network programming in 1992. While on permanent hiatus from CS education at FSU, I took a very long cross-country train trip from Jacksonville, FL through Chicago to L.A. and back to Jacksonville, FL via Pittsburgh, PA. Ideally, the goal was to get away cheaply to spend time figuring out just what the hell the next step might be. Along the way, I stayed with people I had met on social MUDs. Continue reading
Instead of buying and installing SSDs, storing Graphite’s whisper files in a memory-backed filesystem can be a good way to go if you have the RAM to spare. Depending on your environment, you may or may not care about losing a few minutes (or hours) of metric data. I know we certainly don’t care about losing 30 minutes, so there’s no reason for our carbon-cache instances to be scrawling to persistent storage 24/7. Continue reading
For those of us still in the
bash trenches now and then, I learned you can avoid the hassle of hash/octothorpe (#) commenting blocks of documentation in your scripts by using a standard “here” doc prefixed by the no-op expression (:).
Clearly this is something you’d only want to do for major blocks of text, like a large documentation block at the start of a script.
: <<'DOCUMENTATION' My free-form documentation here. DOCUMENTATION
There may be a time when you don’t want to (or cannot) make use of
knife bootstrap to set up a new Chef node or a whole fleet of hundreds of nodes. If that’s the case, and you already have a “hook” into the hosts you want to turn into Chef nodes (such as an existing CM tool), you have an option. Continue reading
Here’s what you can expect from read performance using the Linux CIFS kernel module prior to kernel 3.2.
See the ‘rsync’ graph in the lower right.
- Each of the colors in the rsync graph represent remote WAN sites. Each data point represents a transfer of ~200MB.
- No amount of dickering with the
cifs.kokernel module options improved anything
- All sites have at least 1.5Mbps links
- An HTTP get to each remote site ran at ~900kbps
- Using a Windows 2008 client to each remote site’s CIFS share gave ~940kbps
- Performance did not improve when using
cpin place of
rsync, nor did it improve with tweaks to the rsync options.
- The client of the CIFS shares was 96% CPU idle. A textbook case for illustrating to novices the reduced value of looking at load averages (see graph) to indicate how hard a host is working. The CPU graph was removed as it was irrelevant.
Thankfully, this is a largely solved issue and we’ll see it in future distributions. Here is the thread from the linux-cifs list.