RE: [squid-users] Problem publishing on Facebook via Squid 3.1.2

-----Message d'origine-----
De : Eliezer Croitoru [mailto:eliezer_at_ngtech.co.il]
Envoyé : 27 novembre 2012 13:03
À : squid-users_at_squid-cache.org
Objet : Re: [squid-users] Problem publishing on Facebook via Squid 3.1.2

On 11/27/2012 6:39 PM, Delisle, Marc wrote:
> Hello,
> I am running 3.1.2 on a SUSE Linux Enterprise Server box (8 GB RAM) for 2700 clients, with 6500 HTTP requests per minute. This Squid instance is doing forward proxy and intercept too.
>
> The problem is when users are trying to use the publish feature on Facebook (we have a few corporate pages): the publish operation freezes (but only during office hours; it works fine early in the morning, for example).
>
> To troubleshoot, I installed the same OS and Squid version on a virtual machine. I asked these users to point to this proxy instance and all is fine (still during office hours).
>
> Maybe this Squid instance is overloaded? Is it a bad idea to be running Squid on box that is routing all outgoing traffic? Could it help to run a second instance of Squid on this box?
>
> Thanks,
> Marc Delisle

Hello Marc,

8GB is not the reason which you can get this problem from.
If you will be more specific about the environment and hardware peripherals we can maybe assume couple things.

For now the basic thing is that your server software is OLD and not up-to-date with the latest patches.
The current 3.1 version is 3.1.21 which will might solve this specific problem you are having.

This amount (about 130 per sec) of requests should not move a muscle for squid(from experience).
You can use this amount of connections on an INTEL atom D410 and D525 with 8GB ram and you should not have any problem with it.
The major culprits for slowdowns in such situation can be caused by:
- High HDD access(r\w) to SATA drives on software raid(any)
- Facebook or other servers on the way that identify your traffic as abusing and\or as DOS.
- Bug.
- many others.

My suggestion is to first try remove any disk access to make sure this is not the culprit.
Force the basic "none" for access logs and also make the proxy as mem only cache by disabling all the cache_dir.

It will give you a nice view on your server hardware performance else then the HDD.

As I mentioned before this is a very OLD version of SQUID and you better give a test fly to 3.2.3 stable version which improves squid in any way I can think of.

About routing + squid, Depends on the hardware.
Routing by itself wont be too much in this specific case by my experience.
even if you will hold some BGP or other server it should hold it for
2700 users pretty easily.

NAT is also a thing in this scenario which if exists for 2700 users you will be having a lot of problems with it.

If you can check for the server stats in these hours it would be good to see the wait memory and cpu usage.
If you have a SWAP being used it could point you to the source of the problem.

After all the above data will be gathered you will have a more solid ground towards the Solution.

Regards,
Eliezer

----
Hello Eliezer,
Thanks for your excellent analysis. First, there is no cache_dir involved. Second, I deactivated access_log and cache_log and the problem persists.
CPU does not seem to be the problem, it's mostly 80% idle with less than 0.5 % wait. Routing is RIP-only, but this box is IP-forwarding all traffic for the whole campus.
By the way, in Squid my cache_mem is set to 5000 MB.
Could you elaborate on the NAT issue? Most of our users are indeed in private networks and the Squid box is performing also NAT for them.
My next step is to compile Squid 3.2.3 and give it a try, even though I would have preferred to stay with the packages offered in this distro.