Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Replies 31 replies
  • Subscribers 0 subscribers
  • Views 8464 views
  • Users 0 members are here
Options
Suggested

[8.910][BUG] Webadmin excessively bloated

Billybob
I know that with all the new changes to webadmin some sacrifices will have to be made to the memory footprint but this is kind of excessive. I have a 2GB vmware instance running and after the update and starting snort, I am already swapping about 170Mb ram. What I have noticed is that there is a new process called asg.plx introduced in this version and whenever webadmin is launched, it takes up about 150megs of ram. I don't have anything new enabled for this version like hotspot etc. so the usage has increased for some other reason compared to previous versions. This added to the cssd daemon adds up to be almost 300megs increase in baseline compared to v8.3x

There are other threads about wwwrun cpu usage and I am sure it will be optimized but the memory footprint of webadmin is getting very large at this point. I hate to cry over memory usage all the time but something has to be optimized somewhere.  

gatekeeper:/var/log # ps aux |grep wwwrun

wwwrun    4327  0.0  0.0   8320  1732 ?        S    12:46   0:00 /bin/httpd -f /etc/httpd/httpd.conf

wwwrun    7920  0.9  2.8  74268 59548 ?        S    13:15   0:06 /var/webadmin/index.plx

wwwrun    7954  0.4  2.1  54768 44656 ?        S    13:15   0:03 /var/webadmin/asg.plx

wwwrun    7955  0.5  2.1  54768 44792 ?        S    13:15   0:03 /var/webadmin/asg.plx

wwwrun    7957  0.5  2.1  54768 43944 ?        S    13:15   0:03 /var/webadmin/asg.plx

wwwrun    8229  0.2  1.0  36256 22284 ?        S    13:17   0:01 /var/jape/index.plx

wwwrun    8286  0.0  0.1   9360  3600 ?        S    13:19   0:00 /bin/httpd -f /etc/httpd/httpd.conf

wwwrun    8324  1.2  2.3  60468 48092 ?        S    13:21   0:04 /var/webadmin/index.plx

wwwrun    8325  1.3  2.3  60688 48268 ?        S    13:21   0:04 /var/webadmin/index.plx

wwwrun    8326  0.9  2.1  55988 43808 ?        S    13:21   0:03 /var/webadmin/index.plx

wwwrun    8395  0.0  0.1   9368  3504 ?        S    13:22   0:00 /bin/httpd -f /etc/httpd/httpd.conf

root      8633  0.0  0.0   2168   472 pts/0    D+   13:26   0:00 grep wwwrun


Regards
Bill
  • 0
    I'm a little bit confused by the output of lsof, i would have expected to see the connection from your browser in there. Are you using IPv6? If so, could you please post the output of `[FONT="Courier New"]lsof -Pni 46tcp:4444[/FONT]`?

    Cheers,
    Kai
  • 0 in reply to kbr
    I am not using ipv6. Probably just mucked up the results previously somehow[:$]

    Here is the new output:
    Before: 
    gatekeeper:/var/log # lsof -Pni 4tcp:4444

    COMMAND   PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME

    httpd    4320   root    5u  IPv4  10161      0t0  TCP *:4444 (LISTEN)

    httpd    4327 wwwrun    5u  IPv4  10161      0t0  TCP *:4444 (LISTEN)

    httpd   23946 wwwrun    5u  IPv4  10161      0t0  TCP *:4444 (LISTEN)

    httpd   23947 wwwrun    5u  IPv4  10161      0t0  TCP *:4444 (LISTEN)

    gatekeeper:/var/log #


    After: 
    gatekeeper:/var/log # lsof -Pni 4tcp:4444

    COMMAND   PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME

    httpd    4320   root    5u  IPv4  10161      0t0  TCP *:4444 (LISTEN)

    httpd    4327 wwwrun    5u  IPv4  10161      0t0  TCP *:4444 (LISTEN)

    httpd   23946 wwwrun    5u  IPv4  10161      0t0  TCP *:4444 (LISTEN)

    httpd   23947 wwwrun    5u  IPv4  10161      0t0  TCP *:4444 (LISTEN)

    httpd   23947 wwwrun   17u  IPv4 733046      0t0  TCP 192.168.0.1:4444->192.168.0.10:57728 (ESTABLISHED)

    httpd   25071 wwwrun    5u  IPv4  10161      0t0  TCP *:4444 (LISTEN)

    httpd   25072 wwwrun    5u  IPv4  10161      0t0  TCP *:4444 (LISTEN)

    httpd   25072 wwwrun   17u  IPv4 732896      0t0  TCP 192.168.0.1:4444->192.168.0.10:57710 (ESTABLISHED)

    httpd   25077 wwwrun    5u  IPv4  10161      0t0  TCP *:4444 (LISTEN)

    httpd   25077 wwwrun   17u  IPv4 732913      0t0  TCP 192.168.0.1:4444->192.168.0.10:57712 (ESTABLISHED)

    httpd   25106 wwwrun    5u  IPv4  10161      0t0  TCP *:4444 (LISTEN)

    httpd   25106 wwwrun   17u  IPv4 733051      0t0  TCP 192.168.0.1:4444->192.168.0.10:57730 (ESTABLISHED)

    httpd   25110 wwwrun    5u  IPv4  10161      0t0  TCP *:4444 (LISTEN)


    Regards
    Bill
  • 0 in reply to Billybob
    I figured it out, I had customized webadmin to initially test the new features of dashboard. Depending on the extra options that you select, more asg.plx processes are spawned. I disabled all the fancy graphs and the memory usage goes back down.

    Regards
    Bill
  • 0
    Thanks for the hint regarding the customized dashboard. We were able to reproduce this, and i've already seen a patched webadmin on a developers workstation that doesn't show the behavior any more.
  • 0
    Thanks for reporting. We are now tracking this as Mantis ID #20788
  • 0
    The Mantis ID #20788 is now being worked on. We are planning to release a fix for this issue in Version 8.920.
  • 0
    Unbelievable! 4Gigs? 8Gis??  Wow man.. I'm running my v8.301's with 512Megs! Because it's just a freaking router.. and I do VPN and stuff on there... no web filtering or any of that which maybe is the hog. Gosh I sure hope I don't have to beef up my VM's to 4Gigs just to handle traffic!

    All of mine are 32bit because I'm used to 64bit OS's messing up somewhere due to someone not thinking about some 64bit issue.

    So maybe the 64bit instances are way too RAM hungry???
  • 0
    Unbelievable! 4Gigs? 8Gis??  Wow man.. I'm running my v8.301's with 512Megs! Because it's just a freaking router.. and I do VPN and stuff on there... no web filtering or any of that which maybe is the hog. Gosh I sure hope I don't have to beef up my VM's to 4Gigs just to handle traffic!

    All of mine are 32bit because I'm used to 64bit OS's messing up somewhere due to someone not thinking about some 64bit issue.

    So maybe the 64bit instances are way too RAM hungry???


    64 bit is now the norm and works extremely well. 64 bit also allows the real use of anything over 3.5 gigs of ram.  Ram is cheap.  The biggest ram users are http proxy and ids...but also the more traffic you use more ram...the more users the more ram.  Also in order to go from 32 bit to 64 bit is a total reinstall...best to use 64 bit fron the getgo...then there's no reinstall needed for later larger installations

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

    Former Sophos SG(Astaro) advocate/researcher/Silver Partner

    PfSense w/Suricata, ntopng, 

    Other addons to follow

Unfiltered HTML