You are not logged in.
A gameserver I'll be hosting in the near future performs a large amount of read/write operations on a large amount of files, which, in total, also sums up to a large filesize.
At first I was thinking to use a ramdisk to just cache all of the files in RAM and be over with it, however with the current plans we have this total filesize can grow quite big. Is there a way to have Linux cache these files upon read, and perform a writeback if the file hasn't been touched for a specific amount of time (in the order of minutes)?
EDIT:
Would it perhaps be possible to rely on automatic disk caching and handle writes via ramdisk attached as a union filesystem? Excuse me if I don't fully understand how union filesystems function.
Last edited by Sander Hoksbergen (2011-01-25 01:36:50)
Offline
How much RAM do you have? How large are the files in question?
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
How much RAM do you have? How large are the files in question?
An example configuration would be over 80.000+ files and 250MB in size total. However it can also grow to a configuration with 2GB of files (big dent in RAM). Some files are used less than others which is why I find it a waste to put *all* of it in a ramdisk/tmpfs.
Last edited by Sander Hoksbergen (2011-01-25 01:35:13)
Offline
I dunno how to do it otherwise.... how much RAM do you have? If it's 4 G for example, you can use 1/2 that for /dev/shm and no problems.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Using aufs with a size-limited tmpfs might do what you want.
Offline
A copy-on-write functionality seems to be exactly what I'm looking for. Is there a way to merge these two branches at any given time? Branch 1 being the read-only original files and Branch 2 being the copy-on-write edited files stored in RAM.
Offline
Fun fact: Linux actually uses your free RAM as filesystem cache by default anyway. I doubt you'd get better performance by rolling your own cache layer. The more free RAM you have though, the better this works obviously, so performance will go up if you buy yourself more RAM or limit the RAM that gets used by applications (with ulimit or something).
For example, I'm currently using 2.6GB of RAM, but another 7.3GB is being used by the kernel as cache (look at free -m). The files in /proc/sys/vm/ provide some tunables for this behaviour.
Offline
I agree with tavianator, letting the kernel to choose what to keep buffered is your best option.
Help me to improve ssh-rdp !
Retroarch User? Try my koko-aio shader !
Offline
Does this also work for writes though? The server is singlethreaded and locks up until the write has been completed. A ramdisk write buffer sounds better then.
Offline
If writes are stalling, then looking into your mount options and/or filesystem choice is what I'd recommend. The filesystems I use (ext4 and btrfs) have no trouble using the cache for writes and performing write-backs later.
Offline
write cache is bad for data integrity, the higher the cache, the higher the data you'll lose if something goes wrong.
Take a look to "commit" mount option.
Help me to improve ssh-rdp !
Retroarch User? Try my koko-aio shader !
Offline
I do all my writes (and reads) from a ram disk (boot from the hard drive as a degraded raid 1, then create a loopback file in /dev/shm which I add to the raid, and then remove the hard drive (adding it again later if I want to persist changes)) and the performance is huge orders of magnitude faster for writes than when using the hdd (its a very slow ssd to clarify), and a lot faster for reads as well...
I'd suggest using /dev/shm and mounting it as the read/write part of an aufs or unionfs over the top of your data (which you have as a read-only branch) would improve write performance noticably (but I hope the data is lose-able), and then every so often you could copy the data off to somewhere where it will remain (eg the readonly union branch on the harddrive)...
So all up, the answer would be yes, just a matter of how hard you try :-) and how important your data is :-p
Offline