The recording of “When Times Get Tough, The Tough Get Tuning: Improve the Performance of Your Linux Systems” is now available on both:

• O’Reilly’s webcast site
• O’Reilly’s youtube channel

I did a Webinar today for O’Reilly on Linux performance tuning. Thanks to everyone who attended! Here’s my slides, as promised. When the recording of the Webinar is available, I’ll add the link here and blog about it separately as well.

Edited to add: The recording is now available

Also, I created a dashboard for my Splunk instance that displayed a stat of interest over time for each of the four performance areas (CPU, RAM, network, and I/O). To do this, I installed and took a look at the Splunk for UNIX application, noted that it didn’t quite use the same flags I wanted for some of the commands, and so made these scripts to add to the Splunk for UNIX application. Unpack them into $SPLUNK_HOME/etc/apps/unix/bin.

Then I had to tell Splunk to read in their output, and made some searches that I could put on a dashboard. Get these configuration files and unpack them into $SPLUNK_HOME/etc/apps/unix/local. You may need to create this directory.

Restart your Splunk server, and now you can make a new dashboard with the four searches I included:

• Available memory
• CPU idle ticks
• Lag in IO requests

On October 21, 2008 at 10:00am PDT (17:00 GMT) I’m doing an O’Reilly Webcast on Linux performance tuning. If you’d like to join me, go to the registration page and sign up!

A lot of what I’m working on lately involves the best process to accomplish something, which can mean a lot of step by step logic. Often when working on such docs I end up having to repeatedly reorganize them as I realize during the writing that I hadn’t entirely thought out what came before what (the structure of this sentence is a living example of my not having an entirely linear mind).

I’m not a strict outliner for shorter-than-book documents, but I found a kind of middle ground that helps me organize my thoughts without feeling bound into a rigid outline format: rough flowcharting. Somehow it feels more fluid to me than outlining even though I suspect most outlining tools have most of the same features as the charting tools I use. Maybe it’s a visual thinker thing.

In the world of Macs, Omnigraffle is a great tool to just rapidly throw together a step by step chart. I probably underutilize it and there are some features I haven’t figured out–for someone who writes I am ironically also someone who fiddles first and looks at docs when I give up, most of the time–but the ability to just make a series of linked boxes with step explanations, move them around and relink if I need to, etc., seriously comes in handy. Even better, when I’m done, I can clean up the chart and make a more official-looking flowchart out of it to include with the document.

In my wanderings about the Web, I encountered Luis Suarez’s thoughts on an article discussing IBM’s rethinking of knowledge management. In part, the Knowledge Sharing issue makes me think of internal corporate wikis, where people tend to put things up according to the mythical beast named, “When I have the time,” and whose pages can often become out of date, forgotten, and not maintained. However, at times I have thought that part of this problem is the nature of the wiki itself.

As someone who’s spent a good portion of her life mastering word processors and being able to use them to get things to look exactly as she wants them, I tend to find wikis to be a rather cumbersome and frustrating experience. I’m a technical person by nature, so it’s not that I don’t understand how to use them, but by definition wikis seem to be very bare bones and don’t even have some of the useful formatting features that even most blog-posting software has. Trying to get a non-technical person to utilize a wiki can be a frustrating experience, which tends to in a lot of ways sabotage the wiki’s usefulness if you want everyone to add to it.

Part of my focus as Knowledge Manager at Splunk is capturing best practices, particularly the best practices around using Splunk. Gathering this information is a lot like researching a story, getting me to draw on:

• My own knowledge of how to use Splunk (hey, I’m not a guru but I have been using it for over a year now)
• Our sales engineers who encounter what customers want to do in the field
• Folks in support who hear a lot about what aspects of Splunk might be confusing, along with what folks are trying to do with it
• Our developers, who can give me those sweet little tips and tricks that I can share to help people do things more efficiently
• The folks in professional services, who definitely encounter what customers are doing in the field.
• Doc writers, who spend a lot of time explaining the nitty gritty of things and can often have some pretty interesting tips.
• And really anyone else in the company who might have something interesting to share.

Update 22 April 2008: As of Leopard 10.5, you can use the dot_clean utility to get rid of these files!

When building Splunk applications, I’m often working on a Mac. There are files that begin with ._ that are resource files, which contain extended attribute information about the files for the OS. This is great and all but I don’t want to include these files when I package up an application and upload it to SplunkBase.

If you don’t have deep OSX knowledge, then keeping these files out of your tarball is harder than it looks. One of our OSX gurus pointed me toward the answer, and I was so excited (yes, I am a geek) that I just had to share.

To build a tarball in Leopard that doesn’t contain the ._ files, use:

COPYFILE_DISABLE=true tar cvzf filename.tar.gz dirtotar

In Tiger, use:

COPY_EXTENDED_ATTRIBUTES_DISABLE=true tar czvf filename.tar.gz dirtotar

This is definitely going in my .bashrc so I don’t have to fuss with it again:

export COPYFILE_DISABLE=true

Knowledge management is one of those strange terms that sounds like it was made up to make someone’s job sound more important than it is. However, the task of the knowledge manager is no small one: “capture” the knowledge within a company, whether across the board or in a vertical section such as human resources or technology usage. This process is multi-step, as you have to get a feeling for what there is to learn, who to go to in order to learn it, and then get it all down in ways that people can find and make use of.

In my case, I capture best practices in using the Splunk product to accomplish key tasks. Since I’m surrounded by experts in various aspects of using Splunk at work, this task involves a bit of mind-melding so I can learn and understand cool things that other Splunkers have discovered and then put them down in a way our users can follow. I’m sure that many users out there who have come up with some pretty interesting ways to efficiently utilize Splunk for their own purposes. If you’re one of them, I’d love to hear what you’re up to!