This is post #2 in my December-long series on Linux VM performance tuning, Tuningmas.
I remember an old story about people having performance issues on their Windows servers. It would happen intermittently, and never when the system administrator was around. Turns out it was the pretty OpenGL screensaver, which would kick in and slow everything down tremendously. When the admin was around he’d be using the console of the server, so no screen saver, and no problems.
Graphical user interfaces make one-off administration tasks easier in some cases, but for virtual environments they come at a cost: additional RAM and CPU overhead. For a virtual environment you should shut them off, or install as little of them as you need, and only run them when you need them.
To disable the GUI from automatically starting at boot change this line in /etc/inittab from:
id:5:initdefault
to
id:3:initdefault
That way, on boot you’ll enter runlevel 3, which is full multiuser operations but no GUI (runlevel 5 is full multiuser with GUI). You can then start the GUI from the command line with the command ‘startx’ and exit by pressing Ctrl-Alt-Backspace.
Not so bad, eh? But don’t leave it running, and don’t use a fancy screensaver. :)
I started calling this series “Tuningmas” as a play on the fact I’m doing it in December and the Christian religious holiday that is nearby, temporally. Did you know that the word “Christmas” is a compound word that means “Christ’s Mass?” Until recently I hadn’t thought about it. Unlike most religious masses I encourage you to comment, especially if you see I’ve missed something, have made a mistake, or there’s something new since I posted this. There’s nothing holy about this blog, for sure. :)
Comments on this entry are closed.
For your 5 readers that use Solaris, type this at a root prompt:
svcadm disable svc:/application/graphical-login/gdm:default
Five, ha! Actually, though, I’ve wanted that command before, and now I know it.
You can also not install the full X (Gnome/KDE) suite during install – especially if you’re going to be SSHing to the box. Even without the full X suite, you can still run an X server on your local machine, SSH in with X forwarding on, run an X app on the server and see it native on your desktop. If you have a slow connection to your server, it can be painful but so would VNC, etc. You’d just need a few X packages installed and not Gnome or KDE (unless those are the apps you want to run). I’ll be glad to elaborate if this is interesting. ;)
Linux != RedHat.
True. Heck, Fedora != Red Hat, even. Given all the variants it’s difficult to write instructions for each, and my hope is that I can get someone to think “that’s an interesting idea” and subsequently look up the specifics on their own.
The Windows thing is real: at a previous job we had a firewall set up on a (then new) NT server. When the screensaver kicked in, the throughput of the firewall dropped dramatically. It was impressive. And laughable. (Along with a lot of other things about that mess).
On Debian run level 5 is the same as 2, 3 and 4, so the window manager (gdm/xdm/kdm etc.) that requires X11 has to be disabled or its startup script links in /etc/rc?.d/ tweaked, so it only starts in run level 5, for example. Or just skip X desktop environment installation when setting up the VM.