1

On a specific machine I use a lot of RAM to serve websites really fast directly from RAM (which by the way is working amazingly well). For this I have mounted a ramdisk in /etc/fstab (in debian 7, via tmpfs) like so;

tmpfs /ramd tmpfs defaults,relatime,size=2G 0 0

I run a bunch of scripts in crontab to sync dirs from disk into /ramd when /ramd is empty, and from /ramd to disk when the dirs exist.

Now, obviously, I need to sync from RAMdisk to harddisk before a reboot, and back again in reverse at bootup.

I used to just run the sync from crontab every several minutes, but this is really overkill, since it has power backup and so it never shuts down unplanned, basically the only time it needs ram to sync back to disk.

I looked around and experimented for a while now, for the best ways to accomplish this without crontab. Just running sync scripts as init.d scripts seems awfully complex for the task. The only dependency for the syncjob would be that the ram is still mounted, so that would probably be

Required-stop: mountkernfs

and the only dependency at startup would be that nginx has not yet started, and of course that fstab has already been processed.

Any insight on how to best accomplish this, either with or without init script, is very welcome.

The reason init.d seems a bit odd is that it would not hold up after OS changes or upgrades. There's enough custom made in the system as it is.

Improve this question
9
  • 1
    I'm somewhat curious as to why, if you do have enough RAM to do this, it ends up being faster than the ordinary FS mount, which should cache pages anyway. (Assuming it's a read-mostly workload, the need to sync the changes to disc shouldn't come up.) – Tom Hunt Dec 2 '15 at 17:31
  • Mostly because caching requires a pull before it exists.. At least on this setup it does. – Julius Dec 2 '15 at 17:33
  • Hmm. Might be able to emulate the benefits using a boot script that read all the pages to force them into cache. Something as simple as find /webroot -type f -exec cat {} \; >/dev/null might do it. Of course, this assumes there isn't sufficient memory pressure on the machine to cause pages to drop out of cache later. – Tom Hunt Dec 2 '15 at 17:37
  • And it assumes I would want to write and read from disk (all kinds of expiry and selective filetype config not even mentioning), which I just don't want, or at least not more than once after boot. I first used caching, but this (swapping all into ram) gave measurably faster results. – Julius Dec 2 '15 at 19:32
  • 1
    If you've got access to systemd, you should be able to do this with a oneshot service unit that requires a mount unit (for the tmpfs). You would put the copy from disk into tmpfs under ExecStart, and the copy from tmpfs into disk under ExecStop. If you configure the unit files under /etc/systemd, they should survive any OS upgrades. – Tom Hunt Dec 2 '15 at 20:07
1

Turns out Debian has its own thorough description of precisely what I was asking for. Found it when I was optimizing for SSD, at https://wiki.debian.org/SSDOptimization#Reduction_of_SSD_write_frequency_via_RAMDISK

For all of your information;

I'm currently using https://github.com/graysky2/anything-sync-daemon for all this. It's a splendid tool to speed up certain set dirs by throwing them synced to and from RAM. The manual: https://wiki.archlinux.org/index.php/Anything-sync-daemon It compiled perfectly in both Ubuntu 16.* and Debian.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.