Comments on: Ramdisks – Now We Are Talking Hyperspace! http://www.linux-mag.com/id/7388/ Open Source, Open Standards Sat, 05 Oct 2013 13:48:18 +0000 hourly 1 http://wordpress.org/?v=3.1 By: mcobject http://www.linux-mag.com/id/7388/#comment-6588 mcobject Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7388/#comment-6588 Good article, Jeffrey. Timely, too, in that I'll be presenting a webinar on Thursday (June 25) titled "What Makes A Database System 'In-Memory'?" In it, I'll contrast in-memory database systems to:<br /> 1. using a database in a RAM disk<br /> 2. using DBMS cache to cache 100% of the database<br /> 3. using the "memory tables" feature offered by some DBMS <br /> 4. using solid-state disk<br /> <br /> All the approaches have pluses and minuses that we'll explore. Folks that found this article interesting/informative might also find the content in the webinar useful.<br /> <br /> Registration for the webinar is here:<br /> http://www.mcobject.com/in-memory-database-webinar-june-25 Good article, Jeffrey. Timely, too, in that I’ll be presenting a webinar on Thursday (June 25) titled “What Makes A Database System ‘In-Memory’?” In it, I’ll contrast in-memory database systems to:
1. using a database in a RAM disk
2. using DBMS cache to cache 100% of the database
3. using the “memory tables” feature offered by some DBMS
4. using solid-state disk

All the approaches have pluses and minuses that we’ll explore. Folks that found this article interesting/informative might also find the content in the webinar useful.

Registration for the webinar is here:
http://www.mcobject.com/in-memory-database-webinar-june-25

]]> By: sirvig http://www.linux-mag.com/id/7388/#comment-6589 sirvig Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7388/#comment-6589 Just another thumbs up to ramdisk. We recently had a situation where one of our ganglia collection servers was hitting some resource consumption issues. Specifially it was running at a steady 55% iowait because of all the ganglia type data that was being written to the database (to the point where we were seriously considering a redesign of our ganglia system and adding more hardware). As a solution we created a small tmpfs and moved the database to that location. We have a script that copies the database off to harddisk every 10 mins (and of course one that loads data at startup and unloads data at shutdown). That way if we have a major catastrophe on the server the most we could lose is ten minutes worth of performance data (which is acceptable for our purposes).<br /> <br /> Adding this tmpfs for the ganglia database completely eliminated the iowait issue. Now Im a big fan of ramdisks! Just another thumbs up to ramdisk. We recently had a situation where one of our ganglia collection servers was hitting some resource consumption issues. Specifially it was running at a steady 55% iowait because of all the ganglia type data that was being written to the database (to the point where we were seriously considering a redesign of our ganglia system and adding more hardware). As a solution we created a small tmpfs and moved the database to that location. We have a script that copies the database off to harddisk every 10 mins (and of course one that loads data at startup and unloads data at shutdown). That way if we have a major catastrophe on the server the most we could lose is ten minutes worth of performance data (which is acceptable for our purposes).

Adding this tmpfs for the ganglia database completely eliminated the iowait issue. Now Im a big fan of ramdisks!

]]> By: robzane http://www.linux-mag.com/id/7388/#comment-6590 robzane Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7388/#comment-6590 I use a ramdisk. I would like to set scheduler elevator=noop for the ramdisk but I want to use another scheduler for the hard disks.<br /> I can't understand if it is possible and how to do<br /> Thank You I use a ramdisk. I would like to set scheduler elevator=noop for the ramdisk but I want to use another scheduler for the hard disks.
I can’t understand if it is possible and how to do
Thank You

]]> By: laytonjb http://www.linux-mag.com/id/7388/#comment-6591 laytonjb Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7388/#comment-6591 I don't think you can have different schedulers for different file systems. The scheduler has to be defined at boot (and have to exist in the kernel or as a module). <br /> <br /> Did Google reveal anything?<br /> <br /> Jeff I don’t think you can have different schedulers for different file systems. The scheduler has to be defined at boot (and have to exist in the kernel or as a module).

Did Google reveal anything?

Jeff

]]> By: robzane http://www.linux-mag.com/id/7388/#comment-6592 robzane Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7388/#comment-6592 <p>(please correct my english, I\'m Italian...)<br /> With google I understood that I can use different schedulers for different hard disks setting fstab but not for ramdisk and this is what I can\'t understand </p> (please correct my english, I\’m Italian…)
With google I understood that I can use different schedulers for different hard disks setting fstab but not for ramdisk and this is what I can\’t understand

]]> By: rlegro http://www.linux-mag.com/id/7388/#comment-6593 rlegro Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7388/#comment-6593 <p>The Amiga operating system back in the late \'80s came with a default RAM disk, which was very useful in those days of limited storage (my first Amiga had no hard drive). But better yet, before long, the upgraded OS offered a \"Recoverable RAM disk\" (RRD) -- the contents of this would survive a soft reboot or a system crash. </p> <p>Of course the RRD used volatile system RAM and would not survive total loss of power, but given the system\'s high reliability overall, setting up so that frequently accessed data swapped to the recoverable disk was efficient and reasonably reliable. It was a good place to tuck downloads before checking them and consigning them to permanent storage, as well. And you could run programs from such a disk, so it could be used as a sort of virtual sandbox, too.</p> <p>You could also copy OS boot-up routines to RAM if you needed for some reason to frequently reboot, e.g., testing a new program or upgrade (part of the boot routine was in ROM, the rest on disk; you could also copy the BIOS portion to RRD). I tended to use the RRD as a fast cache for heavy-duty application data, such as image files during editing, and also to temporarily store fetches of BBS or web pages -- in sort, a scratch pad as mentioned in the article, only this was two decades ago, and didn\'t require special hardware.</p> <p>Add an uninterruptible power supply to such a recoverable RAM disk, and there would little you could not do with the latter. </p> The Amiga operating system back in the late \’80s came with a default RAM disk, which was very useful in those days of limited storage (my first Amiga had no hard drive). But better yet, before long, the upgraded OS offered a \”Recoverable RAM disk\” (RRD) — the contents of this would survive a soft reboot or a system crash.

Of course the RRD used volatile system RAM and would not survive total loss of power, but given the system\’s high reliability overall, setting up so that frequently accessed data swapped to the recoverable disk was efficient and reasonably reliable. It was a good place to tuck downloads before checking them and consigning them to permanent storage, as well. And you could run programs from such a disk, so it could be used as a sort of virtual sandbox, too.

You could also copy OS boot-up routines to RAM if you needed for some reason to frequently reboot, e.g., testing a new program or upgrade (part of the boot routine was in ROM, the rest on disk; you could also copy the BIOS portion to RRD). I tended to use the RRD as a fast cache for heavy-duty application data, such as image files during editing, and also to temporarily store fetches of BBS or web pages — in sort, a scratch pad as mentioned in the article, only this was two decades ago, and didn\’t require special hardware.

Add an uninterruptible power supply to such a recoverable RAM disk, and there would little you could not do with the latter.

]]> By: andreagelmini http://www.linux-mag.com/id/7388/#comment-6594 andreagelmini Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7388/#comment-6594 <p>Well, tmpfs can\'t dynamically grow, but you can always expand it with flag mount \"remount\".</p> <p>@robzane: the I/O schedulers are an attempt to solve latency problems of mechanical device. They\'re useless with RAM. They would be a waste of CPU cycles.</p> <p>Bye,<br /> Gelma </p> Well, tmpfs can\’t dynamically grow, but you can always expand it with flag mount \”remount\”.

@robzane: the I/O schedulers are an attempt to solve latency problems of mechanical device. They\’re useless with RAM. They would be a waste of CPU cycles.

Bye,
Gelma

]]> By: robzane http://www.linux-mag.com/id/7388/#comment-6595 robzane Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7388/#comment-6595 <p>@andrea: I want to use noop for memory ram disk and other schedulers for mechanical device! I think You haven\'t understood the question </p> @andrea: I want to use noop for memory ram disk and other schedulers for mechanical device! I think You haven\’t understood the question

]]>