How good is MemFS?

[MoreSawdust]

Anyone have experience with MemFS?

I'd like to put about 100MB of data into memory to speed up a specific Oracle process.

[VK2COT · Accepted solution]

Hello,

Memory-based file system is typically used
as storage for temporary files (for meta-data
intensive operations).

Some applications that might benefit from
memory-based file systems: compilers,
editors.

HP-UX uses HFS as the base for MemFS.

In HP-UX 11.23 MemFS is based on the buffer
cache approach.

Usually, MemFS is mounted on /tmp and
/var/tmp.

here is a comparison of similar memory-based
file systems in other operating systems:

Solaris: tmpfs
Linux: tmpfs
BSD: memfs
Tru64: MFS

As attractive as the performance aspects
sound, MemFS only works efficiently under
certain circumstances.

a) The biggest disadvantage is that
it does not preserve data across mounts.
It cannot be used to replace file systems
that store persistent data.

b) Since it uses memory that is a shared
resource, excessive use can adversely
affect other memory consumers.

c) MemFS requires a special backing store
to be associated with each of its instances.

Cheers,

VK2COT

[Hein van den Heuvel]

Are you planning on putting an Oracle Datafile there? An image or two?

If you put a data file there, then you obviously will put the DB at greater risk, relying 100 on teh redo log.

And if you put a datafile there, then your are also implying that you are 'smarter' than Oracle or rather you know something about the application performance behaviour that you can not express into Oracle.
Normally you are better of to just give the memory to Oracle an let it decide how to use it best. You may want to nudge Oracle by selecting minimum and maximums for specific memory pools and perhaps by doing some specific 'alter table cache' commands or the likes.

By putting an Oracle datafile on a memory file system, you may end up with 3 copies
- On the MFS
- In the buffer cache in front of the MFS (on certain operating systems)
- In the Oracle block buffer pool part of the SGA.
Not good use of memory.

hth,
Hein.

[MoreSawdust]

The "data" in question is the log files.

It this case, it's all or nothing... The database in question is essentially a pseudo-copy of a production database, and it's refreshed most weekends. The log files are getting slammed during a full import - HARD - to the point that the import stalls. The fact that the log files are being hit so hard was being masked by an FC60 sitting in front of them that was deinstalled recently (make me an offer!). It turns out the FC60 was just a RAM disk for the Oracle log files on this server... And - no, the FC60 ain't coming back... she's headed out of here.

I've got CPUs and memory to burn.

[Hein van den Heuvel]

Hmmm, it would seem that you might as well run 'disable logging'. Close to the same disaster level protection. Admittedly, if the system does not crash you are in a patter place, redo + archives to crieate a full picture. Can the archiving keep up?

How many MB/sec are we talking here?
What is the target storage... NOT raid-5 we hope?
Maybe the LOGBUFFER is incorrectly (too small) tuned? or checkpointing set way to aggresively?
Did you rotate the log groups such that archiving can be emptying the last redo(s) without disturbing the current redo being written?

Hope this helps some,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting

[Andres_13]

I think that could be better to put the database in "noarchivelog mode" if i well understood.

Regards!

[Michael Steele_2]

Sounds like you should check the raid levels on your FC-60 and use raid 1 or just raid 1 and not raid 05. Common mistake to use raid 5 with log files. Bad idea though.

As for memFS, this is an option that I don't know of anybody using so I would suggest you also stay in the mainstream. Why don't people use memfs? VXFS provides a much more sophisticated caching system then memfs.

HP-UX is not like /proc in Solaris, or /tmp and tmpfs, or Solaris swap which also uses tmpfs. All of these are kept in the Solaris kernel which is what you are suggesting with memfs. And would, in my opinion, be a duplication of vxfs caching and be adding another level of complication. Instead, look in async. Which can be mildly risky but is common enough.

Here's a very good thread on vxfs async:

http://forums12.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1205212522633+28353475&threadId=6646

http://forums12.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1205212618372+28353475&threadId=1091588

http://forums12.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1205212702763+28353475&threadId=583712

Ah! Here's the VXFS performance tuning pdf. Refer to stuff like 'nodatainlog'.

[Michael Steele_2]

BTW - that should be raid 5 for the data base and raid 1 for the log files only.

[Michael Steele_2]

Sorry, (* duh *)

http://docs.hp.com/en/5991-6385/5991-6385.pdf

[MoreSawdust]

Ummm... I think we're getting a little far afield here, due to a lack of clarity on my part.

The FC60 is deinstalled. I've determined since that it was, effectively, a very expensive memory cache for the log files.

The database is already in noarchivelog mode, and always will be. The users of the database understand there is no recovery except to reload, and that their changes, if any, will be lost whenever the database is reloaded, which is usually weekly, more or less on a schedule.

The only workload of importance is the full import from the source database - a production database on another server. So -this is an import throughput issue.

So far, I'm thinking that MemFS is a good possibility for simulating the FC60 we used to have running. From what I've read, to create a MemFS filesystem, it's just a mount command. The filesystem (and the files) go away after a umount, and the Oracle "imp" utility couldn't care less.

My thinking at this point is, for the duration of the import (ONLY), stuff the 100MB of log files into memory. Currently, the script that does the reload shuts down the database, then starts it in restricted mode, imports the export file, shuts down the database, then starts the database in normal mode. It would be very easy to insert the cp/mv, mount, and umount commands necessary to use MemFS for this limited purpose.

I'm not interested in the nologging option for tablespaces and tables because it doesn't *eliminate* the I/O on the log files during the import, just some or most of it. My goal is to get back to the same service level (throughput) we used to get when the FC60 was installed - if I can.

So - anybody have direct experience with MemFS?

[Hein van den Heuvel]

I would still like to see more thoughput numbers.
Are you sure it is the Redo, not the data itself?
Are you checkpointing a lot?
Check the alert log, making sure log_checkpoints_to_alert is on:
select name, value from v$parameter where name like '%alert%';


You mention "stuff the 100MB of log files into memory"
Is that 100M worth through which Oracle cycles?
Use: SQL> select * from v$log;
What are the 'bytes', what is the SEQUENCE# before, after import?
Divide bytes by 1024*1024, Multiply by that difference and you have the number of MB written. In how much time?

Ever run a statspack (AWR for 10g) around the import? What do the tablespace IO aggregates look like?

Here is the thing... 'no one' is running with redo on memfs.
So either you are very smart or......

hth,
Hein.