williamhathaway.com

My wife’s Garmin c340 GPS suddenly shut off on her and wouldn’t power back up.  Initially we suspected that the cable carrying power from the cigarrete adapter was loose, but the charger was working fine.  After leaving the GPS on the charger for a while and pressing the power button, we still weren’t having any success in having it boot back up.  If you are crazy enough to read the manual, it turns out there is a reset button hidden under the faceplate.  After pressing the reset button, the unit was able to power on fine.

There is a little opening to help pry off the faceplate right under the GARMIN name on top.

You can use a fingernail or a dime to pry the faceplate loose.  It should come off very easily.

Once the faceplate is removed you can press the reset button on the right side.

As the days have been getting shorter, my occasional weekday runs at 5:30 with my friend Jon have been plunging into darkness sooner and sooner.  At this point, it is already dark out when we start.  We are usually running around his low-traffic Camp Hill neighborhood, which is pretty runner friendly, but it is still important to make sure that you can see any obstacles in the road (like potholes or those wacky ball shaped seeds from some trees), and that vehicles can see you.

To handle the “can be seen by vehicles” part, I bought two of the Nathan Clip-On Deluxe LED Safety Strobes.  I can clip these to my wrists via my road-ID and watch.  Given my wrist movement in the arm swing, these can be seen from the front, side, and rear and the multiple LEDs blinking is very eye-catching.   I think I’ll also pick up a reflective vest the next time I see one that fits well.

To help see where I’m going I picked up a Petzl E47 PS Tikka Plus headlamp.  It is light-weight but really bright.  A feel somewhat like a coal-miner when wearing it, but it definitely does the trick.

Yesterday we had to modify a huge number of entries in our directory server environment.  The updates were all done in one data center, and they went extremely fast.  When I later went to check on the replication, I noticed  the data was replicated much slower to the remote data center than I expected.  Given that the other data center is a pretty decent WAN hop awa,  I decided to try changing some of the replication agreement parameters.  To do this you use:

dsconf set-repl-agmt-properties $suffix  $property:$value

You can see more information on the properties and suggested values at the Replication Over a WAN page of the DSEE Admin Guide.

In our case, I did some quick experimenting and found the values suggested for WANs seemed to work pretty well and gave us about a 3x-4x boost in performance versus the defaults.  The changes take place immediately, there was no need to restart the servers or replication agreements.

To measure how fast replication was going I would go to the remote server and run something like

grep 2008:10:23 logs/access | grep -c MOD

where 10:23 was the previous minute, to count how many MOD operations had come through in one minute.

Monday morning through Sunday night I worked 91.5 hours, which was my heaviest work week ever.  The team I am on was in a big sprint to get Sun’s DSEE software rolled out on a huge scale across multiple data centers and it all came together.   The software installation and configuration itself was easy to manage across dozens of hosts thanks to the fantastic CLI.   The x4600 servers performed very well.  Our biggest challenges were coordinating a group of people in multiple locations with differing levels of familiarity of the machines and software stack.  There were a few cases where tired fingers made a typo and wiped out some data, but using zfs rollback (and smart use of snapshots) made the recovery time in under a minute once the problem was detected.

The funniest moment of the crazy weekend was when my wife saw me working in my office at 8am Sunday morning and asked what time I went to bed.  I answered “about 6:30″.  The look of horror on her face as she realized that mean less than 1.5 hours of sleep was awesome.

I hope I don’t have craziness like the last week often, but I did feel a great sense of accomplishment when we were done.

Tip of the day:

If you get a coredump on Solaris, run

echo ‘$C’ | mdb $name_of_corefile

to get the stacktrace that actually caused the core.

Mark Rebuck and I met for a run at the Conewago trail head Saturday morning.  We did a 10 miler in an hour and 35 minutes.   I could definitely feel fatigue building up towards the end but was thrilled when we completed the run.  This was my longest run since July.  Sweet!

Garmin Connect run info

I started uploading the photos I took at the Harrisburg Marathon today.  Thanks to the beauty of cheap compact flash cards, I took over 1200 photos. They won’t all be uploaded until sometime tomorrow, but you can view the gallery here.

The regular results and relay results are now are posted.

I read a copy of Steve Souder’s book Higher Performance Web Sites: Essential Knowledge for Front-End Engineers about two months ago.  I had enjoyed the book but had forgotten to blog about it until I heard a podcast last night that was talking about measuring site performance.

Souder’s book is a fairly quick read.  He provides a series of rules websites should follow to provide  good user response times and then goes into detailed descriptions about the techical nuisances and provides examples of how different choices affect real-world performance.  Steve’s rules have been embedded in the YSlow plugin for Firefox which can be ran against a site to get a list of which best practices are used and ends up giving a letter grade for overall site optimization.

You can read a short article that gives a high level overview of some best practices that are mentioned.

Recommendation: If you are a website developer, I think this is a fantastic book to read.   If you are short on time, just read the article above and download the YSlow plugin.

Additional notes: KITE is a free website performance tool (Windows only) offered by Keynote that was discussed in the podcast.

I’m working on a project with a customer who is migrating from Sun’s older 5.2 based Directory Server to the latest version (6.3) of  Directory Server Enterprise Edition.  I’m excited about the project because I get to work with some good people I haven’t been in touch with lately, and we are using a number of cool technologies, including:

• Solaris 10 on x4600 servers (16 Opteron cores and 128G of memory)
  • ZFS – provides compression and snapshot capabilities on top of storage
  • DTrace – used for look at performance and troubleshooting
  • Privileges – allows our application user to start processes running on a low port
• Directory Server 6.3
  • I’m loving the dsconf tool for setting almost all config parameters via the command line.  So far there have been only two things I’ve been forced to hack via perl instead of using the supported interface to edit  (db-page-size and db-path).  This is a huge improvement over DS 5.2′s command-line manageability.
• Directory Proxy Server
  • Provides an application level proxy for load balancing LDAP requests and allowing us to perform data distribution.  This is really powerful stuff, giving us a lot more flexibility than if we just had traditional hardware load balancers at our disposal (we are still using hardware based LBs, just in front of our DPS instances).

My plan on blog entries related to this project is to not mention any customer identifying information, but to pass along some general info which might be helpful to other organizations using all or some of the components in similar ways.

Tip of the day:  We had a note from the sysadmin team asking about memory usage on one of our directory servers. There was a bit of confusion about where the memory on the box had gone since according to vmstat about 10 gigs were free and we could only see about 10 gigs used by user processes.  The answer is that since we are using ZFS, the memory consumed by ZFS’s adaptive replacement cache (ARC) doesn’t show up as free memory (unlike UFS, where it does).  This explains why systems using ZFS will have a very different memory usage profile than UFS systems.   In order to give visibility into ZFS’s memory usage, we pulled down arc_stat.pl and used that to show that ZFS was caching about 107 gigs of file system data (which is what we trying to do).  For cases like ours where you have a known memory demand for applications, you might want to consider limiting ZFS’s cache.

If you are using ZFS consider reading Ben Rockwood’s excellent posts on the topic.