Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 3 subscribers
  • Views 1001 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

ASG425 problems with 7.101

Stupots
Hi All,

Help!  I'm having performance problems with 7.101 on an ASG425 appliance and need help.  Basically, this unit has slowly been grinding to a standstill for internet (proxy) access and webmin in the last month.  Despite reboots and tweaking of options to see if there was a common factor, I'm no closer to finding what's causing the problem.

This morning, I rebuilt the 425 by reinstalling from a 7.100 SAI CD and then applying the up-to-date patch to bring it to 7.101.  I then restored a freshly entered config (pretty much identical to the previous one, but made on another 425 with a fresh 7.100 install).  I wanted to do this to prove that there is nothing "bad" being inherited from the old config, like user objects etc, other than the core config itself.

Since finishing the install and restarting at 8am, the CPU figure on the dashboard has not dropped below about 80% apart from sporadically.  Top is showing load averages in double figures, with ulogd, saa-proxy and confd.plx as the main culprits.

If I stop ulog by "/etc/rc.d/ulog stop" then the load averages drop a fair bit, but saa-proxy and confd.plx are still high and CPU figure has barely changed.

Rather than me post a huge amount of config, I'd be really grateful if one of you gurus can start asking me specific questions to help get to the bottom of this.

Regards,
Stuart


This thread was automatically locked due to age.
Parents
  • 0
    Are there a lot of entries in the packetfilter log?

    Barry
  • 0 in reply to BarryG
    Barry,

    Are there a lot of entries in the packetfilter log?


    Yes, there are.  According to the dashboard, we have 10,000 dropped packets today, and proportionately more during a full 24 hour period.

    Because we have an upstream firewall, we don't have any packet filter rules on the Astaro.  Most of them take the following form, where 10.y.yy.yyy is the Astaro's internal interface:

    [FONT="Courier New"][SIZE="2"]11:19:00  Default DROP  TCP  10.y.yy.yyy:8080 →  10.x.xx.***:1188  [RST]  len=40  ttl=64  tos=0x00[/SIZE][/FONT]

    Regards,
    Stuart
  • 0 in reply to Stupots
    I'm not sure if this is the same problem, but since you mentioned having to kill ulog...

    There have been some problems in 7.x where lots of logged traffic can slow down the system; I was under the impression that 7.100 was supposed to have fixed that however.
    You should probably talk to Astaro support about it.

    Regardless, the simple solution is to add some DROP rules that do not log, to catch any uninteresting traffic. I normally have rules to drop NetBios & uPnP broadcasts, misc worms, etc., so that the logs are not cluttered with irrelevant nonsense... it makes analysis much more straightforward, even when there are no performance issues.

    Barry
Reply
  • 0 in reply to Stupots
    I'm not sure if this is the same problem, but since you mentioned having to kill ulog...

    There have been some problems in 7.x where lots of logged traffic can slow down the system; I was under the impression that 7.100 was supposed to have fixed that however.
    You should probably talk to Astaro support about it.

    Regardless, the simple solution is to add some DROP rules that do not log, to catch any uninteresting traffic. I normally have rules to drop NetBios & uPnP broadcasts, misc worms, etc., so that the logs are not cluttered with irrelevant nonsense... it makes analysis much more straightforward, even when there are no performance issues.

    Barry
Children
  • 0 in reply to BarryG
    Barry,

    There have been some problems in 7.x where lots of logged traffic can slow down the system; I was under the impression that 7.100 was supposed to have fixed that however.


    Yes, I saw some other threads which indicated that was the case.

    You should probably talk to Astaro support about it.


    That's starting to look likely, I think.

    Regardless, the simple solution is to add some DROP rules that do not log, to catch any uninteresting traffic. I normally have rules to drop NetBios & uPnP broadcasts, misc worms, etc., so that the logs are not cluttered with irrelevant nonsense... it makes analysis much more straightforward, even when there are no performance issues.


    I can see why you'd silently drop those type of broadcasts, but how would you construct a rule to handle those type of packets that we're seeing, because they're not fully established TCP connections?

    Conversely I presume we need to allow traffic from the internal interface on 8080 (and I'm assuming that as you configure various services, the webproxy configures ipchains in the background, and that by implication there is a rule that already does this).

    Regards,
    Stuart
  • 0 in reply to Stupots
    You're right, there's no easy way to clean this up... I think the proxy config must be fixed by Astaro.

    Barry