tmpfs recording

Posted:
Thu Oct 29, 2009 9:55 am
by robin
Hi, working on my new Vicidial server and I was wondering if my fstab lists this:
tmpfs /var/spool/asterisk/monitor tmpfs rw 0 0
means that I'm recording to tmpfs? Or am I missing the point here? And if I do record to tmpfs, does this mean I'm recording to RAM? I've messed up a few expensive harddisks with recording already, so I'd really like to make sure I'm not killing more of them by making wrong assumptions...
tnx.

Posted:
Thu Oct 29, 2009 2:14 pm
by mflorell
That should be the case, what does 'df -k' output look like?

Posted:
Fri Oct 30, 2009 1:44 am
by robin
df -k gives me the following:
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/cciss/c0d0p1 67606164 2428844 61743028 4% /
tmpfs 4546616 0 4546616 0% /lib/init/rw
varrun 4546616 92 4546524 1% /var/run
varlock 4546616 0 4546616 0% /var/lock
udev 4546616 156 4546460 1% /dev
tmpfs 4546616 0 4546616 0% /dev/shm
lrm 4546616 2560 4544056 1% /lib/modules/2.6.28-16-server/volatile
tmpfs 4546616 0 4546616 0% /var/spool/asterisk/monitor
so i guess that means it works. Does it expand automagically?
I have these lines in my crontab:
0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57 * * * * /usr/share/astguiclient/AST_CRON_audio_1_move_mix.pl
#0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57 * * * * /usr/share/astguiclient/AST_CRON_audio_1_move_VDonly.pl
Should I be doing something with these as well? I guess I do, but tips are welcome. The idea is to record to tmpfs and then move the audio somewhere else every 10 minutes or so. Then I'd like another machine to do the mixing. Any tips on this one are welcome as well...

Posted:
Fri Oct 30, 2009 5:19 am
by spaquet
I have this running on my server and here is what I saw:
Yes files are first recorded to tmpfs, but as live memory is not as big as hard drive space, files (-in and -out) are drop on disc at the appropriate time.
The idea behind using tmpfs is to by pass disc critical path and take advantage of fast writing speed of live memory.
Once on disc, the scripts you mentioned (which are basic cron scripts) are mixing files together since asterisk records in and out streams in separate files and move the resulting audio file to a proper place.
you can edit frequency using crontab -e (as root) or webmin interface, which is very simple to use.

Posted:
Fri Oct 30, 2009 5:30 am
by robin
spaquet, thank you for your repsonse.
What would be good intervals for these scripts? Or could I run them just once/twice a day (after shifts or in breaktime)? Or could I skip these scripts here and just have the files moved to another machine every 15 minutes or so and have that machine do the mixing/compressing?
Hmm, maybe I should just try different approaches and will find out the best way to do this for my situation...
thnx!

Posted:
Fri Oct 30, 2009 7:10 am
by spaquet
Well I let the default schedule. From my point of view these processes are not that resource consuming.
I just changed scheduling of the WAV to mp3 script. I set it up to 1 hour instead on every 2 minutes.
By the way, when changing scheduling be sure to keep the order. If you look closely you will see that the first one is scheduled every 2 minutes but on odd ones and the second on even. Thus you mix files before moving to an other directory.

Posted:
Fri Oct 30, 2009 7:22 am
by robin
I'll keep the order in order (strange sentence...). I'll try the setup with a change in the WAV -> MP3 first and monitor what is going on.
The resources on my boxes was not really the problem, it is the demolition of the harddisks with all that writing.

Posted:
Fri Oct 30, 2009 11:29 am
by spaquet
Yes I know, I should have written: keep the order to have the process flow not disturbed....
Any way, regarding your hard drive, it's a shame, but you have no choice.
I tested several solutions (open source, paid, etc.) all are doing the same.
Just keep some spare and wait for the next hard drive to crash...


Posted:
Fri Oct 30, 2009 1:28 pm
by robin
Ah well, RAID and spare disks on the shelve will get me trough winter I guess..
tnx for your replies.