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 10:58 AM, Richard Pieri wrote:
> What Jack said about applications.  Even though an application doesn't =
leak memory it can still suffer from memory fragmentation which will even=
tually degrade performance.  File servers, on the other hand, generally d=
on't care.  Quarterly may be overkill, or it may be woefully inadequate. =
 It depends on what the server is doing.
I disagree with this on modern Linux (and BSD) kernels. Let's remove VM
from the discussion for a second. Most applications use the malloc(3)
command to allocate and the free(3) command to deallocate memory. C++
uses the new and delete to free, but the underlying calls are malloc(3)
and free(3).  AFAIK, the Linux malloc uses both the brk(2)/sbrk(3)
system calls as well as mmap(2) to allocate memory to the process. The
advantage of using mmap(2) is that memory pages can be allocated
non-contiguously (from a VM standpoint). the brk(2)/sbrk(2) always
increase (or decrease) the heap contiguously, but there are things that
can block sbrk(2). Malloc can, and recent versions of it can release
memory back to the OS.  So, assuming that the application does not have
a memory leak, the free(3) library call will return that chunk back to
the pool, and malloc will try to coalesce. It all depends on the
specific way the applicaiton allocates memory as well as the efficiency
of the specific malloc package. In terms of an application, it is more
important from the application standpoint how that application manages
its own memory. Additionally, an application does not have to use the
system's malloc (eg libc), it can override it with another version.

--=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