Hey guys,
I hope you are doing well, this is such a nice day!

My problem is simple but it's becoming hard for me to find a solution...
I ordered a new server at LSN and there is 16GB of RAM.

I've already :
- put /bin /usr /sbin /lib in ramfs
- all cgi, html files and even httpd logs in tmpfs with automatic tar to restore in case of reboot
- MySQL master has key_buffer_size=2048M and other big values
- MySQL slave is about the half

And despite of all this, the overall system uses about 8G of RAM.
The problem is that, I am afraid that the 8G others get bored.

What can I do?
Please help me, please help them.

What is the output of uname -a.

1 members found this post helpful.

Thanks a lot for your help Frankbell.
Here is uname -a :

Fire up a VM with 8g allocated to it?

1 members found this post helpful.

Too much RAM is a problem - that is a phrase that is almost never used in this forum. If I was you I would install about 3 Virtual Machines and then try and see if I can crack them open. You can also play some nice games (if that intrests you) with little or no lag.
Hope this helps.

1 members found this post helpful.

Use it for swap ....

1 members found this post helpful.

Why do you run a 32 bit OS on a machine with 16GB RAM? This way none of your applications will be able to address more than 3GB of RAM.

My kernel is 64
I built the system starting from a Zenwalk core, which is 32. So I guess a few binaries and libs still 32.

Two words: Mersenne primes

Ramdrive, Load up an 8G of ram drive with applications that you want to run mucho fast.

Are you sure?

I'm inclined to trust the uname output, which says your kernel is 32 bit.

Even if uname itself were 32 bit, it should report on the kernel.

There is no problem using 32 bit programs and libs with a 64 bit kernel with 16GB.

A ram drive doesn't have significant advantage for the things you mentioned vs. just trusting file caching to automatically do its job.
A tmpfs is great for any frequently created/deleted files that you DON'T want kept across a reboot. But if you see a need to back up files from a tmpfs to keep across reboot, you probably shouldn't choose a tmpfs at all.

ramdrive and tmpfs are a bit different but tend to be called the same. A reboot or crash will destroy any intermediate data.

http://www.alper.net/linuxunix/linux...ed-filesystem/

You can automate it on reboot if you want and use it like any mount point. I used to copy the raw data over on reboot then run applications from the ramdrive.

Many ideas exist on how to use it instead of a hard drive access.

http://www.cyberciti.biz/faq/howto-c...sk-filesystem/

Actually, ramfs is preferable IMO because tmpfs is not always in the RAM. ramfs insures you to be in ram, whatever happens.
That's why I've put the system dirs into ramfs, and in read-only

I use tmpfs only for things that have a risk to go bigger, such as user-writable areas.
Then I simply tar them with cron and they are restored at boot time.

@johnsfine: well, yes I'm sure, I compiled it myself and I guess I wouldn't see all the ram if it was 32. i686 does not mean 32b.

Actually, yes it does, i686 means 32 bit. And you will be able to see all of your RAM if you have PAE enabled in your 32 bit kernel. But that limits single processes to 3GB per process.

I see that as a reason tmpfs is better. ramfs is in ram even if you don't have enough ram and even if performance suffers because of your choice to use a ramfs. tmpfs is in ram if that was a good choice and automatically in swap space instead if other uses of ram would give better performance.

Again, I would trust the Linux file caching to do a better job than you do yourself. You copy a bunch of files from disk to ram once on start up, whether those files are needed or not and lumping all that work together where it is very noticeable. Assuming you have excess ram, the Linux file caching will copy each of those files from disk to ram once on first access and never read them from disk again (until next reboot) but only the files that are actually used. So it has less total disk access and spread out to be less noticeable.

Are you sure you compiled it correctly and are you sure you loaded the kernel you compiled?

See (trust) TobiSGD's answer.

Minor detail: If you compiled your own 32 bit kernel, you might have selected the option to limit each process to 2GB instead of 3GB and by doing so avoid the overrun of kernel virtual memory that is a significant risk when using a 32 bit kernel with 16GB of ram.

For most uses of Linux, the per process limit of 3G (or even 2GB) is not a significant limitation. Your ram is divided among many process and file caching and maybe ramfs and/or tmpfs, so you can easily make good use of 16GB with no one process getting 2GB. Exhausting kernel virtual memory is more often a serious limit in 32 bit Linux systems with very large ram.