Memcache connection errors

[Kamran Nisar]

got zero tx/rx errors...


even the ping returned 0% packet loss, though there was sum random sharp
jumps in repsonse time


64 bytes from 10.0.0.51: icmp_seq=7780 ttl=64 time=0.097 ms
64 bytes from 10.0.0.51: icmp_seq=7781 ttl=64 time=0.096 ms
64 bytes from 10.0.0.51: icmp_seq=7782 ttl=64 time=0.096 ms
64 bytes from 10.0.0.51: icmp_seq=7783 ttl=64 time=0.095 ms
64 bytes from 10.0.0.51: icmp_seq=7784 ttl=64 time=0.095 ms
64 bytes from 10.0.0.51: icmp_seq=7785 ttl=64 time=3.49 ms
64 bytes from 10.0.0.51: icmp_seq=7786 ttl=64 time=6.94 ms
64 bytes from 10.0.0.51: icmp_seq=7787 ttl=64 time=7.69 ms
64 bytes from 10.0.0.51: icmp_seq=7788 ttl=64 time=2.69 ms
64 bytes from 10.0.0.51: icmp_seq=7789 ttl=64 time=7.75 ms
64 bytes from 10.0.0.51: icmp_seq=7790 ttl=64 time=7.28 ms
64 bytes from 10.0.0.51: icmp_seq=7791 ttl=64 time=1.95 ms
64 bytes from 10.0.0.51: icmp_seq=7792 ttl=64 time=0.102 ms
64 bytes from 10.0.0.51: icmp_seq=7793 ttl=64 time=3.81 ms
64 bytes from 10.0.0.51: icmp_seq=7794 ttl=64 time=0.097 ms
64 bytes from 10.0.0.51: icmp_seq=7795 ttl=64 time=3.44 ms
64 bytes from 10.0.0.51: icmp_seq=7796 ttl=64 time=0.109 ms
64 bytes from 10.0.0.51: icmp_seq=7797 ttl=64 time=0.096 ms

64 bytes from 10.0.0.51: icmp_seq=9827 ttl=64 time=0.099 ms
64 bytes from 10.0.0.51: icmp_seq=9828 ttl=64 time=5.07 ms
64 bytes from 10.0.0.51: icmp_seq=9829 ttl=64 time=0.098 ms
64 bytes from 10.0.0.51: icmp_seq=9830 ttl=64 time=1.15 ms
64 bytes from 10.0.0.51: icmp_seq=9831 ttl=64 time=0.267 ms
64 bytes from 10.0.0.51: icmp_seq=9832 ttl=64 time=0.095 ms

64 bytes from 10.0.0.51: icmp_seq=9858 ttl=64 time=0.240 ms
64 bytes from 10.0.0.51: icmp_seq=9859 ttl=64 time=1.74 ms
64 bytes from 10.0.0.51: icmp_seq=9860 ttl=64 time=2.11 ms
64 bytes from 10.0.0.51: icmp_seq=9861 ttl=64 time=0.927 ms

64 bytes from 10.0.0.51: icmp_seq=9997 ttl=64 time=0.096 ms
64 bytes from 10.0.0.51: icmp_seq=9998 ttl=64 time=0.108 ms
64 bytes from 10.0.0.51: icmp_seq=9999 ttl=64 time=1.74 ms

On 5/24/06, Jacques Caron <jc at oxado.com> wrote:
>
> Hi,
>
> Start by checking your interface error counters on your servers
> (netstat -in) and switches. Also try a nice big ping -i 0.01 -c 10000
> between the boxes to see if you have any kind of packet loss.
>
> Jacques.
>
> At 15:52 23/05/2006, Kamran Nisar wrote:
>
> >hey alll...
> >we are having a weird problem with memcache.. descriptions below.
> >
> >the problem:
> >we shifted our hosting company, and ever since we got at the new
> >one.. we have been getting random connection error to memcache...
> >we've run various packets transfers during the memcache test to see
> >if a similar error is encountered there.. but the the problem seems
> >to occur with memcache only..
> >
> >
> >the memcached lies on anoher machine, and the hits are generated
> >using ab, when using anything above total of 1000 and concurrent of
> >150 connections.. we start getting random errors.. the errors are
> >mentioned below
> >
> >------
> >PHP Warning:  Memcache::pconnect() [<a
> >href='function.pconnect'>function.pconnect</a>]: Can't connect to
> ><http://10.0.0.51:11211>10.0.0.51:11211, Unknown error (0)
> >PHP Warning:  Memcache::pconnect() [<a href='
> >function.pconnect'>function.pconnect</a>]: Can't connect to
> ><http://10.0.0.51:11211>10.0.0.51:11211, Connection timed out (110)
> >
> >increased the port range to accomadate over 64K connections,
> >recompiled the kernel to accomodate TIME_WAIT to 2 secs, tried
> >setting up memcached on the same machine, remote machine.. but the
> >errorr keeps randonmly showing up...
> >
> >we are currently using 100Mbps ethernet cards , while previously we
> >had gigabit ethernet on managed switches.. and we have also swtiched
> >from intel to 64 bit AMD
> >
> >
> >
> >any suggestions/ides for debugging or reasons as to why the random
> >connect error comes up...
> >--
> >Regards
> >M Kamran Nisar,
>
>
>


-- 
Regards
M Kamran Nisar,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20060524/18df114a/attachment.htm