HTTP Proxy/DansGuardian performance is slow over time

Home Page Forums Network Management ZeroShell HTTP Proxy/DansGuardian performance is slow over time

This topic contains 4 replies, has 0 voices, and was last updated by  foobysmacker 8 years, 4 months ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #41689

    foobysmacker
    Member

    Hello,

    I’m having a problem where client web browsing and downloads become very slow and sometimes even crawl to a halt after the HTTP Proxy service and DansGuardian have been running for a few weeks.

    Rebooting the ZeroShell router doesn’t seem to resolve the issue, but I can apparently fix the problem temporarily by disabling the HTTP Proxy and then restarting it again. Of course, in a few weeks the same problem happens again.

    I’m running ZS 1.0b11b on a Alix device (AMD 500MHz / 256MB / 1GB CF). The ZS box is used as a wired router (no wireless) and services 5 clients that browse the web + 1 that is used frequently for bittorrent downloads.

    Anyone have the same problem or know how to fix this? I’d be more than happy with a workaround (like a scheduled restart of the proxy if that can be done)

    Thanks in advance

    #48133

    Vizzini
    Member

    I just wanted to bump this.
    @foobysmacker wrote:

    I’m running ZS 1.0b11b on a Alix device (AMD 500MHz / 256MB / 1GB CF). The ZS box is used as a wired router (no wireless) and services 5 clients that browse the web + 1 that is used frequently for bittorrent downloads.

    Hi, I am getting similar symptoms to you. Except that usually it starts slowing down in a week or less. I am running a WRAP (which is half the MHz and RAM of your ALIX).

    When it works, it works well. When it works poorly, it will either:
    a) take a long time to connect to the web (5 minutes or more at times), i.e. unusable. Sometimes if you come back to it a while later it will inexplicably work. When I reset the machine, it usually restores the performance.
    b) not work at all.

    Meanwhile, everything else keeps chugging away, bittorrent, ssh to the ZS box. I run top and nothing is over 6% for memory or CPU usage. I have 3-4 MB free RAM and 57MB free swap or so. That doesn’t seem to be much RAM left, considering I’m running the embedded version – there isn’t any swap, correct? If so, maybe memory is the problem – 3MB RAM is not much to play with.

    The fact that my system has half the memory of yours makes me suspect a memory leak, even if that is not the case.

    Other symptoms – when I attempt to go to a website through firefox, the “connecting to…” bit at the bottom left hand side of the browser very quickly changes to “waiting to reply from…” and stays there the whole time it is stalled there. So I wonder what is the problem.

    Any suggestions for diagnosing this thing would be really helpful.

    Edit: Another thing I forgot to mention, I am running an Atheros wifi card in the WRAP. The connection quality is good but not great. I note the following url has something that points to two possibilities – RAM (suggests that DG needs lots of RAM) and that the Server Network Connections have low error rates. Either of these could be a problem.

    http://contentfilter.futuragts.com/wiki/doku.php?id=performance_tuning

    #48134

    Vizzini
    Member

    Ok, I just had another little play with this, hammering the WRAP with opening different webpages (only about 5-10 different requests or so), and I note that in top the free swap memory is down to 52k (and has been around 500k or so for a bit), and the free memory is 2-3MB. 90% of processes are in I/O wait.

    My guess is that the WRAP is just too light in memory for the required task. I’m about to try it with a netbook instead of a WRAP, hopefully 1GB will be enough RAM.

    #48135

    Vizzini
    Member

    Ok, so I did a bit of googling for what to do with high IO-wait, and it said that it’s often a symptom of low memory. Also, check your dmesg output. Sure enough:
    http://pastebin.com/883seBqT


    Out of memory: kill process 4838 (havp) score 32659 or a child
    Killed process 4841 (havp)
    daemonwatcher invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0

    Looks like the low memory of the WRAP is an issue for running ZS+DG.

    #48136

    Vizzini
    Member

    Since I’ve moved to using an Eee PC with 10x the amount of RAM as the WRAP, I haven’t had the slowdown problem with dansguardian. No such errors in dmesg as I was getting before (but some different USB NIC related ones). I’ve been running the same setup without a reboot for about a week now. It’s working well and very snappy. Starting and restarting the filter is fast by comparison, and the web interface flies. For 10 more Watts and a built in UPS, monitor and keyboard, I think the Eee PC solution is definitely worth it.

    The only issue with using an Eee PC is the bandwidth you can get over a USB NIC. So far I’m not seeing the bandwidth I would expect (over sshfs at least, I haven’t tried other methods). However, since 1MB/s is all I can get over the internet, it’s not a real problem at this stage.

    #48137

    Vizzini
    Member

    One thing to consider is the EeePC’s lack of gigabit LAN. If I had to do it over again I’d probably get an EeeBox. Either the B202 or the newer one have GLAN, which I expect would work with Linux. Kind of strange that the EeePC with screen running all the time uses less power than the EeeBox, which I think is 13-15W.

    This is only an issue though if you use VLANs, which I do. Otherwise you have your ZS box between your only subnet and the internet, and if you are complaining about 100Mbit being slow on that, I envy you.

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.