Open desktop mechanic

Are there really GNOMEs living inside my desktop?

Thursday Jun 10, 2004

I'm sure many have experienced this problem, you're working on your favorite application under your favorite OS when suddenly...chatter clatter chatter, the drive light blinks furiously. Or maybe there are no physical signs, but the system suddenly inexplicably grinds to a crawl as if the bits somehow encountered the computational equivalent of molasses. You manage to run `top` only to learn that the top cpu user is...top. Whatever it is either doesn't take up CPU resources, or does it in such a way that isn't easily measurable. A few seconds later everything suddenly goes back to normal and all is as though the strange occurance never happened.

Not long after GNOME 2.0 was deployed on internal SunRays, one of our engineers impressed me with the diagnostic capability of a new tool called dtrace in finding a problem which somehow escaped many opensource eyes and found its way onto many linux and Solaris desktops. When the desktop group brought JDS to Solaris it provided an opportunity to learn more about these mysterious GNOMEs. So I installed a JDS build on Solaris 10 beta and ran the dtrace tool on a bare GNOME desktop with only a couple of terminals, a panel, a nautilus window and mozilla. I started by looking at reads and writes. After all, though CPUs have become hundreds of times faster in the past 20 years, hard drive latency hasn't changed nearly as much.

A few words about dtrace. Software developers are familiar with the technique of peppering their code with printfs and enabling these with build flags or environment variables. But what if the OS maintained a database of probes that you could turn on or off at will? Dtrace provides this capability. So I ran a little dtrace script in the d language which looks at how many times each process is invoking the write system call:

syscall::write:entry
{
 @counts[execname] = count();
}
I ssh into the machine, start the dtrace write script and then go away to a meeting. When I return I can see what my desktop was doing while I was away:
  dtrace                                                            1
  sshd                                                              4
  sac                                                              10
  ttymon                                                           10
  gnome-panel                                                      55
  mozilla-bin                                                     636
  xscreensaver                                                    663
  clock-applet                                                   2971

I run a similar script on the read system call:

  sh                                                                1
  ttymon                                                            4
  sac                                                               4
  nscd                                                              5
  dtterm                                                            5
  init                                                              8
  utmpd                                                            10
  gnome-session                                                    10
  nautilus-throbbe                                                 10
  gnome-smproxy                                                    17
  sshd                                                             24
  gnome-settings-d                                                 30
  clock-applet                                                     32
  nautilus                                                         83
  wnck-applet                                                     125
  metacity                                                        151
  mozilla-bin                                                     225
  gnome-terminal                                                  234
  xscreensaver                                                    275
  gnome-panel                                                     287
  gnome-vfs-daemon                                                657
  Xorg                                                           5771
I'm also interested in calls to open. To look at these, I download a dtrace script called opensnoop.d from the dtrace tools repository. It looks like gnome-vfs-daemon and sshd are the winners. sshd is opening /dev/random and gnome-vfs-daemon is opening /etc/fstab and /etc/mnttab. I'm running over an ssh terminal session and letting the output go to the terminal so I'm causing a bit of a probe effect. So far I've only looked at a quiecent desktop. I'll run a script tonight to capture more information, but then I'd like to find out how a GNOME desktop behaves when it is being actively used. Stay tuned...

[2] Comments
Like this post? del.icio.us | furl | slashdot | technorati | digg
Comments:

We recently fixed an SSH bug similar to the one you mention: 5014180 "SSH should keep /dev/random open" This was fixed in s10_58 (aka Beta4). And surprise surprise the submitter used dtrace to discover the problem :)

Posted by Anonymous on June 16, 2004 at 06:36 AM GMT+00:00 #

Cool!

Posted by bnitz on July 23, 2004 at 02:36 PM GMT+00:00 #

Post a Comment:
Comments are closed for this entry.