In article <Y%STa.3818$c6.3326@bos-service2.ext.raytheon.com>,
"EKL" <En-Kuang_Lung@raytheon.com> wrote:

> >
> > +> Would someone please give me some pointers on a trend analysis on
> resource
> > +> leaks for Solaris 9 and LynxOS (or in general on UNIX machines).
> Basically,
> > +> I need statistics to determine how often I need to restart these
> machines to
> > +> avoid unplanned failures. Thanks.
> >
> > Ummm...you don't? I can't speak to LynxOS, but I've had Solaris boxen
> > with uptimes on the order of 4-6 months. If they weren't connected to
> > the commidity internet, and the power stayed on, and I wasn't so
> > zealous in applying the recommended and security patches, I could
> > probably get uptimes in the *years*.
> >
> > What you have to worry about are buggy applications doing bad things
> > to your system resources.
>
> Thanks James. Even though you may not need to reboot for a long time, but do
> you notice any performance degradation over time or unexplained resource
> losses of usages? Thanks.

That only happens when you let evil developers use your systems. They
can write the worst stuff that screws up your filesystems and not clean
up after themselves. Then they want hourly backups of all their files
in case they screw up. If you just run without users, your servers can
go for _very long_ without rebooting. If the applications and system
are designed with properly, the day-to-day procedures to run the system
are established and maintained, and the environment is OK (e.g.
datacenter with A/C, UPS, and backup generator), you shouldn't need to
reboot your systems for anything less than a hardware failure.

Obviously, that's not possible. You ask an overly-broad, marketing-type
question without specifics of your situation. You must be responding to
something a PHB asked you to find out.

The "general rule" of UNIX is "don't reboot unless you have to (or
you're lazy and don't want to figure out what to fix your problem".
Sysadmins are forever quoting the longest "uptime" on their systems as a
matter of pride.

In common practice, scheduling downtime at least once a month gets the
users used to the idea of a "downtime" and gives you headroom to plan
projects that require an outage--hardware and software upgrades,
testing, or whatever.

If you can't do this, buy lots of hardware and build a fault tolerant
system. Bring your checkbook.

--
DeeDee, don't press that button! DeeDee! NO! Dee...