Keeping Unix Running and Tuned 225 Compilation exited abnormally with code 1 at Sat Feb 29 17:01:34 I was started to get really worked-up for a flaming message about Unix choking on leap-year dates, but further examination—and what example of unix lossage does not tempt one into further, pointless, inconclusive, disheartening examination?—shows that the actual bug is that this machine has been up too long. The way I discovered this was when the ispell program told me: swap space exhausted for mmap data of /usr/lib/libc.so.1.6 is not a known word Now, in a blinding flash, it became clear that in fact the poor machine has filled its paging space with non-garbage-collected, non- compactible twinkie crumbs in eleven days, one hour, and ten min- utes of core-dumping, debugger-debugging fun. It is well past TIME TO BOOT! What’s so surprising about Richard Mlynarik’s message, of course, is that the version of Unix he was using had not already decided to reboot itself. You Can’t Tune a Fish Unix has many parameters to tune its performance for different require- ments and operating conditions. Some of these parameters, which set the maximum amount of some system resource, aren’t present in more advanced operating systems that dynamically allocate storage for most sys- tem resources. Some parameters are important, such as the relative priority of system processes. A sysadmin’s job includes setting default parameters to the correct values (you’ve got to wonder why most Unix vendors don’t bother setting up the defaults in their software to match their hardware con- figurations). This process is called “system tuning.” Entire books have been written on the subject. System tuning sometimes requires recompiling the kernel, or, if you have one of those commercial “open systems” that doesn’t give you the sources, hand-patching your operating fix with a debugger. Average users and sysadmins often never find out about vital parameters because of the poor documentation.

226 System Administration Fortunately, very experienced sysadmins (those with a healthy disrespect for Unix) can win the battle. Date: Tuesday, January 12, 1993 2:17AM From: Robert E. Seastrom rs@ai.mit.edu To: UNIX-HATERS Subject: what a stupid algorithm I know I’m kind of walking the thin line by actually offering useful information in this message, but what the heck, you only live once, right? Anyway, I have this Sparcstation ELC which I bought for my per- sonal use in a moment of stupidity. It has a 760MB hard disk and 16MB of memory. I figured that 16MB ought to be enough, and indeed, pstat reports that on a typical day, running Ecch Windows, a few Emacses, xterms, and the occasional xload or xclock, I run 12 to 13MB of memory usage, tops. But I didn’t come here today to talk about why 2 emacses and a win- dow system should take five times the total memory of the late AI KS-10. No, today I came to talk about the virtual memory system. Why is it that when I walk away from my trusty jerkstation for a while and come back, I touch the mouse and all of a sudden, whirr, rattle, rattle, whirr, all my processes get swapped back into memory? I mean, why did they get paged out in the first place? It’s not like the system needed that memory—for chrissake, it still has 3 or 4 MB free! Well, here’s the deal. I hear from the spies out on abUsenet (after looking at the paging code and not being able to find anything) that there’s this magic parameter in the swapping part of the kernel called maxslp (that’s “max sleep” for the non-vowel-impaired) that tells the system how long a process can sleep before it is considered a “long sleeper” and summarily paged out whether it needs it or not. The default value for this parameter is 20. So if I walk away from my Sparcstation for 20 seconds or take a phone call or something, it very helpfully swaps out all of my processes that are waiting for keyboard input. So it has a lot of free memory to fire up new processes in or use as buffer space (for I/O from processes that have already been