vicidial.org

I am using

Kernel Version 2.6.18-92.el5.vnow (SMP)
Distro Name CentOS release 5 (Final)

In my cron , I have

## Flush Memory :/var/spool/cron/crontabs
----------------------------------------------------------------------
#### Flush cache after every 20 minutes
29,59 * * * 1,2,3,4,5,6,7 sync; echo 3 > /proc/sys/vm/drop_caches

But still every 2 hrs , I see my memory touching 87%...

There are several suitable screens on:
2894.ASTfastlog (Detached)
2976.astshell (Detached)
3135.ASTlisten (Detached)
2983.asterisk (Detached)
2892.ASTVDadapt (Detached)
3138.ASTVDauto (Detached)
3141.ASTVDremote (Detached)
3129.ASTupdate (Detached)
3132.ASTsend (Detached)

What could be the reason ?

Is this due to NOT updated kernel ?

I think this should be made sticky. Same old questions regarding Linux memory management.

Traditional Unix tools like 'top' often report a surprisingly small amount of free memory after a system has been running for a while. For instance, after about 3 hours of uptime, the machine I'm writing this on reports under 60 MB of free memory, even though I have 512 MB of RAM on the system. Where does it all go?

The biggest place it's being used is in the disk cache, which is currently over 290 MB. This is reported by top as "cached". Cached memory is essentially free, in that it can be replaced quickly if a running (or newly starting) program needs the memory.

The reason Linux uses so much memory for disk cache is because the RAM is wasted if it isn't used. Keeping the cache means that if something needs the same data again, there's a good chance it will still be in the cache in memory. Fetching the information from there is around 1,000 times quicker than getting it from the hard disk. If it's not found in the cache, the hard disk needs to be read anyway, but in that case nothing has been lost in time.

http://www.linuxhowtos.org/System/Linux ... gement.htm

Matt can we make this sticky?

I understood but didnt understood the solution of the problem.

made it sticky.

If you've read thru the document, then you should have understood that there is no problem in the first place at all.

gmcust3 wrote:I understood but didnt understood the solution of the problem.

RAM is DDR3.

As most of then when It reaches 80% or so , I see call flow getting slow..

Physical Memory reach in SCARY RED.

Cache memory is around 80% of the Physical Memory.

No transfer happening... Voice break but rebooting the server solves all issues..

In 2.0.4 I never faced this issue , though I have the same line in cron .

On another server with same Vici , I don't face this issue.

Its 92% now and is in RED.

[root@vici ~]# free
total used free shared buffers cached
Mem: 3359592 3086880 272712 0 93060 2775200
-/+ buffers/cache: 218620 3140972
Swap: 1044216 0 1044216
[root@vici ~]#


..............................

Was trying to do the 3rd Party Transfer and IT didn't happen..

Rebooting the server now..

Pl advice what to do ..

Feedback from CentOS Forum :

That is not a CentOS kernel and you seem not to have updated for a very long time - still at CentOS 5.0 and we are now at 5.4 + subsequent updates. After this long without updates might want to consider an anaconda upgrade. If you don't upgrade you are left with a system with known security vulnerabilities and bugs. See the CentOS 5.4 Release Notes for the update procedure.

Mr Gardo , Any further guidance will be highly appreciated.

If you have read through the article I posted and understood it's meaning, you'll know that a high cache memory is NORMAL and very good for linux system. The problems you're encountering is not due to high system memory cache. It might be something else.

gmcust3 wrote:RAM is DDR3.

As most of then when It reaches 80% or so , I see call flow getting slow..

Physical Memory reach in SCARY RED.

Cache memory is around 80% of the Physical Memory.

No transfer happening... Voice break but rebooting the server solves all issues..

In 2.0.4 I never faced this issue , though I have the same line in cron .

On another server with same Vici , I don't face this issue.

If you don't mind , what could be the problem ?

As it happens when it reaches 90% or more.

Anyways to debug and post the results here ?

There could be a number of reasons. It would help if you can post the load average of the system when the problem occurs.

put the following line in crontab-e

10 * * * * sync; echo 3 > /proc/sys/vm/drop_caches

and also to keep the eye on the system performance on web use phpsysinfo and make this phpsysinfo/index.php to auto refresh in every 35 seconds so u can manually give command
sync; echo 3 > /proc/sys/vm/drop_caches on the terminal

When I reach this state, I get Terrible Voice Break Up.

After Restarting, All becomes normal and run for 2-3 hrs and then I again have to restart the server.

I have

10 * * * * sync; echo 3 > /proc/sys/vm/drop_caches

But It doesn't free and red bar stays !!!

Any advice ?

It would really help if you can post the output of "top -c" when you encounter voice breakups.

top -c

top - 12:09:28 up 18:52, 3 users, load average: 0.19, 0.17, 0.11
Tasks: 123 total, 1 running, 122 sleeping, 0 stopped, 0 zombie
Cpu(s): 7.3%us, 1.7%sy, 0.0%ni, 90.3%id, 0.2%wa, 0.0%hi, 0.5%si, 0.0%st
Mem: 2073868k total, 2018308k used, 55560k free, 144424k buffers
Swap: 1044216k total, 0k used, 1044216k free, 1641832k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2262 mysql 23 0 141m 27m 4920 S 3.0 1.4 3:59.28 /usr/libexec/mysqld
2628 root 15 0 38624 14m 5180 S 1.7 0.7 6:41.97 /usr/sbin/asterisk
24881 root 18 0 6260 4464 1760 S 1.0 0.2 0:00.03 /usr/bin/perl /usr/
24883 root 20 0 6260 4424 1740 S 1.0 0.2 0:00.03 /usr/bin/perl /usr/
24887 root 21 0 6260 4428 1740 S 1.0 0.2 0:00.03 /usr/bin/perl /usr/
24902 root 19 0 6260 4420 1740 S 1.0 0.2 0:00.03 /usr/bin/perl /usr/
24910 root 19 0 6260 4424 1740 S 1.0 0.2 0:00.03 /usr/bin/perl /usr/
24912 root 19 0 6260 4424 1740 S 1.0 0.2 0:00.03 /usr/bin/perl /usr/
1088 apache 16 0 61376 10m 6436 S 0.7 0.5 0:03.19 /usr/sbin/httpd
2798 root 16 0 12424 7128 2752 S 0.7 0.3 1:43.79 /usr/bin/perl /usr/
5260 apache 15 0 58560 8680 4732 S 0.7 0.4 0:02.37 /usr/sbin/httpd
16295 apache 15 0 58320 7844 4140 S 0.7 0.4 0:01.04 /usr/sbin/httpd
20703 apache 15 0 61524 10m 6436 S 0.7 0.5 0:04.60 /usr/sbin/httpd
21479 apache 16 0 61496 10m 6464 S 0.3 0.5 0:04.55 /usr/sbin/httpd
23083 apache 15 0 58604 8724 4736 S 0.3 0.4 0:04.14 /usr/sbin/httpd
23213 apache 15 0 58592 8712 4736 S 0.3 0.4 0:04.08 /usr/sbin/httpd
28922 apache 15 0 58564 8684 4732 S 0.3 0.4 0:03.71 /usr/sbin/httpd

I am having this kind of problem too.
When it reaches 80%. Transfers are breaking up, Line is congested or busy.
_____________________________________________________________

Goautodial CE 2.1
Vicidial SVN 2.4-309a BUILD: 110430-1642
Asterisk 1.4.39.1-vici
Dahdi 2.4.1
VtigerCRM 5.1.0
Sangoma 3.5.20
CentOS 5.6 as base

breakup at 80% is "overload". You need to build a cluster. (add another server to your existing Vicidial setup).

This can be done by building another vicidial server and "clustering" it with the first or by moving mysql onto a different server. There are clustering / multi-server instructions available online.

Alternately, of course, you could simply get a "bigger" server.

What's the output of the following commands:

1. free -m
2. top -c

AZNCUTE wrote:I am having this kind of problem too.
When it reaches 80%. Transfers are breaking up, Line is congested or busy.

OK this is what my Dialer Specs is before:

Processors 4
Model Intel(R) Core(TM) i3 CPU 540 @ 3.07GHz
CPU Speed 3.07 GHz
Cache Size 4.00 MB
System Bogomips 24533.69
Memory 4Gb

Now I added another 4Gb which makes 8Gb total memory and it solves the problem. But the total physical memory is still increasing rapidly from 5% to 18% in 30 Minutes. Consuming 1.40Gb of 7.82Gb memory. I also noticed that Cached is the culprit. Is there a way to flush this Cached items? I know that a system reboot will "Flush Out" all the memory but I really don't like it in that way.

Please Help!

What's the output of the following commands

Last login: Tue Aug 2 16:10:55 2011 from 122.54.235.162

Welcome to GoAutoDial!!!
-------------------------------------------------
-------------------------------------------------

[root@go ~]# top -c
top - 17:02:02 up 1:37, 2 users, load average: 0.76, 0.88, 1.11
Tasks: 225 total, 1 running, 224 sleeping, 0 stopped, 0 zombie
Cpu(s): 19.2%us, 3.7%sy, 0.0%ni, 76.1%id, 0.3%wa, 0.3%hi, 0.4%si, 0.0%st
Mem: 8197964k total, 1905504k used, 6292460k free, 47904k buffers
Swap: 1044216k total, 0k used, 1044216k free, 1400604k cached

Memory Usage
Type Percent Capacity Free Used Size
Physical Memory 23% 6.03 GB 1.79 GB 7.82 GB
- Kernel + applications 5% 376.96 MB
- Buffers 1% 47.48 MB
- Cached 18% 1.38 GB
Disk Swap 0% 1019.74 MB 0.00 KB 1019.74 MB

Mounted Filesystems
Mount Type Partition Percent Capacity Free Used Size
/boot ext3 /dev/sda1 12% (1%) 82.07 MB 11.55 MB 98.72 MB
/ ext3 /dev/sda2 2% 419.22 GB 7.66 GB 450.11 GB
/dev/shm tmpfs tmpfs 0% (1%) 3.91 GB 0.00 KB 3.91 GB
Totals : 2% 423.21 GB 7.67 GB 454.12 GB

MySQL will always consume most of your memory to cache. This cache is actually available memory, but doubles as "if it has not been touched" mysql cache memory to speed up mysql operations. If mysql has need of data that still resides untouched in some of that cache, it can access it much faster than "disk". IE: The eating of cache is a "Feature" not a bug.

This has been covered a few times on the forums, there are several links to it.

But the question is: Are you recording all calls or using memory for something heavily besides this (not "stock")? Have you altered your memory allocation for RAM drives or anything else? As a rule, GoAutoDial clients do not seem to complain about memory issues if they have at least 2G RAM, and you had 4G ...

Sorry to disappoint you sir william, I didn't mean to offend you. What you say is that in order for it to run much better is to add more RAM right? Then all will good. right?

? Offend? Did you? Not that I am aware of.

And ... No. I don't think more memory will "solve" your problem, although it may alleviate it. The question is what exactly the problem is. Try not discussing the memory, and just describe the details of the problem itself. (Details ...)

AZNCUTE wrote:Transfers are breaking up, Line is congested or busy.

And how about some CLI output from the problem moment, on a problem call?

Then: Show cli output showing the "80%" (from a moment when the "problem" occurs) just to be sure we are all on the same page here.

Ok sir william, Will do this night shift.

Hi! this also happened to me last week on another server aside from the other thread I posted. How many agents are running on your existing hardware?

I also saw red on the memory usage as well. Thanks William!


Goautodial 2.1 (just 4 seats)
VICIDIAL VERSION: 2.4-325c BUILD: 110430-1924
HP Intel Zeon Dual Core 3.0
2 gig ddr
80 gig

Please also check the logs below. Did you also experience this?



[Sep 7 19:11:29] VERBOSE[18062] logger.c: [Sep 7 19:11:29] -- AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... ---------- completed, returning 0
[Sep 7 19:11:29] VERBOSE[18063] logger.c: [Sep 7 19:11:29] == Spawn extension (default, 8309, 3) exited non-zero on 'Local/58600051@default-86c8,1'
[Sep 7 19:11:29] VERBOSE[18063] logger.c: [Sep 7 19:11:29] -- Executing [h@default:1] DeadAGI("Local/58600051@default-86c8,1", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0---------------") in new stack
[Sep 7 19:11:29] VERBOSE[18063] logger.c: [Sep 7 19:11:29] -- AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... ---------- completed, returning 0
[Sep 7 19:11:29] VERBOSE[18437] logger.c: [Sep 7 19:11:29] == Parsing '/etc/asterisk/manager.conf': [Sep 7 19:11:29] VERBOSE[18437] logger.c: [Sep 7 19:11:29] Found
[Sep 7 19:11:29] VERBOSE[18437] logger.c: [Sep 7 19:11:29] == Manager 'sendcron' logged on from 127.0.0.1
[Sep 7 19:11:29] VERBOSE[18438] logger.c: [Sep 7 19:11:29] == Parsing '/etc/asterisk/manager.conf': [Sep 7 19:11:29] VERBOSE[18438] logger.c: [Sep 7 19:11:29] Found
[Sep 7 19:11:29] VERBOSE[18438] logger.c: [Sep 7 19:11:29] == Manager 'sendcron' logged on from 127.0.0.1
[Sep 7 19:11:31] VERBOSE[18424] logger.c: [Sep 7 19:11:31] == Manager 'sendcron' logged off from 127.0.0.1
[Sep 7 19:11:31] VERBOSE[18429] logger.c: [Sep 7 19:11:31] == Manager 'sendcron' logged off from 127.0.0.1
[Sep 7 19:11:31] VERBOSE[18437] logger.c: [Sep 7 19:11:31] == Manager 'sendcron' logged off from 127.0.0.1
[Sep 7 19:11:31] VERBOSE[18438] logger.c: [Sep 7 19:11:31] == Manager 'sendcron' logged off from 127.0.0.1
[Sep 7 19:12:01] VERBOSE[18868] logger.c: [Sep 7 19:12:01] == Parsing '/etc/asterisk/manager.conf': [Sep 7 19:12:01] VERBOSE[18868] logger.c: [Sep 7 19:12:01] Found
[Sep 7 19:12:01] VERBOSE[18868] logger.c: [Sep 7 19:12:01] == Manager 'sendcron' logged on from 127.0.0.1
[Sep 7 19:12:01] VERBOSE[18869] logger.c: [Sep 7 19:12:01] == Parsing '/etc/asterisk/manager.conf': [Sep 7 19:12:01] VERBOSE[18869] logger.c: [Sep 7 19:12:01] Found
[Sep 7 19:12:01] VERBOSE[18869] logger.c: [Sep 7 19:12:01] == Manager 'sendcron' logged on from 127.0.0.1
[Sep 7 19:12:01] VERBOSE[18868] logger.c: [Sep 7 19:12:01] == Manager 'sendcron' logged off from 127.0.0.1
[Sep 7 19:12:02] VERBOSE[18941] logger.c: [Sep 7 19:12:02] == Parsing '/etc/asterisk/manager.conf': [Sep 7 19:12:02] VERBOSE[18941] logger.c: [Sep 7 19:12:02] Found
[Sep 7 19:12:02] VERBOSE[18941] logger.c: [Sep 7 19:12:02] == Manager 'sendcron' logged on from 127.0.0.1
[Sep 7 19:12:02] VERBOSE[18942] logger.c: [Sep 7 19:12:02] -- Executing [919123542157@default:1] AGI("Local/919123542157@default-b93b,2", "agi://127.0.0.1:4577/call_log") in new stack
[Sep 7 19:12:02] VERBOSE[18942] logger.c: [Sep 7 19:12:02] -- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
[Sep 7 19:12:02] VERBOSE[18942] logger.c: [Sep 7 19:12:02] -- Executing [919123542157@default:2] Dial("Local/919123542157@default-b93b,2", "SIP/19123542157@goautodial||tTo") in new stack
[Sep 7 19:12:02] VERBOSE[18942] logger.c: [Sep 7 19:12:02] -- Called 19123542157@goautodial
[Sep 7 19:12:02] VERBOSE[18944] logger.c: [Sep 7 19:12:02] == Parsing '/etc/asterisk/manager.conf': [Sep 7 19:12:02] VERBOSE[18944] logger.c: [Sep 7 19:12:02] Found
[Sep 7 19:12:02] VERBOSE[18944] logger.c: [Sep 7 19:12:02] == Manager 'sendcron' logged on from 127.0.0.1
[Sep 7 19:12:02] VERBOSE[18945] logger.c: [Sep 7 19:12:02] -- Executing [915618442157@default:1] AGI("Local/915618442157@default-cebd,2", "agi://127.0.0.1:4577/call_log") in new stack
[Sep 7 19:12:02] VERBOSE[18945] logger.c: [Sep 7 19:12:02] -- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
[Sep 7 19:12:02] VERBOSE[18945] logger.c: [Sep 7 19:12:02] -- Executing [915618442157@default:2] Dial("Local/915618442157@default-cebd,2", "SIP/15618442157@goautodial||tTo") in new stack
[Sep 7 19:12:02] VERBOSE[18945] logger.c: [Sep 7 19:12:02] -- Called 15618442157@goautodial
[Sep 7 19:12:03] ERROR[17909] utils.c: write() returned error: Broken pipe
[Sep 7 19:12:03] ERROR[17909] utils.c: write() returned error: Broken pipe
[Sep 7 19:12:03] ERROR[17909] utils.c: write() returned error: Broken pipe
[Sep 7 19:12:03] VERBOSE[17909] logger.c: [Sep 7 19:12:03] == Manager 'sendcron' logged off from 127.0.0.1
[Sep 7 19:12:03] VERBOSE[17910] logger.c: [Sep 7 19:12:03] == Spawn extension (default, 912395742157, 2) exited non-zero on 'Local/912395742157@default-462d,2'
[Sep 7 19:12:03] VERBOSE[17910] logger.c: [Sep 7 19:12:03] -- Executing [h@default:1] DeadAGI("Local/912395742157@default-462d,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0-----CANCEL----------") in new stack
[Sep 7 19:12:03] VERBOSE[17910] logger.c: [Sep 7 19:12:03] -- AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... ---------- completed, returning 0
[Sep 7 19:12:03] ERROR[17916] utils.c: write() returned error: Broken pipe
[Sep 7 19:12:03] ERROR[17916] utils.c: write() returned error: Broken pipe
[Sep 7 19:12:03] ERROR[17916] utils.c: write() returned error: Broken pipe
[Sep 7 19:12:03] VERBOSE[17916] logger.c: [Sep 7 19:12:03] == Manager 'sendcron' logged off from 127.0.0.1
[Sep 7 19:12:03] VERBOSE[17917] logger.c: [Sep 7 19:12:03] == Spawn extension (default, 918653542157, 2) exited non-zero on 'Local/918653542157@default-f804,2'
[Sep 7 19:12:03] VERBOSE[17917] logger.c: [Sep 7 19:12:03] -- Executing [h@default:1] DeadAGI("Local/918653542157@default-f804,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0-----CANCEL----------") in new stack
[Sep 7 19:12:03] VERBOSE[17917] logger.c: [Sep 7 19:12:03] -- AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... ---------- completed, returning 0
[Sep 7 19:12:03] VERBOSE[18869] logger.c: [Sep 7 19:12:03] == Manager 'sendcron' logged off from 127.0.0.1
[Sep 7 19:12:04] VERBOSE[18942] logger.c: [Sep 7 19:12:04] -- SIP/goautodial-000000e8 is making progress passing it to Local/919123542157@default-b93b,2
[Sep 7 19:12:04] VERBOSE[18945] logger.c: [Sep 7 19:12:04] -- SIP/goautodial-000000e9 is ringing
[Sep 7 19:12:06] VERBOSE[18990] logger.c: [Sep 7 19:12:06] == Parsing '/etc/asterisk/manager.conf': [Sep 7 19:12:06] VERBOSE[18990] logger.c: [Sep 7 19:12:06] Found
[Sep 7 19:12:06] VERBOSE[18990] logger.c: [Sep 7 19:12:06] == Manager 'sendcron' logged on from 127.0.0.1
[Sep 7 19:12:06] VERBOSE[18990] logger.c: [Sep 7 19:12:06] == Manager 'sendcron' logged off from 127.0.0.1
[Sep 7 19:12:26] VERBOSE[18945] logger.c: [Sep 7 19:12:26] -- SIP/goautodial-000000e9 answered Local/915618442157@default-cebd,2
[Sep 7 19:12:26] VERBOSE[18944] logger.c: [Sep 7 19:12:26] > Channel Local/915618442157@default-cebd,1 was answered.
[Sep 7 19:12:26] VERBOSE[18944] logger.c: [Sep 7 19:12:26] == Manager 'sendcron' logged off from 127.0.0.1
[Sep 7 19:12:26] VERBOSE[19273] logger.c: [Sep 7 19:12:26] -- Executing [8368@default:1] Playback("Local/915618442157@default-cebd,1", "sip-silence") in new stack
[Sep 7 19:12:26] VERBOSE[19273] logger.c: [Sep 7 19:12:26] -- Playing 'sip-silence' (language 'en')
[Sep 7 19:12:26] WARNING[19273] file.c: Unexpected control subclass '-1'
[Sep 7 19:12:26] VERBOSE[19273] logger.c: [Sep 7 19:12:26] -- Executing [8368@default:2] AGI("Local/915618442157@default-cebd,1", "agi://127.0.0.1:4577/call_log") in new stack
[Sep 7 19:12:26] VERBOSE[19273] logger.c: [Sep 7 19:12:26] -- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
[Sep 7 19:12:26] VERBOSE[19273] logger.c: [Sep 7 19:12:26] -- Executing [8368@default:3] AGI("Local/915618442157@default-cebd,1", "agi-VDAD_ALL_outbound.agi|NORMAL-----LB") in new stack
[Sep 7 19:12:26] VERBOSE[19273] logger.c: [Sep 7 19:12:26] -- Launched AGI Script /var/lib/asterisk/agi-bin/agi-VDAD_ALL_outbound.agi
[Sep 7 19:12:27] VERBOSE[18945] logger.c: [Sep 7 19:12:27] -- Executing [h@default:1] DeadAGI("Local/915618442157@default-cebd,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16-----ANSWER-----25-----1") in new stack
[Sep 7 19:12:27] VERBOSE[18945] logger.c: [Sep 7 19:12:27] -- AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... --25-----1 completed, returning 0
[Sep 7 19:12:27] VERBOSE[18945] logger.c: [Sep 7 19:12:27] == Spawn extension (default, 915618442157, 2) exited non-zero on 'Local/915618442157@default-cebd,2'
[Sep 7 19:12:27] VERBOSE[19273] logger.c: [Sep 7 19:12:27] -- AGI Script agi-VDAD_ALL_outbound.agi completed, returning 0
[Sep 7 19:12:27] VERBOSE[19273] logger.c: [Sep 7 19:12:27] -- Executing [8368@default:4] AGI("SIP/goautodial-000000e9", "agi-VDAD_ALL_outbound.agi|NORMAL-----LB") in new stack
[Sep 7 19:12:27] VERBOSE[19273] logger.c: [Sep 7 19:12:27] -- Launched AGI Script /var/lib/asterisk/agi-bin/agi-VDAD_ALL_outbound.agi
[Sep 7 19:12:28] ERROR[19273] utils.c: write() returned error: Broken pipe
[Sep 7 19:12:28] VERBOSE[19273] logger.c: [Sep 7 19:12:28] -- AGI Script agi-VDAD_ALL_outbound.agi completed, returning 0
[Sep 7 19:12:28] VERBOSE[19273] logger.c: [Sep 7 19:12:28] -- Executing [192*168*001*002*8600051@default:1] Goto("SIP/goautodial-000000e9", "default|8600051|1") in new stack
[Sep 7 19:12:28] VERBOSE[19273] logger.c: [Sep 7 19:12:28] -- Goto (default,8600051,1)
[Sep 7 19:12:28] VERBOSE[19273] logger.c: [Sep 7 19:12:28] -- Executing [8600051@default:1] MeetMe("SIP/goautodial-000000e9", "8600051|F") in new stack
[Sep 7 19:12:29] VERBOSE[19370] logger.c: [Sep 7 19:12:29] == Parsing '/etc/asterisk/manager.conf': [Sep 7 19:12:29] VERBOSE[19370] logger.c: [Sep 7 19:12:29] Found
[Sep 7 19:12:29] VERBOSE[19370] logger.c: [Sep 7 19:12:29] == Manager 'sendcron' logged on from 127.0.0.1
[Sep 7 19:12:29] VERBOSE[19371] logger.c: [Sep 7 19:12:29] -- Executing [58600051@default:1] MeetMe("Local/58600051@default-8eaa,2", "8600051|Fmq") in new stack
[Sep 7 19:12:29] VERBOSE[19370] logger.c: [Sep 7 19:12:29] > Channel Local/58600051@default-8eaa,1 was answered.
[Sep 7 19:12:29] VERBOSE[19372] logger.c: [Sep 7 19:12:29] -- Executing [8309@default:1] Answer("Local/58600051@default-8eaa,1", "") in new stack
[Sep 7 19:12:29] VERBOSE[19372] logger.c: [Sep 7 19:12:29] -- Executing [8309@default:2] Monitor("Local/58600051@default-8eaa,1", "wav|20110908-071227_5618442157") in new stack
[Sep 7 19:12:29] VERBOSE[19372] logger.c: [Sep 7 19:12:29] -- Executing [8309@default:3] Wait("Local/58600051@default-8eaa,1", "3600") in new stack
[Sep 7 19:12:31] VERBOSE[19370] logger.c: [Sep 7 19:12:31] == Manager 'sendcron' logged off from 127.0.0.1
[Sep 7 19:12:32] VERBOSE[19412] logger.c: [Sep 7 19:12:32] == Parsing '/etc/asterisk/manager.conf': [Sep 7 19:12:32] VERBOSE[19412] logger.c: [Sep 7 19:12:32] Found
[Sep 7 19:12:32] VERBOSE[19412] logger.c: [Sep 7 19:12:32] == Manager 'sendcron' logged on from 127.0.0.1
[Sep 7 19:12:32] WARNING[19273] app_meetme.c: Unable to write frame to channel SIP/goautodial-000000e9
[Sep 7 19:12:32] VERBOSE[19273] logger.c: [Sep 7 19:12:32] == Spawn extension (default, 8600051, 1) exited non-zero on 'SIP/goautodial-000000e9'
[Sep 7 19:12:32] VERBOSE[19273] logger.c: [Sep 7 19:12:32] -- Executing [h@default:1] DeadAGI("SIP/goautodial-000000e9", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0---------------") in new stack
[Sep 7 19:12:32] VERBOSE[19273] logger.c: [Sep 7 19:12:32] -- AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... ---------- completed, returning 0
[Sep 7 19:12:32] VERBOSE[19417] logger.c: [Sep 7 19:12:32] == Parsing '/etc/asterisk/manager.conf': [Sep 7 19:12:32] VERBOSE[19417] logger.c: [Sep 7 19:12:32] Found
[Sep 7 19:12:32] VERBOSE[19417] logger.c: [Sep 7 19:12:32] == Manager 'sendcron' logged on from 127.0.0.1
[Sep 7 19:12:32] VERBOSE[19371] logger.c: [Sep 7 19:12:32] == Spawn extension (default, 58600051, 1) exited non-zero on 'Local/58600051@default-8eaa,2'
[Sep 7 19:12:32] VERBOSE[19371] logger.c: [Sep 7 19:12:32] -- Executing [h@default:1] DeadAGI("Local/58600051@default-8eaa,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0---------------") in new stack
[Sep 7 19:12:32] VERBOSE[19371] logger.c: [Sep 7 19:12:32] -- AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... ---------- completed, returning 0
[Sep 7 19:12:32] VERBOSE[19372] logger.c: [Sep 7 19:12:32] == Spawn extension (default, 8309, 3) exited non-zero on 'Local/58600051@default-8eaa,1'
[Sep 7 19:12:32] VERBOSE[19372] logger.c: [Sep 7 19:12:32] -- Executing [h@default:1] DeadAGI("Local/58600051@default-8eaa,1", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0---------------") in new stack
[Sep 7 19:12:32] VERBOSE[19372] logger.c: [Sep 7 19:12:32] -- AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... ---------- completed, returning 0
[Sep 7 19:12:32] VERBOSE[19422] logger.c: [Sep 7 19:12:32] == Parsing '/etc/asterisk/manager.conf': [Sep 7 19:12:32] VERBOSE[19422] logger.c: [Sep 7 19:12:32] Found
[Sep 7 19:12:32] VERBOSE[19422] logger.c: [Sep 7 19:12:32] == Manager 'sendcron' logged on from 127.0.0.1
[Sep 7 19:12:32] VERBOSE[19423] logger.c: [Sep 7 19:12:32] == Parsing '/etc/asterisk/manager.conf': [Sep 7 19:12:32] VERBOSE[19423] logger.c: [Sep 7 19:12:32] Found

Now I have added 2gig and the warning no longer appeared BUT I experienced that there were no leads showing in the leads count under the list section of the admin panel.

[/img]

Use this command:

crontab -e

place this on the last line

This should clean your ram every 5 minutes
*/5 * * * * sync && echo 3 > /proc/sys/vm/drop_caches

If you are still reaching the max level, consider increasing your ram.

Regards,

macmaglaque wrote:Use this command:

crontab -e

place this on the last line

This should clean your ram every 5 minutes
*/5 * * * * sync && echo 3 > /proc/sys/vm/drop_caches

If you are still reaching the max level, consider increasing your ram.

Regards,

Or ... don't do this as it merely defeats the ram caching system that's built in to Linux.

I'd love to hear from someone who had a server "work better" after implementing this.

By "work better", I don't mean that the RAM Cache showed nothing cached, that's not a "work better" scenario, that is just a loss of caching which causes more CPU cycles to retrieve disk data that could otherwise have been pulled from memory/cache. I mean "server was crashing before but does not crash any more" sort of "work better".

Thanks for the clarification WIll. Guess the best solution is to upgrade the ram then probably do the clear cache every hour not every 5 minutes.

macmaglaque wrote:Thanks for the clarification WIll. Guess the best solution is to upgrade the ram then probably do the clear cache every hour not every 5 minutes.

... OR wait until there is actually something wrong with the server before trying to fix the server.

Do you change your oil every 500 miles, too? LOL

Wait! I got another one: Do you overhaul the engine when the ashtray is full? (that one may not work, cuz I'm old and remember full ashtrays ... LOL)