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/15/2010 11:35 AM, Richard Pieri wrote:
> Some high performance database engines wire their cache (ex: Cach=E9). =
 Virtual machine monitors wire portions of the memory that they manage (e=
x: VMware Fusion, probably VMware Workstation but I don't have it handy t=
o see).  Some Java VMs wire their heap allocations (ex: Java HotSpot VM),=
 which is why I brought it up in the first place.
>
> There's a lot more wired memory in use out there than you suspect, I th=
ink.  Few apps wire all of their memory allocations but many wire the sla=
bs critical to performance.
In those cases, wiring in memory makes a lot of performance sense, but
those same systems, especially database servers, need a very high up
time.  Virtual machines are interesting in they have guest operating
systems that also do paging. Years ago I worked with IBM's VM370 with
OS/VS1 as the guest. VS1 was not very good in the paging and spooling
area. We could tell VM370 to manage VS1's page faults. We also found
that double spooling (letting VM370 manage the printers rather than VS1)
gave us better performance (eg. we got our payroll checks out faster).
We also found that the throughput of VS1 under VM370 (with several users
using CMS) was better than running VS1 native with the same batch load,
in this case payroll.

The bottom line is the reboot policy should be based upon what you are
running. Additionally, for an application to wire memory on Linux and
most Unix systems, the app must be a privileged app. A virtual machine
manager that has a kernel driver can do this. Additionally, the kernel
may retain some applications and libraries in physical memory after they
exit for a period of time. This feature was added because Unix/Linux
commands are generally small and frequently used.

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