| 1 |
On Thursday 05 Sep 2013 14:17:14 Grant wrote: |
| 2 |
> > +1 on Alan's hunch. I have not used Squid to comment on the specifics |
| 3 |
> > and also Grant stated that another proxy gave him similar symptoms. |
| 4 |
> > From my limited knowledge a proxy could be stalling because of cache |
| 5 |
> > configuration problems, like running out fs space, or inodes and also |
| 6 |
> > running out of memory if it has to process simultaneous requests from |
| 7 |
> > too many clients at a time. If the problem also manifests when the |
| 8 |
> > clients are within the same subnet, then this is unlikely to be a |
| 9 |
> > network issue. |
| 10 |
> |
| 11 |
> Which hunch was that? I snipped a lot above but I couldn't find it in |
| 12 |
> there. |
| 13 |
|
| 14 |
It was Alan's statement that this problem is not related to your AT&T router. |
| 15 |
|
| 16 |
|
| 17 |
|
| 18 |
> It's just one user (me) and I've fiddled with the cache (including |
| 19 |
> disabling it) and at least fs space and memory are good. |
| 20 |
|
| 21 |
OK, this points away from your proxy configuration then. I noticed you |
| 22 |
mentioning that the problem is manifested with a different proxy application, |
| 23 |
points to a network problem, unless the cache fs set up is exactly the same. |
| 24 |
As long as you have enough disk space and enough inodes, plus enough RAM, then |
| 25 |
all points to a network problem. |
| 26 |
|
| 27 |
|
| 28 |
> > If all other causes are eliminated then a network related problem could |
| 29 |
> > be associated with TCP Window Scaling - but this would primarily show up |
| 30 |
> > on the transmission of larger files. This is why I initially asked if |
| 31 |
> > the problem shows up on video/audio downloads rather than small web |
| 32 |
> > pages. |
| 33 |
|
| 34 |
I have to come back to this. I tried the www.google.com/nexus/ you mentioned |
| 35 |
and noticed that the page eats up 1.3MB to load fully, before it starts |
| 36 |
downloading a flash video. So seems to be a relatively large amount of data |
| 37 |
that brings up this problem and this could point to tcp window scaling. |
| 38 |
|
| 39 |
|
| 40 |
> I've tried all of these with no noticeable change: |
| 41 |
> |
| 42 |
> echo 0 > /proc/sys/net/ipv4/tcp_ecn |
| 43 |
> echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc |
| 44 |
|
| 45 |
This should be *disabled* (double negative). PMTU discovery is necessary if |
| 46 |
any nodes are using smaller than the default 1500 byte ethernet MTU value. So |
| 47 |
you better set it as: |
| 48 |
|
| 49 |
echo 0 > /proc/sys/net/ipv4/ip_no_pmtu_disc |
| 50 |
|
| 51 |
|
| 52 |
> echo 0 > /proc/sys/net/ipv4/tcp_window_scaling |
| 53 |
|
| 54 |
This is typically enabled, but if you notice that a connection stalls and then |
| 55 |
later on it works fine again, it could be related to a firewall/router not |
| 56 |
responding as it should to tcp_window_scaling. In this case disabling this |
| 57 |
would fix the problem when traversing problematic nodes. |
| 58 |
|
| 59 |
If you saw no difference, this suggests that window scaling is not an issue. |
| 60 |
|
| 61 |
|
| 62 |
> Not that anyone here should bother to read it, but here's a link to my |
| 63 |
> thread on the squid list where I tried all kinds of stuff: |
| 64 |
> |
| 65 |
> http://squid-web-proxy-cache.1019090.n4.nabble.com/squid-3-3-5-hangs-the-en |
| 66 |
> tire-system-td4660893.html |
| 67 |
|
| 68 |
I read it and if the squid experts say it is a network problem, then it could |
| 69 |
well be - although the network problems can be more difficult to diagnose and |
| 70 |
resolve. |
| 71 |
|
| 72 |
|
| 73 |
> I think at this point I'm hoping that putting the server's |
| 74 |
> modem/router into bridged mode so it will respond to pings will clear |
| 75 |
> this up. |
| 76 |
|
| 77 |
Well, we don't *know* that the router is the cause of the problem - yet. |
| 78 |
Setting it up in fully bridged mode and exposing your desktop directly to the |
| 79 |
Internet will definitely eliminate the router, because it will only be dealing |
| 80 |
with ATM packet encapsulation. |
| 81 |
|
| 82 |
|
| 83 |
> I think that's conceivable if the modem/router is also |
| 84 |
> failing to return Fragmentation Needed since its MTU is 1492. Testing |
| 85 |
> the proxy from within the server's LAN as you suggested in my other |
| 86 |
> thread could also be informative. Please let me know if there's |
| 87 |
> anything else I should try. |
| 88 |
|
| 89 |
I would start with the simplest tests first, which involve isolating suspect |
| 90 |
system components one at a time. Trying to use the same laptop-desktop |
| 91 |
machines within the LAN, takes the router out the equation - full 1500 byte |
| 92 |
MTU will be used by both laptop and desktop. |
| 93 |
|
| 94 |
If that works as intended then setting the router into fully bridged mode will |
| 95 |
eliminate that node and any problems that it may have with tcp window |
| 96 |
extensions. |
| 97 |
|
| 98 |
Troubleshooting public nodes becomes more difficult, unless you happen to |
| 99 |
travel around and use networks that bypass the suspect nodes. For all we know |
| 100 |
it could be the particular hotel firewall/router that is causing the problem. |
| 101 |
;-) |
| 102 |
|
| 103 |
-- |
| 104 |
Regards, |
| 105 |
Mick |
Archives