Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 26 replies
  • Subscribers 2 subscribers
  • Views 10606 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

High usage or bad performance

ciscoman
Hi,
not sure if this is normal for an ASG 320HA. V8.103
It looks like that the performance is very high. The CPU usage is between 20-50 % permanently.
Does a proxy with activated single scan engine does take so much resources?
2 500 000/requests per day / logging enabled
some mail traffic (below 5000 mails/day)
This box is designed (data sheet) to manage 600 000 concurrent sessions and 165 Mbit/s UTM throughput.

Cheers,


top - 08:17:37 up 62 days, 8 min,  2 users,  load average: 0.53, 0.59, 0.50
Tasks: 150 total,   1 running, 147 sleeping,   0 stopped,   2 zombie
Cpu(s): 18.0%us,  4.0%sy,  0.0%ni, 78.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   2068092k total,  1935700k used,   132392k free,   338316k buffers
Swap:  1052248k total,   159920k used,   892328k free,   903736k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 9963 postgres  20   0 49848  36m  35m S  5.6  1.8   2854:41 postgres
 9436 postgres  20   0 49700  37m  36m S  5.3  1.8   2715:34 postgres
 5154 root      19  -1  6356 3652  872 S  1.0  0.2   1632:38 ulogd
 5548 root      15  -5  9560 5964  404 S  0.7  0.3   1934:07 conntrackd
 6012 root      20   0  7404 3276 1232 S  0.7  0.2   1878:26 syslog-ng
26668 root      20   0 33100  14m 4088 S  0.7  0.7   0:14.84 smtpd.bin



top - 08:19:53 up 62 days, 10 min,  2 users,  load average: 0.82, 0.66, 0.54
Tasks: 153 total,   5 running, 146 sleeping,   0 stopped,   2 zombie
Cpu(s): 43.0%us, 16.4%sy,  0.0%ni, 29.2%id,  0.3%wa,  1.3%hi,  9.8%si,  0.0%st
Mem:   2068092k total,  1949860k used,   118232k free,   339220k buffers
Swap:  1052248k total,   159920k used,   892328k free,   915424k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 6086 httpprox  20   0  387m 156m 3676 R 11.9  7.8   3369:39 httpproxy
20469 root      20   0 17288 9456 3512 S 10.9  0.5  13:53.43 websec-reporter
 6012 root      20   0  7404 3276 1232 S  7.3  0.2   1878:31 syslog-ng
 5548 root      15  -5  9560 5964  404 S  6.3  0.3   1934:11 conntrackd
 9963 postgres  20   0 49848  36m  35m R  5.0  1.8   2854:47 postgres
 5154 root      19  -1  6356 3652  872 S  4.6  0.2   1632:41 ulogd
31841 root      20   0  2324 1104  808 R  3.3  0.1   0:00.10 csync2
26668 root      20   0 33100  14m 4088 S  2.7  0.7   0:17.51 smtpd.bin
 9436 postgres  20   0 49700  37m  36m S  1.7  1.8   2715:39 postgres


This thread was automatically locked due to age.
  • 0
    is this a web server that the astaro is protecting?
  • 0 in reply to William Warren
    is this a web server that the astaro is protecting?


    Not really,

    the main feature of the ASG is to forward and receive mails und to act as a 
    web proxy. 
    Security is beeing made on other devices. Guess what :-)


    Cheers,
    ciscoman
  • 0
    and are you truly doing a contstant 5-10 megabits/sec?  Right now judging by what i have seen the cpu load on your ASg is expected for what you are pushing through the unit.
  • 0
    You can minimize downtime by:

    Before the maintenance window:

    1. Disable High Availability (this will cause the Slave to do a Factory Reset).
    2. Disconnect the Ethernet cables from the Slave' 
    3. Install the 64-bit version from ISO onto the former Slave.
    4. Put an unencrypted backup on a USB memory stick, and then reboot the Slave with that in place.



    Maintenance Window:

    5. Power down the 32-bit Master.
    6. Connect the new 64-bit ASG to the network.
    7. In order to have the new MAC addresses recognized, you almost-certainly will need to "bounce" the routers/switches connected directly to the ASG.  Depending on your environment, this may include the last-hop router of your ISP.
    8. Once you've confirmed that the 64-bit system is working correctly, disconnect the 32-bit system.



    Before proceeding with the final step, you may want to connect to the 32-bit system (with a separate switch or a crossover cable), run reports, copy off logs, etc.  You also might want to give the new 64-bit system at least a day in production before:

    9. Enable High Availability on the new 64-bit master.  Image the 32-bit ASG with the 64-bit system and then connect it back as it was before.  The Master will take it over and make it its Slave.



    Does anyone see anything I've left out?

    Cheers - Bob
    PS If you only have Web Security and Mail Security, you really should be able to do with NAT rules.  At least, you could run in bridged mode, and, if you're running Web Security in a Standard mode, you really only need to have a single interface connected to your internal network (plus, of course, the Sync interface for HA).
  • 0 in reply to William Warren
    and are you truly doing a contstant 5-10 megabits/sec?  Right now judging by what i have seen the cpu load on your ASg is expected for what you are pushing through the unit.



    Yes, pls see attachement:

    So, in other words, it works as designed and I need to upgrade the hardware?
    Sure, it is possible to do that. However, I'm still convinced that the DataSheet is not realistic.

    Thanks,
    Cheers,
  • 0 in reply to BAlfson
    You can minimize downtime by:

    Before the maintenance window:

    1. Disable High Availability (this will cause the Slave to do a Factory Reset).
    2. Disconnect the Ethernet cables from the Slave' 
    3. Install the 64-bit version from ISO onto the former Slave.
    4. Put an unencrypted backup on a USB memory stick, and then reboot the Slave with that in place.



    Maintenance Window:

    5. Power down the 32-bit Master.
    6. Connect the new 64-bit ASG to the network.
    7. In order to have the new MAC addresses recognized, you almost-certainly will need to "bounce" the routers/switches connected directly to the ASG.  Depending on your environment, this may include the last-hop router of your ISP.
    8. Once you've confirmed that the 64-bit system is working correctly, disconnect the 32-bit system.



    Before proceeding with the final step, you may want to connect to the 32-bit system (with a separate switch or a crossover cable), run reports, copy off logs, etc.  You also might want to give the new 64-bit system at least a day in production before:

    9. Enable High Availability on the new 64-bit master.  Image the 32-bit ASG with the 64-bit system and then connect it back as it was before.  The Master will take it over and make it its Slave.



    Does anyone see anything I've left out?

    Cheers - Bob
    PS If you only have Web Security and Mail Security, you really should be able to do with NAT rules.  At least, you could run in bridged mode, and, if you're running Web Security in a Standard mode, you really only need to have a single interface connected to your internal network (plus, of course, the Sync interface for HA).



    Thanks Bob for the upgrade strategy. I will keep this in mind.
    However, HA has been setup to have no downtime. If I need to update or reinstall, I need to find a solution with no downtime. Perhaps a trial/demo appliance or something like that.

    Cheers
  • 0 in reply to ciscoman
    Hm,
    it is really running on 32 Bit mode. Not sure if the hardware supports 64Bit. Shouldn't there a flag 64 or LM (long mode)?
    And yes, the hardware is running since 7.2x.

    And the most important question would be. Is there a real difference between 32 and 64 bit (assuming the same platform)?
    Cheers,

     ASG:/var/log # hwinfo --cpu
      Hardware Class: cpu
      Arch: Intel
      Vendor: "GenuineIntel"
      Model: 15.2.9 "Intel(R) Pentium(R) 4 CPU 2.80GHz"
      Features: fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,pebs,bts,cid,xtpr
      Clock: 2790 MHz
      BogoMips: 5581.54
      Cache: 512 kb
      Units/Processor: 1
      Config Status: cfg=new, avail=yes, need=no, active=unknown

     ASG:/var/log # uname -a
    Linux ASG 2.6.32.42-15.g07a53b3-default #1 Thu Sep 8 16:06:16 UTC 2011 i686 i686 i386 GNU/Linux

     ASG:/var/log # hwinfo --memory
      Memory Size: 2 GB
  • 0
    a solution with no downtime

    I haven't seen your configuration, but I don't think this is possible if you want to move to 64-bit.  The only downtime required by the above is that necessary to reboot directly-attached switches or otherwise clear their ARP tables.  Even with a loaner, I don't see how you can avoid that.

    When I did a similar outage for one customer, we planned for 15 minutes, and accomplished it in five.  I think we could have had it down to a minute if we'd done a better job of coordinating with their ISP.  If you have your own router between your ISP and the Astaro, then you probably can get closer to a minute.

    Cheers - Bob
  • 0 in reply to BAlfson
    .  I think we could have had it down to a minute if we'd done a better job of coordinating with their ISP.  If you have your own router between your ISP and the Astaro, then you probably can get closer to a minute.

    Cheers - Bob


    just to complete. We could get manage to do the job in less than a minute. However, from customer point of view, it is still a downtime.

    Well, thanks for your tip.

    BestRegards
    ciscoman
  • 0
    your cpu is not a 64 bit cpu.  You are going to need to upgrade your hardware.