Using /tmp Vs. Shared memory...
Hi there,
I have a question on using /tmp Vs. Shared memory to get the best performance of my application.
My application is a performance intensive one and needs to store various data into a file as fast as possible.
So, I would like to get a performance comparison between the below mentioned two methods:
1) Application writing data into a file created in /tmp
2) Application using the shared memory for storing the data.
It would be very much appreciated if anyone could provide some info on this.
thanks and regards,
Rajesh Kumar.
[597 byte] By [
rajkum1] at [2007-11-14]
Unless you have multiple processes potentially trying to update the file or portion of memory that you're manipulating at the same time, what is the benefit to using shared memory? Isn't it just so you can have multiple users modify some portion of memory without the "whoever writes last wins" rule taking effect?
I think for performance reasons, you're best off trying to keep your application in physical RAM and if you're placing it in a tmpfs filesystem, that means you have to try and keep it from delving into your file mounted swap areas. Therefore, so long as you keep it in the physical RAM by correctly sizing either your shared memory segment size, or by making sure you don't start diving into file mounted swap, you're going to see better performance than if you tried whatever your application does on a "normal" mounted partition.
Realistically, I don't think you'll get more than 10% benefit going from tmpfs to shared memory segments given that both chunks of data are of equal size. Does anyone have numbers to the contrary?
Thanks for your reply!
For a comparitive study, I wrote a program which writes a small amount of data into a file. I used this program to compare the performance between writing into /tmp and into a hard disk. But to my surprise,
when the no. of "writes" is only ONCE, the time taken by both are almost the same. (half a msec!)
But when no. of "writes" is very large, say, 100,000, /tmp gave an average of 87usec and hard disk gave an average of 98usec.
Any clue on why writing into /tmp and writing into a hard disk give almost the same latency when we have only ONE "write" ?
In both the cases, out put file was already opened before going into the "write" loop.
Many thanks in advance!
rajesh
It's the file open requests... If you have to do this on disk versus going through memory first, you're going to see a bit of latency. This is why it's much faster to write out 10 files at 100M in size each versus writing out 1000 files at 1M each.
I didn't take into account how much activity you might be having with different files (and not just one or two) when considering your application performance, so perhaps my answer should now read more like - Depending on the number of files that you need to manipulate, you may end up being better off loading up your application into shared memory versus keeping it on a single tmpfs filesystem.
tmpfs should end up (all things equal) pretty close, but only real world perf tests will be able to gauge that.
regards,
jeff
Yes, I understand that. But I write only a constant amount of data at each time. The pseodo code of my test program is :
ofstream logfile;
logfile.open("file_name");
for(i=0;i<COUNT;i++)
logfile ><< some data<<endl;
}
Here, if the COUNT == 1, then writing into /tmp and hard disk takes half a msec. But if COUNT == 100,000, the ave. time takes for writing into /tmp is 89usec and into hard disk is 98usec.
As you can see from above, file is opened only once and so hw does the latency vary when it writes only once and when it writes several times, data being constant?
thanks!
rajesh.
>
