Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Best practice for production servers: To reboot or not to reboot?



On 09/14/2010 12:00 PM, Richard Pieri wrote:
> On Sep 14, 2010, at 11:37 AM, Jerry Feldman wrote:
>  =20
>> I disagree with this on modern Linux (and BSD) kernels. Let's remove V=
M
>> from the discussion for a second. Most applications use the malloc(3)
>>    =20
> Let's not, because I'm specifically thinking of Java's garbage collecti=
on as a common example.
>
>  =20
Most daemons in a Linux system are written in C, and some in C++. Java
is certainly an excellent, and wide-spread language, but most likely
would not contribute to any significant slowdowns. Additionally, there
are a number of different JVMs that can run on a Linux system. For
instance, on Tru64 Unix, Chris Gillett totally rewrote the garbage
collection in the JVM we used. Languages, like Java and Python that have
garbage collection routines are not usually used as background
processes. In the case when a Java application slows down based on
garbage collection inefficiencies, a simple restart of the application
fixes it. The memory issues that cause server slowdowns are things like
a mail server (I know of none written in Java), and web server, like
Apache. But in both cases a simple "sudo service httpd restart" will
restart the daemon. But, other than a memory leak bug, I don't see these
server applications needing a restart. On the BLU server, I sometimes
restart sendmail because it gets bogged down with a large number of
connections, and it causes me not to be able to send email, but this is
neither a memory fragmentation issue nor a bug, and it can be solved by
a simple configuration change (allow more connections), but that
effectively would require a newer, faster server, and it does an
adequate job of turning email around quickly.

Years ago there were many legitimate issues to reboot a server because
of memory fragmentation issues, but this was a long time ago when
operating systems simply needed a reboot to get fid of a lot of cruft.
I'm referring mainly to IBMs mainframe OS and some older Unix systems
when virtual memory was somewhat new. Modern Linux, Unix, and Windows
Server systems really do not require a frequent reboot. A scheduled
maintenance period whether monthly, quarterly, or annually is usually a
good idea for a production server, just to be able to run some
diagnostics, apply patches, and possibly replace some hardware
components. One of the more common issues in Linux used to be zombies,
but we have become better at preventing them.



--=20
Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org>
Boston Linux and Unix
PGP key id: 537C5846
PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB  CA3B 4607 4319 537C 5846








BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org