A while ago, we discussed some performance analysis basics:
Define what your problem is.
Figure out your goal: What metric needs to be in what ballpark for you to declare victory?
Analyze your system from the inside out: CPU, RAM, Disk, Network. Your Bottleneck is always in one of these 4 regions.
So what are the best commands for finding bottlenecks in each of the four categories above? Here’s part two of my Oracle Solaris Performance cheat sheet with some favorite tricks.
In the last couple of posts, we used DTrace to notify our media servers and perfected our script a bit.
But the script is still not ready to be used on our home servers yet: It requires manual start and stop, not quite the service oriented automatism we’re used to in the Oracle Solaris world.
The next step is to wrap our DTrace script inside a Service Management Facility (SMF) service, then wrap everything into a shell script that will easily install or remove the service whenever we need it.
A few weeks ago, we discussed using DTrace for automatically updating media servers when you upload new content.
Yesterday though, I discovered that my D script didn’t work any more. I uploaded new songs to my home server, and expected the music daemon to re-scan the music directory, but nothing happened.
That teached me an important lesson about DTrace, and here’s what I learned:
Before we continue with our Home Server Scripting Series, let’s throw in a simple but useful DTrace hack.
One of the most typical uses for a home server is to serve music or videos to home entertainment equipment. In my case, I’m using the Firefly Media Server (no link, fireflymediaserver.org no longer exists) to serve music to my Roku Soundbridge and Mediatomb (no link, page no longer exists) for videos.
Whenever I upload new music or videos to my OpenSolaris home server (typically by rsync-ing my laptop home directory), both Firefly and Mediatomb need to be restarted so they detect that new files are sitting in their directories, waiting to be served.
