Ironport System Performance

[MikeK_ironport]

Hello,
Just wondering if anyone is noticing that after each upgrade they do of AsyncOS, the performance of the system goes down and down.

We have been running our C60s for 1 1/2 years, starting with the 3.8 build of AsyncOS.

After this last build (4.5.5) we are averaging over 70 percent on our CPU's.

We process about 30,000 inbound connections per hour, which is well below the 140,000 advertised that the box can handle.

We are not running anything strange... no content scans, no dictionary matches. Just your basic file attachment blocking, AV and Antispam.

Thanks!

[chhaag]

As discussed, CPU is not a good indicator of an IronPort's performance.

The best indicator of performance is frequency of workqueue backups. An occasional backup is perfectly normal and an ESAs ability to "bend", (though not break) during mail spikes is one of the best features of our appliance. However, frequent backups (several times per week) or a pattern of backups that is increasing may indicate a system that is getting over burdened.

We have several articles that address performance issues which might be of interest to this thread.
Why does the workqueue back up?
http://tinyurl.com/jtz5k
What can I do to prevent my workqueue from backing up?
http://tinyurl.com/ne8mo

cheers,

Chris Haag

[kronoply_gmbh]

No -

I only changed the reportinglevel. Ironport tells me the following facts about this issue (please read from downwards to up)


---------------------------------------------------------------------------

Hi Jens-Uwe,

Some more data for this case. I'm not sure if PostX will be on box for a
C100 or not. The action to encrypt will be as fare as I know, but the
whole PostX web front-end functions will not be on box. The main problem
C10/C100 are facing is the small amount of RAM. It's only 1GB and the
raid is a soft raid, which is way swapping becomes really expensive in
terms of CPU usage.

Reporting in 5.0 and 5.1 has become more resource hungry and needs a lot
of RAM if used in full mode. Moreover the GUI has a very low priority
(for the CPU scheduler), which is painful for administration.

We don't sell extra RAM for any IronPorts.

Regards,


--

Mark Strasheim

IronPort Systems
Toll-Free Customer Support
U.S.: 1-877-641-IRON (4766)
Int’l : www.ironport.com/support/contact_support.html
Survey http://www.surveymonkey.com/s.asp?u=774823512862

Support Portal: www.ironport.com/support
www.ironport.com - The Leader in Email Security


Do 12. Apr 2007, 00:43:54 Mr. Neumann - Korrespondenz hinzugefügt [Antworten]
Subject:
Re: [IronPort.com #145115] Slow GUI Performance after 5.0 Upgrade
Date:
Thu, 12 Apr 2007 07:43:45 +0000
To:
customersupport@ironport.com
From:
"neumann@kronotex.de"

Download(unbenannt)
text/plain 3.5k
Hello,

If you say "30% disk swap space being used, which is high" you means that is not enough ram at the C10 ? Should and could I place some additionally RAM in the C10 ?

Yes at the moment I do a dual scanning with brightmail und ironport anti spam. But this is not the cause, for the heavy load, because I was able to enable this with the update to 5.1 2-3 weeks ago. The performance leak was already there, before I enabled the dual scanning and the situation was not gone awry after this action. But please disabled it, If you would test it.


Remember, you are you looking at our time 11.30pm. At this time there is nobody in the office. Therefore there is no mailflow (or much fewer).
Also we are already minimized the logging (limited monitoring functions)


I mean, to see really what is happened, you have to log in at 10.00am our time and we have to maximize the logging.




Best regards


Neumann

-----------------------------------------------------------------------------------


I think that is clear, waht was happend after the update :(

[bfayne_ironport]

Have you checked what your average message size is? Most sites have seen serious growth in message size as well as image spam so CPUs everywhere are working a lot harder.

You always need a beeger bawx. :D

[seveneyes_ironport]

You may want to check out the "What are common configuration errors?" in the knowledge base for some suggestions.

We set our blacklist to start at -2.0 and only received a few complaints, mostly from mail servers that did have blacklist problems.

The connection timeout setting were modified to:

Timeout for Unsuccessful Inbound Connections = 2m
Total Time Limit for All Inbound Connections = 15m (this would depend on the largest message size you will expect from the slowest mailserver you might expect - dsl line) 15m seems to be working ok for 10mb.

in conversation ldap rcpt checking should absolutely be used.

Ignore the recommendations for strict address parsing and reject literals suggested. We found this did reject legit email.