This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

snort taking up all the memory

Hello,

In our office installation of Astaro (8.305), we have a problem with snort taking up all the swap space.  It builds up gradually from boot time over a period of weeks.

Restarting the IPS clears up the swap.

I don't see this in any of my other installations (server rack in datacenter, branch office and my home install) but a co-worker say his own home install is having similar issue.

Any idea what could cause this ?


This thread was automatically locked due to age.
Parents
  • Keep an eye on it and post again when it gets worse.

    Your memory usage looks very high to me already though; it's at about 2.6GB after subtracting 'buffers' and 'free'.

    You might want to also open a support case.

    Barry
Reply
  • Keep an eye on it and post again when it gets worse.

    Your memory usage looks very high to me already though; it's at about 2.6GB after subtracting 'buffers' and 'free'.

    You might want to also open a support case.

    Barry
Children
  • Are you leaving your webadmin session open indefinitely. index.plx (renamed to webadmin.plx in v9) seems to be taking up all your ram. It has been a known issue in v7~8. Kill it in top by pressing k then PID 23880 and hit enter.
  • Are you leaving your webadmin session open indefinitely. index.plx (renamed to webadmin.plx in v9) seems to be taking up all your ram. It has been a known issue in v7~8. Kill it in top by pressing k then PID 23880 and hit enter.


    No, I'm not but, at the time I took these measurements, it was indeed open.

    here is a new top snapshot with the web interface closed:

    top - 16:40:35 up 38 days, 20:39,  1 user,  load average: 0.20, 0.19, 0.21
    
    Tasks: 120 total,   1 running, 117 sleeping,   0 stopped,   2 zombie
    Cpu(s):  5.9%us,  4.0%sy,  0.0%ni, 89.1%id,  0.0%wa,  0.0%hi,  1.0%si,  0.0%st
    Mem:   3090452k total,  2130660k used,   959792k free,   167612k buffers
    Swap:  1052248k total,    99920k used,   952328k free,  1202752k cached

      PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
     4632 root      20   0  180m 140m 6924 S  0.0  4.7   0:36.24 cssd
    24638 snort     19  -1  158m 136m 1696 S  7.9  4.5  27:48.95 snort_inline
     7203 chroot    20   0  160m 113m 1580 S  0.0  3.8  50:00.96 clamd
     6407 postgres  20   0 82640  68m  67m S  0.0  2.3   2:57.18 postgres
     5851 postgres  20   0 82960  68m  67m S  1.0  2.3  91:33.75 postgres
     5118 postgres  20   0 80368  65m  65m S  0.0  2.2   8:33.25 postgres
    18409 postgres  20   0 82716  54m  52m S  0.0  1.8   0:07.44 postgres
    30067 wwwrun    20   0 55996  52m 8496 S  0.0  1.7   0:02.94 index.plx
     5174 root      20   0 64872  51m 1972 S  0.0  1.7  19:06.64 mdw.plx
    30978 postgres  20   0 82892  51m  50m S  0.0  1.7   0:09.28 postgres
     6118 root      20   0 51640  29m 3352 S  0.0  1.0  47:46.81 ctasd
    30014 postgres  20   0 82608  24m  22m S  0.0  0.8   0:00.34 postgres
     6398 root      20   0 42960  17m 1656 S  0.0  0.6   7:40.04 smtpd.bin
     4659 root      20   0 40044  16m 1248 S  0.0  0.5  23:49.41 confd.plx
    30098 root      20   0 39944  15m 1640 S  0.0  0.5   0:00.08 confd.plx
    26397 root      20   0 18904  10m 3512 S  0.0  0.4   0:01.49 websec-reporter
     6377 root      20   0 31120  10m 1976 S  0.0  0.4  90:25.61 smtpd.bin
     4999 root      20   0 39792  10m  548 S  0.0  0.3   3:40.90 confd.plx
    22455 root      20   0 18076  10m 3600 S  0.0  0.3   0:14.25 ips-reporter.pl
    22451 root      20   0 17632 9724 3472 S  0.0  0.3   0:13.35 pfilter-reporte
    22457 root      20   0 17448 9524 3404 S  0.0  0.3   0:02.11 waf-reporter.pl
    22454 root      20   0 16804 8872 3408 S  0.0  0.3   0:05.29 mailsec-reporte
     6806 root      20   0 10620 8676 2712 S  0.0  0.3   0:07.84 admin-reporter.
    22453 root      20   0 16484 8460 3256 S  0.0  0.3   0:02.60 vpn-reporter.pl
    30975 wwwrun    20   0 25760 7140 1296 S  0.0  0.2   0:01.70 index.plx
     6129 root      20   0 27784 6896 1488 S  0.0  0.2   9:51.85 ctipd.bin
     5207 root      20   0 11740 6408 1412 S  0.0  0.2 313:55.83 selfmonng.plx
    27627 wwwrun    20   0 25628 6256  248 S  0.0  0.2   0:01.67 index.plx
     5614 root      20   0 10256 6224 1024 S  0.0  0.2  19:33.91 named
     5081 root      20   0 13864 5184 1044 S  0.0  0.2   1:09.82 notifier.plx
     4819 root      20   0 15416 5020 1428 S  0.0  0.2   0:02.85 aua.bin
    18987 postgres  20   0 82696 5020 3916 S  0.0  0.2   0:00.02 postgres
     5607 root      20   0  8576 4596 1068 S  0.0  0.1  24:07.12 dns-resolver.pl



    Keep an eye on it and post again when it gets worse.

    Your memory usage looks very high to me already though; it's at about 2.6GB after subtracting 'buffers' and 'free'.

    You might want to also open a support case.


    I'll keep an eye on it. memory usage has always been high. I opened a case about 12 month ago about mail security simply dropping (legitimate) emails and connections and Astaro responded that I needed more RAM (we upgraded from 1 gigs to 3). Maybe I should reinstall or, at least, resize the swap partition to match the amount of memory.

    with ASL 9 being almost there, I wonder if it's worth the trouble: restarting the IPS every couple of weeks isn't exactly a big issue
  • I generally reinstall after hardware changes like ram etc. The kernel tunes itself better if it knows the hardware from the beginning. Probably doesn't make any difference but it seems to help atleast in my mind[:D] 
    I am not aware of any IPS memory leaks so I am not sure why you have to toggle snort every few weeks. As far as v9, they have improved the IPS throughput. Keep in mind that v9 has higher hardware requirements and depending on the number of users that you have, if you are having hardware problems (cpu, ram) with v8, I would probably wait till 9.1 to learn from other people's issues before I take the plunge.
    Once you get used to the white interface, I find v9 to be a little more responsive atleast in the webadmin department.

    Regards
    Bill