7.086 Memory Leak [NOTABUG]

Log into SSH (or use the console) and run "TOP" -- and set the sort order to memory... you should see what processes are "growing."

Hello.

You can see many details here (column MEM):
Support - Advanced - Process List 

regards Juergen

Ahh Juergen, that is easier... especially for those with little experience with Linux.  I still like TOP, though, because you can watch the memory usage increase / decrease in realtime.

Nothing looks to be unreasonable. Previous versions would boot with about 40% used and grow to about 45%. Now it boots with 37% used and is growing right now to 54% used. That means if I had 512 meg I would be s2wapping at this point. Here are the stats from top.

top - 10:11:06 up 2 days,  1:30,  3 users,  load average: 0.01, 0.02, 0.00
Tasks:  97 total,   2 running,  93 sleeping,   0 stopped,   2 zombie
Cpu(s):  3.0%us,  1.0%sy,  0.0%ni, 95.7%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Mem:   1036052k total,   982744k used,    53308k free,   194132k buffers
Swap:  1052248k total,       68k used,  1052180k free,   235072k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5194 root      15   0  111m  75m 2732 S  0.0  7.4   1:54.40 snort_inline
 3166 root      16   0 65192  61m 3016 S  0.0  6.1   2:11.91 mdw_daemon.plx
16718 root      25   0 86564  56m 6356 S  0.0  5.6   0:03.09 cffd
 4319 chroot    15   0  168m  34m 3400 S  0.0  3.5   1:17.48 httpproxy
18585 wwwrun    16   0 31896  26m 2956 S  2.3  2.6   0:04.88 index.plx
 3405 mysql     16   0  123m  23m 4816 S  0.0  2.4   5:37.20 mysqld
 2815 root      15   0 28600  15m 3800 S  0.0  1.5   0:21.26 confd.plx
18586 root      17   0 30260  15m 2260 S  0.3  1.5   0:01.72 confd.plx
17230 wwwrun    16   0 20780  14m 2712 S  0.0  1.5   0:00.69 qm.plx
17231 root      16   0 29556  14m 2060 S  0.0  1.4   0:00.13 confd.plx
 3574 root      15   0 15468  13m 1568 S  0.0  1.3   0:32.75 named
 2915 root      15   0 28456  12m 1460 S  0.0  1.3   0:03.12 confd.plx
 4366 root      16   0 17928  11m 3128 S  0.0  1.2   1:32.17 aua_edirsync.pl
 2816 root      15   0 13288  10m 2084 S  0.0  1.0   2:56.01 dns-resolver.pl
 2885 root      15   0 15432 9796 1776 S  0.0  0.9   0:01.22 aua.bin
 5743 root      34  19 13200 9032 1624 S  0.0  0.9   0:01.26 snmpd
 3191 root      15   0 13336 8436 2496 S  0.3  0.8   5:44.16 selfmonng.plx

You need to check it periodically after a reboot to see what is growing... I'd bet on the HTTP Proxy, or mysqld.

I second this problem.  A couple of weeks ago I watched my ASG220 with 512Mb running 7.007 work it's way up to 99%, mostly on the mysql process.  Only way to get it back was with a hard reboot.

Thinking it might be software, I upgraded to the latest (7.011) and it seemed OK.  Now it has been creeping back up, now at 55% with mysql taking 25% of that.  

I have a relatively simple install, no web browsing/proxy services, no email, no IDS, little logging.  It's basically a firewall with maybe a half dozen rules, no special features running.  What give?  

Regards
Brian

I second this problem.  A couple of weeks ago I watched my ASG220 with 512Mb running 7.007 work it's way up to 99%, mostly on the mysql process.  Only way to get it back was with a hard reboot.

Thinking it might be software, I upgraded to the latest (7.011) and it seemed OK.  Now it has been creeping back up, now at 55% with mysql taking 25% of that.  

I have a relatively simple install, no web browsing/proxy services, no email, no IDS, little logging.  It's basically a firewall with maybe a half dozen rules, no special features running.  What give?  

Regards
Brian

keep in mind Linux normally grabs all physical memory for caching to increase speed.  In Linux you should never touch swap if things are configured correctly, enough ram is installed in the machine for what's turned on, etc etc.  Astaro in early version of v7 had a badly misconfigured memory subsystem and that caused huge performance problems.  Astaro has now gone to the opposite extreme and is not allowing hte system to cache much if anything which will cause other performance problems in high-load environments....

Astaro has now gone to the opposite extreme and is not allowing hte system to cache much if anything which will cause other performance problems in high-load environments....

I'm not sure why you say that, warper's system above is using nearly all of his 1GB of RAM as expected without swapping. About 1/2 of his 1GB is being used for filesystem cache.

Same scenario here
Ver: 7.086
1GB of RAM

Less then 24hrs (exactly 20hrs of uptime) and now using %45 of RAM.

Like drees already said, the system is always using free RAM as IO cache. Really "free" RAM is wasted RAM. What is also true is that there is a (smaller) memory leak problem in MySQL - we're working on that.