It is fairly typical to make the size == the RAM, and just pray you (almost) never actually reach that and start swapping like crazy.

/dev/shm is essentially a ramdisk, only pretending to be a file, and it might get swapped to disk when the going gets tough. You can survive a page fault or two now and then. You can’t survive constant thrashing of your swap.

Because it pretends to be a file and lives in RAM (mostly) it makes an execellent vehicle for program communication with locks etc as a “shared memory” substitute. It’s easy to use; It lives in RAM (mostly); It is fault-tolerant (hitting swap if it has to); It’s fast

Greeting from Beijing
xuedi

I think as far as /dev/shm goes, the beauty of this being mounted like a normal file system is that you can write programs (and/or scripts) to use it like you would any other file system. If you have enough RAM available, it will be much more efficient than reading/writing a hard disk. If you’re not writing programs, then /dev/shm is of little consequence to you and does not do anything for you (unless you use a program which uses this). It really should be as if it does not even exist to the average user…but for a sysadmin, it’s good to be aware of it in the event you have a program (like Oracle) that is having strange problems. Then your awareness will lead you in the right direction when researching a solution.

As far as comments about using up RAM and slowing down the whole system…well you simply need to make good decisions about using it when it makes sense to use it, and not making your entire program use it. For example, you have to make the same decision about how much data you load into RAM at a time whether using /dev/shm or just by using a big buffer and passing a pointer between applications…lots of data uses lots of RAM and doesn’t matter whether it’s shm or somewhere else.

I’m speaking out my arse here, but I think mounting 8G shm on 8G RAM is perfectly fine as it’s referencing paged memory like any other program. There is a danger that if your program uses a significant amount, you can starve other programs in RAM by forcing them to swap…but if you’re in that situation, then the active program using SHM is going to use swap if you limit SHM to say, 2G or something…so either way you lose. In the end, don’t write programs that want to load 8G into RAM during runtime. Only load things into RAM if you need to use them right away. When you’re done using it, then free it.

Yes you are!

Like almost every manpage I’ve ever seen, this documentation assumes that you already know the stuff, and need a reminder of how to use it.

I’d like to use this–my system has 3 cpu’s and 4G memory, but runs erratically–freezing for anything from a fraction of a second to over a minute–particularly bothersome when viewing video from the hard drive, but it happens even when all I am doing is browsing.

While I understand the concept, (it is, after all an old idea,) this doesn’t help me apply it to my problem–if indeed it would help.

I’m still new to doing system admin on a linux box, though I have done many years of doing so on IBM mini’s and mainframes.

I’m old enough that my memory isn’t reliable, and my hands have tremors–making the use of the command line a pain in the (&O.

I know that I have a lot of study yet to do, but like all new systems, the amount of documentation is daunting, and much of it doesn’t help very much because it assumes a great many things–like all too much documentation written by programmers, it ignores the problems of those learning how to use things, and tends to be minimalistic and cryptic until you reach a threshold of knowledge (which I have yet to acquire.)

While reminder documentation is extremely useful, more details descriptions of what programs do and how they do it seem to me to be needed.

In general I’ve found that things which are used daily are over-documented, and things used rarely are massively under-documented. And programmers writing their own documentation are extremely likely to write only the most obscure parts of the tool instructions…because they are already intimately familiar with the main functions.

This is the kind of thing that leads to the extremely useless error messages generated by Windoze (Or an old database program I used once that gave only 4-digit error codes, all of which seemed to map to “call tech support,” bad enough, but the company no longer existed….

Am I alone in this perception?

thank you..

The equivalent for the BSDs is mfs, but there’s no standard of having it in any particular location – as far as I know anyway.

As an example, I have an external piece of hardware which only one program at a time can communicate with. I want to log data from this device as often as possible, but also run an “assay” – ie. tell it to do a sequence of tasks. I have implemented this in a client/server mode where the “server” does all of the communication and the clients request actions. The data logger requests readings as often as it can and the assay controller requests the device to change states at the appropriate times. In order to avoid conflicts each client program must check a “lock file” in /dev/shm to see if the server is available. If it is, then the client writes it own process ID ($$ in bash) to the lock runs it request, and then releases the lock (don’t forget that step!) by writing 0 back to the lock so other clients know that the server is available again.

All of this _could_ be done with a “normal” file, but would be a bit slower.

firstly, what is tmpfs and swap space? where they are stored?
second, if there are any difference how this will affect the performance of a system?
third, is there any method to allocate tmpfs or swap space for a particular program?

if my english is bad please forgive