Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 24 replies
  • Subscribers 1 subscriber
  • Views 6758 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

8.202 experiences

William Warren
There's good and some irritants still

So far 8.202 is finally usable.  Even with the local database things are still a bit slower though.  Cpu usage is up as well as ram usage.  Swap is still ocurring even with swapinnes at zero with 3 gigs installed...system never shows more than 60% usage on ram though.  I'm figuring the increased overhead for application control is to blame for the increased cpu ans ram usage.  Looks like minimum ram requires are at least 2 gigs.  One definite positive is I have an asl install on an atom and had kcipd issue.  I updated the bios and it reduced the issue but did not eliminate it.  8.202 along with the bios update resolved the issue.  8.202 needs some tweaking but honestly all new installs of v8 should be 3 gigs of ram and 64 bit.  Astaros days as a lightweight product are over.  8.202 is deployable...using the http proxy with cloud classisfication is still painful...its time to get this into the webadmin.


This thread was automatically locked due to age.
  • 0 in reply to Billybob
    I agree with all stated above.

    We have a large customer with 200Mbit pipe and clustered ASGs running on HP DL380 with 8 Gigs of RAM - but when we tried a pilot run of 8.2 it did not gave us expected "performance boost" and we downgraded back to 8.103 to avoid proxy issues.

    I am personally very sorry that Astaro made such drastical changes in the middle of 8.x branch because it looks more like new release with all consequences of such change and brings us to the point where we have to choose between updates/security and performance/stability.
  • 0
    Wow with that spec it still didn't work
  • 0
    Astaro made such drastical changes in the middle of 8.x branch because it looks more like new release with all consequences of such change
    In the Astaro way of assigning version numbers, x.x is considered to be a major version change.

    8.00 = major version change with new features added.
    8.01 = minor version change.  Bugfixes.
    8.100 = major version change with new features added.
    8.101 = minor version change.  Bugfixes.
    etc.

    If you'd like to keep abreast of new features to be added in upcoming versions, please see Astaro Gateway Feature Requests.
  • 0
    We have about 150 users on an ASG320 (2gb RAM). We have a 20mb Metro E circuit running for internet. Will we have problems running 8.202?
  • 0
    that depends on what features you are using now.  Also what are your hardware usage stats like in the executive reports?
  • 0
    j, if you're on 7.511, you probably won't see any real difference.  If you're using Mail Security, you need to be ready for an intervention...

    Cheers - Bob
  • 0
    I am on 8.103. Using IPS, Authenticated Proxy (using Whitelist) with single scan AV, Mail Security with antispam and dual AV scanning, and remote access VPN (light usage). Average stats over the last week: 14% CPU, 48% RAM, 19% Swap.
  • 0
    you might...if you are swapping nearly 20% already.  The new https proxy's web application controls are ram hungry as well as the ips.
  • 0
    Is there any way to upgrade the RAM in an ASG320? I looked to see if there was a hardware version number on the appliance and in the dashboard and couldn't find anything.
  • 0
    I don't think it's possible to increase the RAM - at least, not and keep your Astaro maintenance. [:)]

    The swap number never goes down until you reboot.  You might do that early next weekday morning so you can see what happens with the memory and swap when the unit is under load from your users.  During the night, if the database roll-up causes swapping, that's probably not having any impact on the time it takes to do it.

    Cheers - Bob