This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature: System Administration

Improve system performance by moving your log files to RAM

By Ben Martin on July 16, 2008 (9:00:00 AM)

Share    Print    Comments   

The Ramlog project lets you keep your system logs in RAM while your machine is running and copies them to disk when you shut down. If you are running a laptop or mobile device with syslog enabled, Ramlog might help you increase your battery life or the life of the flash drive on your mobile device. As a side effect of using Ramlog, you will be less likely to be caught out by a daemon that suddenly starts sending a message to syslog every 30 seconds and saps your battery keeping the hard disk spinning.

The life of the flash drive is an important consideration if you are using a solid state drive. It is likely that the /usr partition does not get written to very much, with /var and /tmp taking the lion's share of disk writes compared to the handful of times you might save source code in your home directory per day. Moving your system logs to RAM means that the solid state drive will see a lot less write activity. That means it should take longer to start producing unwritable sectors. The tradeoff is that if the laptop crashes instead of shutting down gracefully, you will lose the logs that were in RAM, but most of the time on a laptop the logs are not mission-critical.

The repositories for openSUSE, Ubuntu, and Fedora do not contain packages for Ramlog. The project's home page includes .rpm files for Fedora, .deb files for Ubuntu, and a source tarball. I'll build from source on a 64-bit Fedora 8 machine using Ramlog version 1.1.0.

The first steps of installation are shown below. Note that the 1.1.0 tarball of Ramlog expands directly into the current directory instead of creating a new subdirectory. These steps put the files in place ready for the final stage of installation. If you are running Ubuntu, see the Ramlog INSTALL file for the commands that you should execute instead of the chkconfig ones shown here for Fedora.

$ mkdir ramlog-1.1.0 $ cd ramlog-1.1.0 $ tar xzvf /.../ramlog-1.1.0-1.tar.gz $ su ... # install -m 750 ramlog /etc/init.d/ramlog # install -m 444 ramlog.8.gz /usr/share/man/man8/ramlog.8.gz # install -m 755 ramlog.cron /etc/cron.daily/ramlog.cron # install -m 644 ramlog.logrotate /etc/logrotate.d/ramlog # chkconfig --add ramlog # chkconfig ramlog on

The getlogsize option to the ramlog command causes it to print how large your current /var/log directory is. You then select how large you want your RAM disk to be so that your log files will fit onto it. If you are using logrotate to keep your log files from growing infinitely, adding 30-50% to the current size of your log files should provide sufficient space in the RAM disk for your logging. If you do not set the size of your RAM disk explicitly then you are relying on the value that your distribution has selected for you. To explicitly set the value, edit your grub.conf file and append ramdisk_size=n, where n selects how many kilobytes to make the RAM disk. Because my existing /var/log was a little over 50MB, I selected a RAM disk size of 80MB.

# ./ramlog getlogsize Ramlog: Size of /var/log is: 52640 kbytes # vi /boot/grub/grub.conf ... title Fedora (2.6.24.4-64.fc8 ramlog) root (hd0,0) kernel /vmlinuz-2.6.24.4-64.fc8 ro root=/dev/VolGroup00/LogVol00 rhgb quiet ramdisk_size=80000 initrd /initrd-2.6.24.4-64.fc8.img

To start using Ramlog you can either reboot, or stop every program that is using /var/log, start ramlog, and then restart the programs you stopped. One upshot of rebooting is that your RAM disk size parameter will be in effect; if you try to force ramlog to start on a running system, you are at the mercy of whatever RAM disk size is currently available (64MB according to the Ramlog documentation). The below command shows you what is currently using /var/log; in my case, quite a few daemons and the X Window System are active, making a reboot the more attractive option for starting to use Ramlog. If you accidentally boot a kernel that uses a RAM disk that is too small, then Ramlog will fail to start during boot, your /var/log will remain on hard disk, and things will function as they did before you installed Ramlog.

# service ramlog teststartstop The list of open files: (You need to close below daemons if you want to start/stop ramlog manually) COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME auditd 1680 root 5w REG 253,0 4590592 3936085 /var/log/audit/audit.log rsyslogd 1934 root 2w REG 253,0 23860 3933163 /var/log/messages ... setrouble 1966 root 4w REG 253,0 131 3935366 /var/log/setroubleshoot/setroubleshootd.log-20080705 httpd 2053 root 2w REG 253,0 8160 3935447 /var/log/httpd/error_log ... cupsd 2178 root 11u REG 253,0 14729 3933123 /var/log/cups/access_log X 2430 root 0r REG 253,0 30710 3933132 /var/log/Xorg.0.log ... mysqld 25212 mysql 1w REG 253,0 1468 3935384 /var/log/mysqld.log ... Test result: ramlog cannot be started or stopped at the moment.

When you boot from a kernel that has a sufficient RAM disk size and the ramlog service is enabled, during system boot your /var/log directory is copied to a RAM disk and the RAM disk is mounted at /var/log. The contents of the log directory on hard disk are still available through the /var/log.hdd path. This allows you to see both filesystems if you want to perform any manual operations. For example, if you want to delete a file, you should delete it from /var/log.hdd to avoid it being copied back to the RAM disk the next time you reboot. As shown below, the log.hdd directory is located on the LogVol LVM, and /var/log itself is on the ram9 disk.

# df -h /var/log /var/log.hdd Filesystem Size Used Avail Use% Mounted on /dev/ram9 76M 52M 21M 72% /var/log /dev/mapper/VolGroup00-LogVol00 16G 11G 3.8G 75% /

If you want to save the log files from your RAM disk to your hard disk, execute service ramlog restart as root.

It would be nice if ramlog were aware of logrotate and kept the logrotate files themselves on your hard disk, storing only softlinks in the RAM disk. This would allow a smaller RAM disk to be used for storing only the log files that are still active. Perhaps the developers will consider this enhancement for future versions.

Wrap up

Knowing that you have a fixed chunk of RAM that contains your log files means that your laptop's hard disk doesn't have to spin up regularly if something needs to be logged by an overly verbose daemon. The fixed-size RAM disk Ramlog uses will keep an overly verbose daemon from exhausting all your system RAM. If you are using a solid state disk on a laptop with a few gigabytes of RAM, Ramlog can save you many write cycles on your solid state disk by sacrificing 50-80MB of RAM.

Ben Martin has been working on filesystems for more than 10 years. He completed his Ph.D. and now offers consulting services focused on libferris, filesystems, and search solutions.

Share    Print    Comments   

Comments

on Improve system performance by moving your log files to RAM

Note: Comments are owned by the poster. We are not responsible for their content.

Improve system performance by moving your log files to RAM

Posted by: Anonymous [ip: 150.3.84.204] on July 16, 2008 03:14 PM
ln -s /dev/null /var/log/messages

If you're going to keep logs in volatile memory, you'd be as well just chucking them into the bitbucket.

#

Re: Improve system performance by moving your log files to RAM

Posted by: Michael Shigorin on July 16, 2008 10:23 PM
1) why use kernel ramdisk and not tmpfs which doesn't require messing with bootloader?
2) re /dev/null, stopping syslogd/klogd might be better yet (albeit some logs would go to console then)

#

Improve system performance by moving your log files to RAM

Posted by: Anonymous [ip: 65.255.65.51] on July 16, 2008 03:19 PM
Just kill the logs better performance. Its about the same as what you suggest without the overhead.

#

Obvious questions

Posted by: Anonymous [ip: 141.123.223.100] on July 16, 2008 05:41 PM
1) What exactly, besides the theoreticals mentioned in the article, are the performance benefits of this? I don't see any metrics in your article to back your claims, and the website...well, it's a fairly typical open sourcer's website: absolutely no information. You make some interesting claims about performance, but without numbers to back it up, it's just bull.

2) What are the benefits of doing this as opposed to simply creating a ramdisk and modifying syslog.conf to put its files there? You could schedule logrotate to activate a little more frequently to back them up to ensure they're still captured.

3) Why not use something like syslog-ng or rsyslog which will output to a database? You gain some significant i/o improvements over simply writing to a text file AND those two products offer some other compelling benefits besides (like more granular logging, "teeing" of info, etc).

This looks like a solution in desperate need of a problem,.

#

Re: Obvious questions

Posted by: Anonymous [ip: 66.151.59.138] on July 17, 2008 04:18 AM
Are you serious? A database is the best thing for datamining,
but can never beat a properly tuned disk unless you have it
running on a beefy server with lots of ram.

Lets do some math:
Overhead of database + overhead of disk !< overhead of disk

One of the best things you can do is prefix the logfile location with a "-" such as:
*.* -/var/log/all.log

That prevents syslogs from calling sync() and flushing every write to disk. It also means there is
a chance of loosing some syslog lines, but it gives you much less disk writes.

Feel free to flame:
http://www.digitalprognosis.com/blog

#

Re(1): Obvious questions

Posted by: Anonymous [ip: 141.123.223.100] on July 17, 2008 08:23 PM
Except, dumbass, a large portion of the Linux community has MySQL already running on their machine, so pointing your logs to it is only a trivial change.

It also means there is a chance of loosing some syslog lines, but it gives you much less disk writes.

Prove it. Show me the numbers. Show me how many less disk writes this dumbass scheme is going to save me. Show me what I'm gaining for an obsurdly overly-complex solution to a non-problem.

#

Re(2): Obvious questions

Posted by: Anonymous [ip: 66.151.59.138] on July 18, 2008 02:06 PM
You've obviously never managed large clusters of Linux servers. Go away troll

#

Improve system performance by moving your log files to RAM

Posted by: Anonymous [ip: 85.16.50.170] on July 16, 2008 09:10 PM
One of the dumbest things ever. Especially during a crash you do *not* want your logs reside in memory but on disk.

#

Improve system performance by moving your log files to RAM

Posted by: Anonymous [ip: 98.233.32.36] on July 17, 2008 03:25 AM
how Linux.com accepted this article? two options: you save the logs or shutdown syslog.

#

Improve system performance by moving your log files to RAM

Posted by: Anonymous [ip: 166.128.247.36] on July 17, 2008 03:27 AM
I wouldn't do this on a Production Server.

#

Improve system performance by moving your log files to RAM

Posted by: Anonymous [ip: 134.146.240.8] on July 17, 2008 05:13 AM
Many people who have commented on this article, have note read the intial para, "...If you are running a laptop or mobile device with syslog enabled, Ramlog might help you increase your battery life or the life of the flash drive on your mobile device..."

#

Improve system performance by moving your log files to RAM

Posted by: Anonymous [ip: 63.226.97.79] on July 17, 2008 06:59 AM
You guys are all stupid. This is for a laptop or flash based system. Not some production server. The idea is that keeping the logs in RAM will help preserve battery and flash disks. Turning off logging is just as dumb. When I'm doing development I often need to see the logs. But I'm not depending on them so if the system does die I don't care about a few lost logs. But this program is nice because it will copy the logs from RAM to disk when you shutdown. So barring any system crashes you will still have access to past logs.

RTFA

#

Re: Improve system performance by moving your log files to RAM

Posted by: Anonymous [ip: 141.123.223.100] on July 17, 2008 08:26 PM
We did RTFA, and we're still not seeing the benefit. We get it, the author mentions repeatedly it's for laptops. Perhaps you, in your infinite brilliance, could explain it to us lowly slugs? Show us the numbers, show us what it saves, show us it's safe. Show us how it benefits over all of the other methods suggested as better options.

#

Re: Improve system performance by moving your log files to RAM

Posted by: Anonymous [ip: 200.111.44.196] on July 18, 2008 10:21 PM
My production server is a laptop, you insensitive clod!

#

Improve system performance by moving your log files to RAM

Posted by: Anonymous [ip: 212.95.96.30] on July 17, 2008 11:04 AM
i think that is a great idea for notebooks. push the logs in the ram and your harddrive have nothing to do (if you have enough ram for sure), if the harddrive don´t work it don´t need power. interesting solution what its worth for a deeper look behind the technic. i dunno what you all have? do you think that post is about a webserver for a high traffic website?
James from http://www.xeel.de

#

Improve system performance by moving your log files to RAM

Posted by: Anonymous [ip: 91.194.158.21] on July 17, 2008 01:26 PM
Really stupid idea, you can probably gain as much performance (unless you're logging *WAY* too much) by stopping syslogd syncing, using the "-" character as suggested above

#

Re: Improve system performance by moving your log files to RAM

Posted by: Anonymous [ip: 69.6.147.182] on July 17, 2008 09:15 PM
That may stop syncs for every log write, but doesn't ext2/3 sync every five seconds anyway, by default? So if there's a log write waiting in the buffer, it's still going to write it to the hard disk every five seconds.

This is not a stupid idea at all. It doesn't take a rocket scientist to figure out that on a laptop it can allow the hard disk to remain spun down longer. Even for SSDs, it can let the SATA link remain in low power mode longer. It's clearly better than sending logs to /dev/null, because this way you still get logs. On most laptops, most of the time, logs aren't critical, and if you're having a hardware problem, you can always turn ramlog off.

This is another good idea that will further improve our limited battery life on mobile systems. Anyone who thinks ramlog is a stupid idea is probably just that...

#

Re(1): Improve system performance by moving your log files to RAM

Posted by: Anonymous [ip: 74.69.65.169] on July 19, 2008 05:45 PM
It doesn't take a rocket scientist to figure out that on a laptop it can allow the hard disk to remain spun down longer.

No, but it does take a REAL scientist to figure out that you're just guessing about improvements. With absolutely no numbers backing any of these claims, they're just a huge, tightly coiled pile of dogshit.

#

A wider view.

Posted by: Anonymous [ip: 67.173.12.114] on July 17, 2008 03:42 PM
You have to look at the whole system to determine what to do. If you're disk IO bound, then moving the logs can have a big performance increase (assuming they're not on the same disks). Generally speaking, writes are a non-blocking operation but enough of them at one time will start to block. Syslog will sync write to the log files if you've not put a - in front of the path (like -/var/log/maillog which you may see on your distro) and that will cause problems if your db or application is busy doing work on the disk. So what to do? You can log to ram if you have some free, but you might lose some logs. If thats acceptable... Do it! If not, find another option like moving logs to another disk. Or, as I do, send all logs via network. I usually only get disk IO bound on our database servers and logging over network (which is not saturated) is a great solution.

You can't just blanket fix or make things faster. For example, if you're not disk IO bound, you won't see much if any performance gain by moving your logs to memory but you will lose some free memory.

#

Use tmpfs but check init scripts

Posted by: Anonymous [ip: 72.204.223.246] on July 17, 2008 11:04 PM
Logs feel to me (sysadmin) like an archaic holdover from server days. Desktops do not need them, and certainly not laptops (servers, yes). Linux hasn't graduated yet from a server OS mentality. Ubuntu is trying and some other distros, but all keep logs.

For my users, I put the logs in tmpfs (via fstab) and just let them disappear on shutdown. I am a sysadmin and even I don't see a rationale for keeping them. Yah, I've heard all the arguments about debugging etc. When you crash, or power fails, the last thing you want is disk activity. That spells file system corruption. There is also the OS performance issue. File writes being the major choke point. Why do you want to do that for every little daemon activity?

For us tmpfs works fine. We do use logs, and look at them in tmpfs, and that works fine.

The only minor thing: check any braindead init scripts in case they fail not finding their log folder. You'll have to mod them to create it if not found. This is really a "bug" that upstream should fix. Actually I just have a small pre-script that runs beforehand. It makes the folders in tmpfs at bootup to cover for the braindead scripts.

#

Improve system performance by moving your log files to RAM

Posted by: Anonymous [ip: 64.56.230.64] on July 18, 2008 12:33 AM
I stopped taking your article seriously when I realized you said that 80000 KB == 80MB. It does not. 80MB == 1024 * 80.

You have a Ph.D and you can not do very simple byte math?

Yes a tempfs is better because if it runs out of space it can use the swap. If a regular ramdisk runs out of space you're screwed. Not that it likely would, but still.

Also, Linux sometimes caches IO -- unless you tell it not to -- so really you're not gaining all that much here.

If you're going to throw your logs into a non-trustworthy ramdisk you might as well turn your syslog off.

-Isaac

#

Re: Improve system performance by moving your log files to RAM

Posted by: Anonymous [ip: 66.151.59.138] on July 18, 2008 02:09 PM
When flaming someone over pure semantics, perhaps you should make yours ok. Perhaps you meant "tmpfs" instead of tempfs? Hello pot, meet kettle. You are both black.

#

Improve system performance by moving your log files to RAM

Posted by: Anonymous [ip: 83.78.8.40] on July 18, 2008 08:53 AM
>You have a Ph.D and you can not do very simple byte math?

80000 KB == 80MB is true, but 80000 KiByte != 80 MB

Ambiguity !!! Please read the definition ( http://en.wikipedia.org/wiki/Kilobyte )


Some people must read the article again. It is not mentionned that this trick is for an important machine that needs to keep tracks of logs if something fails. It is just meant to save access to limited writes of SSD (about ~100k writes per block for NAND tech).

Stop trolling and if you don't find this article important don't link it to an high MySQL enterprise server, neither to performance except if a daemon goes crazy and sends thousands line of logs per second, which is, rare.

If logs are needed for a true read-only system, it is still possible to send them over a network, but this is another story...

#

Improve system performance by moving your log files to RAM

Posted by: Anonymous [ip: 208.47.135.227] on July 18, 2008 07:21 PM
have a syslog server and send all logs there.

#

Re: Improve system performance by moving your log files to RAM

Posted by: Anonymous [ip: 10.162.47.158] on July 23, 2008 01:08 PM
Hi all,

I have installed this tool on my linux box (running as router, security webcam, samba, apache, a few other applications), it's a small pc with no hard disk and Ubuntu Server installed on a USB pendrive.
I was worried that the many log write cycles would destroy my pendrive in a short time so I decided to log to ram and then regularly flush to the pendrive.
I decided to use ramlog and it looks like working fine, I dump the logs once a day; I'm happy to always have them ready even though they are not critical, in case of crash or power down (really really infrequent) it is acceptable to lose the last day.
I hope this helps.

scozzy

#

Improve system performance by moving your log files to RAM

Posted by: Anonymous [ip: 41.247.73.232] on August 03, 2008 06:04 AM
While I agree that this really won't improve performance, it does seem useful for flash based devices where you don't want to write too often - although flash based devices rarely need to store huge amount of logs, and when they do it's almost never feasible to do on the flash itself anyway.

So, I only see this useful for very non-general situations.

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya