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

[7.004] HTTP Proxy doesn't work anymore in Standard Mode

PabloDiablo
Hi,

Yesterday I updated my ASG-box to V7.004. No problems. But now all of the sudden HTTP Proxy (in standard mode port 8080) isn't responding anymore! I rebooted the box but it didn't help. So I set the Proxy-mode to "Transparant" then it works (a little bit slow, but it works). So I set it back to "Standard" and no requests are responded. Does anyone also got these problems? Or does have any idea what is going wrong?

Now I set it to Prxy mode "Standard" and changed the port to 8081. Now it works, very slow. So I changed the port back to 8080 and then it doesn't responds anymore....strange...


This thread was automatically locked due to age.
Parents Reply Children
  • 0 in reply to PabloDiablo
    If you review the Squid log (/etc/squid.log) from the CLI you will notice that there are configuration errors in it:

    createRemovalPolicy_heap: Unknown key type "lfuda". Using LRU

    This relates to these two directives:

    cache_replacement_policy heap lfuda
    memory_replacement_policy heap lfuda

    This error is probably occuring due to the binary not being compiled with the --enable-removal-policies=heap directive.

    Then:

    WARNING: Very large maximum_object_size_in_memory settings can have negative impact on performance

    maximum_object_size_in_memory 51395 KB

    Personally I think this setting is deranged ... who in their right mind wants to keep a 64Mb object in memory??! Especially when your ASG only has 512Mb.

    I'm not sure whether this has anything to do with the cache halting but Astaro should definitely revisit their cache tuning configuration.
  • 0 in reply to James Bourne
    If you review the Squid log (/etc/squid.log) from the CLI you will notice that there are configuration errors in it:

    createRemovalPolicy_heap: Unknown key type "lfuda". Using LRU

    Yep, I see this, too.


    WARNING: Very large maximum_object_size_in_memory settings can have negative impact on performance

    maximum_object_size_in_memory 51395 KB

    Personally I think this setting is deranged ... who in their right mind wants to keep a 64Mb object in memory??! Especially when your ASG only has 512Mb.

    I agree that even on big hardware values larger than a couple megabytes or so should not significantly improve performance. The default is 8KB!

    On my system w/512MB, the maximum_object_size_in_memory is 25762KB and the cache_mem size is 51526KB. I think a more reasonable size for squid would be to set cache_mem to 1/20th the total memory size and the max object size to 1/200th of the cache_mem size.

    In addition, the cache_swap_low/high settings could be tweaked as well.
  • 0 in reply to James Bourne
    Personally I think this setting is deranged ... who in their right mind wants to keep a 64Mb object in memory??! Especially when your ASG only has 512Mb.

    BTW, a quick google search reveals this set of benchmarks:

    http://lynx.fnal.gov/ntier-wiki/Squid_20performance_20for_20big_20objects

    They found that keeping the max object size in memory setting small tends to work much better regardless of  the cache_mem setting.
  • 0 in reply to drees
    I was advised by Astaro Tech Support of this today. It would _appear_ Astaro is aware of the problem.

    Anyone have the contents of /var/storage/chroot-squid/etc/squid.conf from 7.003 handy???? Would love to see what the old settings were.

    > James,
    >
    > Thank you we'll check into this.  The last major change to the 7.004 was
    > the increasing of the cache size to accommodate more objects in the proxy
    > cache.  The next update should include a change to move cached objects out
    > of memory and into the HD cache more efficiently to address performance
    > problems locking up the proxy.
    >
    > Best regards,
    >
    > Cameron Byers  |  Support Engineer
    > Astaro Corporation
    > supportus@astaro.com
    > https://my.astaro.com/support/cases.php  | Support Form
    > www.astaro.com/kb  |  Astaro Knowledgebase
  • 0 in reply to James Bourne
    I was advised by Astaro Tech Support of this today. It would _appear_ Astaro is aware of the problem.

    It looks like they may be, reducing the memory utilization of squid and letting the OS handle more of the caching duties should improve the performance of the system over a wider variety of system loads.
    Anyone have the contents of /var/storage/chroot-squid/etc/squid.conf from 7.003 handy???? Would love to see what the old settings were.

    Well, my 6.304 system has the same ratio of disk space, max object sizes and cache_mem settings allocated to it based on the size of the /var/storage system and amount of memory in the systems, so I doubt that those have changed unless they reduced one of those settings early in V7 for some reason.
  • 0 in reply to drees
    This is hot off the press from Cameron:

    James,

    We can certainly try setting these to a lower value, however it may be overwritten with the new 7.005, which really shouldn't be an issue as it should do this to help correct the storage issue.

    The settings to modify this cache are:
    joe /var/storage/chroot-squid/etc/squid.conf

    Under the Cache tuning section:

    maximum_object_size_in_memory 25711 KB
    maximum_object_size 108 MB

    Change these to a 5 MB max memory file and only a 20 MB object size:

    maximum_object_size_in_memory 5120 KB
    maximum_object_size 20 MB
  • 0 in reply to James Bourne
    Too bad they are reducing the maximum_object_size. [:(]

    That value should be proportioned related to the amount of disk space used for the cache, where the maximum_object_size_in_memory should be proportioned slightly according to the cache_mem setting.

    All IMO and IME, of course. [;)]
  • 0 in reply to drees
    Upgraded 2 firewalls here yesterday to 7.004.  Had no issues prior, but now the HTTP proxy stops serving requests every few hours on each of them.  No config changes were made other than the update.

    Disable and re-enable HTTP proxy will make it work for a while.. and then it stops again.  

    I do not think the problem is actually the HTTP proxy but rather the AUTO_INPUT packet filter table that the middleware manages.  For some reason, the firewalls just start dropping packets to its own http proxy after a while.

    We also have other strange things due to packets being dropped by the middleware managed INPUT filter, such as we sometimes cannot access the Webmin interface from external networks.

    We also are getting trouble tickets on PPTP VPN problems, their sessions seem to stop passing traffic after several minutes, not sure if its related.  Using L2TP seems to help with or resolve these.

    This is not good for us, and rolling back to 7.003 is going to be a real PITA, with management types upset.   Thank god its a three day weekend.. at least for everyone else [[[:(]]] [[[:(]]] [[[:(]]]
  • 0 in reply to AaronWolfe
    I never update production firewalls without waiting for at least a week and scanning the forums for issues, first.
  • 0 in reply to drees
    I never update production firewalls without waiting for at least a week and scanning the forums for issues, first.


    Is this because Astaro has a history of releasing junk updates?  It isn't my responsibility to bug test their product.  How about Astaro should never release an update without waiting for a week and running it on their own production firewalls.