Thanks Boris, I haven't really given that much thought. Out of curiosity, why do you think the issue might be on the client end? I ask, cause I really don't have a sense of what to look for on that end and wonder if you might have some suggestions.
Best, Mike On Wednesday, November 19, 2014 12:46:16 PM UTC-4, Boris wrote: > > Hi Mike, this sounds to me more like a client/coding error rather than > memcached server. That's where I would focus first. > > Boris > > On Wed, Nov 19, 2014 at 11:41 AM, <[email protected] <javascript:>> > wrote: > >> I just had another failure. After pulling down my apache web servers, >> and before restarting memcached I grabbed stats to see if they showed >> anything of interest: >> >> - All 3 servers were reporting for duty following a getServerStatus (PHP >> client call) >> - curr_connections were listed as 8 across all the instances (apache was >> down but cron jobs up, so that would have dropped things down considerably) >> - listen_disabled_num was listed as 0 across all the instances >> - accepting_conns was listed as 1 across all the instances >> - evictions listed as 0 >> - All items across all instances had an evicted and evicted_nonzero and >> evicted_time value of 0 >> - All slabs across all instances had a total_pages value of 1 >> - tailrepairs and outofmemory is listed with a value of 0 across all >> items in each instance >> - global hit rate is 0.9937 >> - get_hits is always* greater than cmd_set on a per slab basis. *One >> slab reported both values as equal >> >> >> As far as I can tell, memcache is reporting that the world is fine and >> dandy. Should I be enlarging scope of the search to look at OS related >> factors that could result in the client receiving bad data? None of the >> machines are dipping into swap. >> >> Thanks, >> >> Mike >> >> >> >> On Wednesday, November 19, 2014 9:35:19 AM UTC-4, [email protected] >> wrote: >>> >>> For what it is worth, I'm hesitant to upgrade memcached to the latest >>> version as a step to try and solve this issue. It seems to me that since >>> our installs have been running without issue for quite some time (close to >>> a year), that there are other variables at play here. I just don't >>> understand the variables. ;) >>> >>> Thanks, >>> >>> Mike >>> >>> >>> On Tuesday, November 18, 2014 2:00:46 PM UTC-4, [email protected] >>> wrote: >>>> >>>> Hi There, >>>> >>>> I'm trying to diagnose a new problem with Memcache that seems to be >>>> happening with greater frequency. The issue has to do with memcache get >>>> requests returning incorrect responses (data from from other keys >>>> returned). Restarting or flushing the servers seems to resolve the issue. >>>> >>>> Do any memcache veterans have any suggestions of how I might dig into >>>> this issue? Stats that I might want to trace, log files to look at, etc? >>>> Does maybe this symptom fit the description of any known issues? >>>> >>>> I'm keeping a casual eye on on curr_connections, listen_disabled_num, >>>> accepting_conns, >>>> bytes, and limit_maxbytes (all show nothing unusual). I've verified that >>>> all servers and clients are set up in a consistent fashion. I'm not sure >>>> where to go from here to better understand the problem. >>>> >>>> >>>> If it helps, I'm running 1.4.13 (ubuntu 12.04 LTS) across 3 servers, >>>> connecting in with PHP Memcache 3.0.6 >>>> >>>> >>>> Tips? >>>> >>>> Mike >>>> >>>> >>>> >> >> >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "memcached" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
