On Sun, Jun 17, 2012 at 04:39:55PM +0200, Benny Amorsen wrote: > Vladimir Mikhelson <v...@mikhelson.com> writes: > > > But interestingly enough, yesterday morning I had zero (0) bytes in the > > swap file and still experienced missing DTMF detection on an outgoing > > call. > > Executables do not get written to swap, their pages just get discarded > under pressure, and reloaded directly from their original location on > disk. > > The only way to ensure that Asterisk always stays in memory is to use > the mlockall() system call; doing that would require patching Asterisk.
This is what the patch on DAHLIN-241 [1] is intended to do (only if Asterisk is run in the real-time priority class) [1] https://issues.asterisk.org/jira/browse/DAHLIN-241 What I feel is the important clue in this case is the problem, as reported, only occurs after this system has been idle for awhile. I just updated the patch since the memory locks weren't carried through after the fork call. When I apply the patch on the current head of the asterisk 1.8 branch and load all the asterisk modules by default: # asterisk -p # cat /proc/`pidof asterisk`/status | grep VmLck VmLck: 567268 kB You can see that just after load there is already 567MB locked. The systems on DAHLIN-241 started with 384M and were updated to 512M. -- Shaun Ruffell Digium, Inc. | Linux Kernel Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: www.digium.com & www.asterisk.org -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users