Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 16 replies
  • Subscribers 3 subscribers
  • Views 3931 views
  • Users 0 members are here
Options
Suggested
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

mdw_daemon.pl

galpe
Hello,
i'm having the mdw_daemon.pl eating many many CPU and RAM. Yesterday i put another 256 mb ram on the machine because my swap space was too big and there was lot of swap I/O operations. I report a 'top' snapshot'. I Searched this group for similar problem and i found this but no solutions...


top - 09:51:31 up 14:31,  1 user,  load average: 1.58, 1.24, 0.74
Tasks: 103 total,   4 running,  98 sleeping,   0 stopped,   1 zombie
Cpu(s):  94.8% user,   5.2% system,   0.0% nice,   0.0% idle
Mem:    515532k total,   500100k used,    15432k free,    48932k buffers
Swap:  1052248k total,    60908k used,   991340k free,    39060k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  597 root      25   0  164m 164m 2976 R 88.2 32.6  38:02.82 mdw_daemon.pl
 1076 root      15   0 49348  44m  668 S  4.3  8.9   2:04.84 snort_inline
 1307 root      15   0   432  404  104 S  1.6  0.1   0:36.63 nacctd
  628 root      15   0  7440 7440 2324 S  1.3  1.4   7:00.32 selfmonng.pl
12165 root      15   0   960  960  720 R  1.3  0.2   0:00.24 top
 1198 root      15   0  2168 1628  740 R  1.0  0.3   0:33.61 hyperdyper
  390 root      15   0  2536 2404 2052 S  0.7  0.5   0:13.22 alicd
 2421 chroot    15   0   848  736  604 S  0.7  0.1   0:10.82 sockd
  214 root      15   0   892  880  520 S  0.3  0.2   0:29.03 syslog-ng
 1271 chroot    15   0 37212  34m  13m S  0.3  6.9   0:54.12 squidf
12069 loginuse  15   0  1928 1864 1704 R  0.3  0.4   0:00.09 sshd
    1 root      15   0   228  228  188 S  0.0  0.0   0:05.25 init
    2 root      15   0     0    0    0 S  0.0  0.0   0:00.00 keventd
    3 root      34  19     0    0    0 S  0.0  0.0   0:01.02 ksoftirqd_CPU0
    4 root      15   0     0    0    0 S  0.0  0.0   0:01.06 kswapd
    5 root      16   0     0    0    0 S  0.0  0.0   0:00.02 bdflush


This thread was automatically locked due to age.
Parents
  • 0
    What kind of CPU are you running?

    How many rules are you running?  If you bring up Current System Packet Filter Rules, how many rules do you have?

    mdw_daemon.pl seems to get triggered whenever you make a tweak to the packet filter rules, and also seems to get triggered periodically as well.
  • 0 in reply to drees
    Well, i have many rows from Current System Packet Filter Rules... Abount 27.000 rows... Cpu is a PIII 600 mhz (or similar...). 
    And if i restart Astaro, i must wait about 9 minutes between the login prompt and the 'ready beeps'.
    I must wait the some time if i change 1 or more packet filter rules also.
Reply
  • 0 in reply to drees
    Well, i have many rows from Current System Packet Filter Rules... Abount 27.000 rows... Cpu is a PIII 600 mhz (or similar...). 
    And if i restart Astaro, i must wait about 9 minutes between the login prompt and the 'ready beeps'.
    I must wait the some time if i change 1 or more packet filter rules also.
Children
  • 0 in reply to galpe
    I had the exact same problem earlier when I had rulesets which expanded into 20k+ iptables rules.  See my earlier thread here.

    The only solution I found was to figure out ways to reduce the size of the network and service groups in the rules which were getting expanded.  Once I got it down to about 1000 individual packet filter rules it was much happier.

    There seems to be an inefficient algorithm inside the mdw_daemon that needs to be addressed.
  • 0 in reply to drees
    Thank you for replay! But have you saved the semantic of your rules? Have you simply 'exploded' your definitions? (ex. 1 rule with 1 group of 2 services -> 2 rules with 1 service etc.)
  • 0 in reply to galpe
    I was able to reduce a large number of redundant values in service and network groups to reduce the packet filter expansion.  In addition, I also ended up relaxing certain rules to help.

    Depending on your ruleset and needs, you may or may not be able to do so.
  • 0 in reply to drees
    Ok, thank you! I'll review my ruleset but i think it is correct....
  • 0 in reply to galpe
    Hi,

    specially network groups tend to explode.
    Example, group A has 4 networks/hosts, group B has 4 networks/hosts. 
    Now you have one rule like group A to group B Service blabla, this gets expanded in the iptables to 16 entries. Best is, to avoid filters that are based on groups, it is much better if you use subnetting instead.

    Chris