Hi John, Thanks for your reply.
Basically there is no real structure under /var/spool/asterisk/monitor - it's one directory. While 60 or so agents are on calls there will be 60 .wav file being written simultaneously to the RAM disk. The filesystem was ext3 but of course we are now using tmpfs. The recorded .wav files are moved out of RAM disk to the physical disk every minute - when this happens, the process only takes a second or two to write the files from RAM to the physical disk. Normally there is only about 80 or so MBs at a time. > Have you looked into a raw file system for disk writes? >(There was a time when raw file systems were common, >but disk performance has moved beyond that now for the most part.) I haven't look at this but perhaps it's an option ? Most people out there that run Asterisk call centers of this capacity and use call recording seem to have great success with using a RAM disk. The problem I'm picking up right now is that Asterisk's active call audio quality degrades when we write to the hard disk directly and not to RAM disk first. >From what I can see on the web a RAM disk is the best way to go for this - do you know if there's a way of picking up what caused the deadlock ? I've looked through /var/log/messages but there's no mention of anything with regards to the lockup. Thanks for your help so far. Kind regards David Wilson D c D a t a CNS, CLS, Linux+, LPIC1, LPIC2 Email/MSN: [EMAIL PROTECTED] Phone: 0860-1-LINUX Fax: 0866878971 Mobile: 0824147413 Skype: dave-wilson -----Original Message----- From: John Andersen [mailto:[EMAIL PROTECTED] Sent: 03 April 2007 10:58 AM To: opensuse@opensuse.org Subject: Re: [opensuse] OpenSuse 10.2 x86_64 RAM disk & server lock ups On Tuesday 03 April 2007, David Wilson wrote: > If I disable the RAM disk and record the conversation straight to hard disk > then everything is fine - the servers do not lock up. Unfortunately I have > to use the RAM disk due to performance issues with writing the recordings > straight to disk. It would seem that a deadlock would itself qualify as a performance issue. What is the underlying file structure? Could you not choose a different one with better performance? How about splitting the disk up so that not all recordings contend for the same disks/controllers? When you write from ramdisk, you incur another massive demand for memory as the fast ramdisk dumps onto the file system infrastructure which, of course can't keep up and therefore it starts demanding memory for buffers, etc. How much memory have you reserved for that? Have you looked into a raw file system for disk writes? (There was a time when raw file systems were common, but disk performance has moved beyond that now for the most part.) Have you looked at offloading disk writes to other machines via giga-bit ethernet or fiber? -- _____________________________________ John Andersen -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- This email and all contents are subject to the following disclaimer: http://www.dcdata.co.za/emaildisclaimer.html -- This email and all contents are subject to the following disclaimer: http://www.dcdata.co.za/emaildisclaimer.html -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
