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

https://community.sophos.com/products/unified-threat-management/astaroorg/f/53/t/32078

Let's just link ourselves up, shall we.

Good to know its not just me.

Hallo,

the same at my machine. Updated to 7.004. The proxy-port was the 8080. Then I have changed the port 3128. Now I can see notifications, that the proxy-server is not running and will be restarted. I can't connect to the web.

Whats wrong with 7.004 ?

Best regards from
Egbert

Hi guys, 

its working as expected in my case.

Are you using anything special?

regards
gert

I am seeing the same problem. Random stops and out for a short to a long period of time - like I say it is random and there does not seem to be a pattern developing...

I am seeing this in transparent mode... I have not tested with standard mode...

--Ray

P4 1.3
1.5 GIG Ram
80 GIG Drive
Intel Pro100s Nics

Nope, nothing special. Same hardware as I used for V6.x, beta's V7.x and final releases of V7.x .

I'm running the HTTP proxy in standard mode, and it has stopped working on three occasions since I installed 7.004 two days ago. The first two times the proxy was re-started automatically, but on the last occasion I ended up rebooting the firewall to get it to work once more.

As other posters have mentioned, there seems to be no obvious reason why this happens.

No - nothing special. We had the proxy stop for a fourth time in four days ... so I decided to just change the port number from 8080 -> 3128. No everything seems to be OK. Been up for two days without a hitch.

The http proxy on my ASG usually stops at least twice a day and the socks proxy at least once a day.

Ian M

what is the cli-command to restart the proxy? /etc/init.d/squid restart?

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.

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.

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.

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.

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

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.

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

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. [;)]

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 [[[:(]]] [[[:(]]] [[[:(]]]

I never update production firewalls without waiting for at least a week and scanning the forums for issues, first.

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.

Is this because Astaro has a history of releasing junk updates?

Yes. I can't remember the last time an update was rolled out without significant issues. It seems that nearly every update to the v6.3xx series has been "re-rolled" to fix some error. Do a search, you'll find more information about them.

The whole v7 series has been a bit of a cluster-. It seems that most people are avoiding v7 unless they really need some new feature in v7. It definitely seems to be very unstable compared to the v4 -> v5 -> v6 migration.

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.

I agree, but I think you will find that with any product with this amount of complexity in it will always have some sort of bug. Just look at all the major software manufacturers. That said, it still seems to me that Astaro has some basic QA issues which fail to find basic functionality issues in new releases and new releases have a nasty habit of introducing regressions.

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

Want to know some really good settings for squid?  I have been using these for a looong time.  IF you have the disk space then this will drastiically chop ram usage and increase your cache usage(only for static content obviously)


 maximum_object_size_in_memory 0 KB
maximum_object_size 250 MB
cache_mem size is 0KB

This will remove about 50-70% of squid's memory usage, increase your disk cache and remove squid as one of your ram hogging apps.

If you are a bit short on disk space like i am max the max object size 125 megs or a bit smaller.  That way one or two large files won't wipe out your other cached files.

An Astaro 7.004 webproxy at a customers network fails about 5 times a day and we can only switch it off and on! 
Has somebody found a workaround or is there any information if Astaro is going to fix this?