2x RAM for swap space? huh?

I came across an article here which sparked my interest in blogging about this today. Yeah i know "Big can of worms"

I am calling this "swap talk" - This kind of talk has been around since the swap file was introduced, and the kernel limits on swap were introduced. (Meaning a very very long time. Say Kernel 1.x, 2.x)

It seems i answer this question quite a bit in my travels. The truth is many admins follow an _OLD_ rule of thumb that your swap partition should be twice the size of your main system RAM. I have heard some other old rules such as... swap == ram, and Swap space == 2GB size (if RAM > 2GB). There are lots more, just google it. :)

Here is what it boils down to.
How much do you know your user space applications?

Here are the Methods i like to use.

Workstation with 4GB of RAM:
4GB swap
why? because my user space apps are VMware Workstation for one, which if I have say 4 or 5 VM's running then I'm going to be swapping, so it makes sense. I could probobly get away with 2GB though. Most of the time you will be able to get away with very low amounts of swap space for Workstations if you have about 2GB of RAM available.

Server:
swap == ram ( if ram <= 4GB ) || swap == 4GB ( if ram > 4GB )

I like to use this rule with just about everything. I think its a good starting point and fits mostly everything, but it leads to another rule mentioned above "How much do you know your user space applications?"

So lets say you have a Database that is pretty consistent high load... Oracle and others might suggest 8GB of swap space.

Maybe you have a JBoss Server load balanced and it has high load spikes during certain times of the day, but not exactly consistent. So when you receive that load spike you all of a sudden see kswapd go mad with your CPU and your system comes to a crawl. Ummm.. well you might want to get more RAM or a bigger server to handle that load.

Which brings me to another method. Throw more ram in your system. You might not like swapping at all and if you see your application swapping then just throw more ram in your system.

Absolute Bottom line no matter which method your using. "How much do you know your user space applications?" Learn how your user space applications are using memory and adjust your systems accordingly.

I would like to know your methods. Please post comments on your methods.

About Time... Linux 64-bit Flash Player

This has been a long time in the waiting. I have been using a 64-bit Workstation for a few years now and finally i don't have to wait much longer to run a 64-bit Browser with a 64-bit Flash Player. Woohoo!

Prior to this release 32-bit Flash Player on 64-bit Linux has required the use of a plugin wrapper, which prevents full compatibility with 64-bit browsers. Some would just run all 32-bit browser and plugins to get the best support on their 64-bit Linux.

Until Now.. Maybe someone has the new flash built out on the Build Service.A quick search at http://software.opensuse.org/search for flash reveals that no one has built the 64-bit version yet. I guess i may have to dig in. :)

If your interested, you can download it from the adobe labs here

Check out these other related articles.

http://blogs.adobe.com/penguin.swf/2008/11/now_supporting_16_exabytes.html

http://linux.slashdot.org/firehose.pl?id=1739019&op=view

VDPAU: NVIDIA Releases New Video API for Linux

See the documentation here ftp://download.nvidia.com/XFree86/vdpau/doxygen/html/index.html

I Quote from the Documentation "The Video Decode and Presentation API for Unix (VDPAU) provides a complete solution for decoding, post-processing, compositing, and displaying compressed or uncompressed video streams. These video streams may be combined (composited) with bitmap content, to implement OSDs and other application user interfaces."

Sounds good eh... Well lets look at the benchmarks that were run with the new driver that includes this API.

NVIDIA VDPAU Benchmarks

I think the benchmarks speak for themselves.

Please post comments on your thoughts about this NVIDIA API...

LZMA compression becoming the better choice.

LZMA - Lempel-Ziv-Markov chain algorithm
http://en.wikipedia.org/wiki/LZMA

If you have not heard about it, certainly start reading up on it and DO use it. If your using bzip2 currently then your going to like this even more.

LZMA is currently being used in openSUSE today. Have you been wondering why the install is quicker for both openSUSE 11.X and SLE11? We now use lzma to compress the content in our rpm's. The decompression is quite a bit faster than the bzip2 that was used prior. This is just one reason why its faster, but certainly adds to it quite a bit, not to mention it makes the rpm's a bit smaller too.

LZMA has several levels of compression from 1-9. According to the man page on lzma it states the following "The first two (-1 and -2) are designed for fast compression speed. -3 .. -9 provide good to excellent compression ratio but require more CPU time and system memory. For relatively fast compression with medium compression ratio -1 is the recommended setting. It's faster than 'bzip2 --fast' and usually creates smaller files than 'bzip2 --best'. -2 makes somewhat smaller files but doubles the compression time close to what 'bzip2 --best' takes." I have been happy with using level -2 since it is close to bzip2 in speed and also creates smaller files. The standard level they are using for the openSUSE rpm's is -2. By default LZMA uses level -7 which does take quite a bit more time to compress, but you certainly will be happy with the size of the file after the compression. Amazing!!

The Bad News: Currently in the Stable releases of openSUSE and SLE tar does not support LZMA.
The Good News: The version of tar in the upcoming releases of openSUSE 11.1 and SLE 11 will support LZMA. I have also heard that the openSUSE build service also supports tar.lzma for factory builds currently.

The bad news is not so bad because there is a way to get around it of course.

Building a .tlz or .tar.lzma compresses archive pre-openSUSE 11.1 / pre-SLE 11:

with tar executing lzma:
1. tar --use-compress-program=/usr/bin/lzma -cvf some_archive_file.tlz some_archive_directory/

without tar executing lzma:
1. tar -cvf - some_files | lzma -2 > some_archive_file.tlz

Note: when you use method 1 with tar executing lzma it defaults to the -7 compression level. If you don't want to use that level then its preferred that you use the method without tar executing the compression program. Notice after the pipe you see the lzma switch with -2, which you can substitute with any number from 1-9 for your compression level.

Happy Compressing...
Enjoy!