Hi Joseph,
I guess you know that your Memcached size if only 10MB (STAT limit_maxbytes
10485760). Magento zend cache (your objects) tests this size prior to
setting object, and if the limit is reached (STAT bytes) you cannot set any
new object in the cache, but you can set new sessions - so that might be
your problem , though not according to the stats u sent.
One more thing, it is better to deploy Magento with 2 Memcached servers,
one for the cache and one for the session, so whenever you upgrade your
site and flush the objects, you don't need to either flush your sessions -
see typical configuration of one of our customers below.
Best,
Yiftach
config>
<global>
<session_cache_limiter></session_cache_limiter>
<session_save><![CDATA[memcache]]></session_save>
<session_save_path><![CDATA[DNSADDRESS]></session_save_path>
<cache>
<backend>memcached</backend><!-- apc / memcached / xcache /
empty=file -->
<slow_backend>database</slow_backend> <!-- database / file
(default) - used for 2 levels cache setup, necessary for all shared memory
storages -->
<slow_backend_store_data>0</slow_backend_store_data>
<memcached><!-- memcached cache backend related config -->
<servers><!-- any number of server nodes can be included -->
<server>
<host><![CDATA[NSADDRESS]]></host>
<port><![CDATA[10245]]></port>
<persistent><![CDATA[1]]></persistent>
<weight><![CDATA[1]]></weight>
<timeout><![CDATA[10]]></timeout>
<retry_interval><![CDATA[10]]></retry_interval>
<status><![CDATA[1]]></status>
</server>
</servers>
<compression><![CDATA[0]]></compression>
<cache_dir><![CDATA[]]></cache_dir>
<hashed_directory_level><![CDATA[]]></hashed_directory_level>
<hashed_directory_umask><![CDATA[]]></hashed_directory_umask>
<file_name_prefix><![CDATA[]]></file_name_prefix>
</memcached>
</cache>
On Thu, Mar 1, 2012 at 9:59 AM, Joseph Brower <[email protected]> wrote:
> Thanks for the response.
>
> I've been testing as best I can and I've found that setting and getting
> fail. I get either no output, or a
>
> Notice: Memcache::set(): Server my.memcachehost.com (tcp 11211) failed
> with: Received malformed response (0) in /var/www/memcache.php on line 5
>
> I'm able to continue setting and getting via telnet without any issues.
> Also, if I redeploy my webserver (onto somewhere else in our cluster)
> things sometimes are happy, sometimes they continue to fail. When I look
> at netstat, I don't see the connections in memcache. When looking at the
> output from memcached, it doesn't show any additional output (as if the
> connection never reaches it.) I'm confident it's not my firewall rules, as
> I've got everything automated so that my configuration is consistent
> between versions. I've also ruled out the extension being used. It
> happens using the memcached, memcache, and an extensionless method that I
> found.
>
> I'm running on Ubuntu 10.04. All of the other services on this cluster
> don't have any connection issues (mysql, http, load balancer, ssl
> terminator) and they all use my same script for configuring the firewall
> rules appropriately.
>
> All of the stats look ok. I'm not maxing out the connection limit, and I
> am nowhere near memory limits. This happens when using memcache for
> sessions and for page cache.
> STAT pid 126
> STAT uptime 2017
> STAT time 1330588738
> STAT version 1.4.10
> STAT libevent 1.4.13-stable
> STAT pointer_size 64
> STAT rusage_user 0.040000
> STAT rusage_system 0.160000
> STAT curr_connections 10
> STAT total_connections 37
> STAT connection_structures 11
> STAT reserved_fds 20
> STAT cmd_get 45
> STAT cmd_set 35
> STAT cmd_flush 0
> STAT cmd_touch 0
> STAT get_hits 40
> STAT get_misses 5
> STAT delete_misses 0
> STAT delete_hits 0
> STAT incr_misses 0
> STAT incr_hits 10
> STAT decr_misses 0
> STAT decr_hits 0
> STAT cas_misses 0
> STAT cas_hits 0
> STAT cas_badval 0
> STAT touch_hits 0
> STAT touch_misses 0
> STAT auth_cmds 0
> STAT auth_errors 0
> STAT bytes_read 1942
> STAT bytes_written 1672
> STAT limit_maxbytes 10485760
> STAT accepting_conns 1
> STAT listen_disabled_num 0
> STAT threads 4
> STAT conn_yields 0
> STAT hash_power_level 16
> STAT hash_bytes 524288
> STAT hash_is_expanding 0
> STAT expired_unfetched 0
> STAT evicted_unfetched 0
> STAT bytes 303
> STAT curr_items 4
> STAT total_items 27
> STAT evictions 0
> STAT reclaimed 0
>
> That's how some of my stats are. I've tried various sizes, this is an
> exceptionally small one that I was using only for testing.
>
> Thanks,
>
> Joseph Brower
>
>
>
> On 02/29/2012 11:16 PM, Yiftach Shoolman wrote:
>
> Hi Joseph,
>
> Can you elaborate a bit more on your problem, what do you mean
> by unavailable, can you set/get keys ? are your app-->mmemcached tcp
> connections disconnected ? have you reached to your memcached memory limit
> (please send memcach stats) ? something else ?
>
> Also, specific question about Magento, does it happen on the session
> caching (I guess so) or the object caching the part that is based on zend
> caching ?
>
> Yiftach
>
> On Thu, Mar 1, 2012 at 3:41 AM, Joseph Brower <[email protected]>wrote:
>
>> When I'm using Memcache (the PECL extension) with Magento, everything
>> works well for an indeterminate amount of time. After some time
>> passes, Memcached becomes unavailable. This is the odd part though, I
>> can still telnet into MemcacheD and issue commands. I have 4
>> webservers all connecting to one memcache instance. Does anyone have
>> any ideas what might be going on?
>>
>> Thanks,
>>
>> Joseph Brower
>>
>
>
>
> --
> Yiftach Shoolman
> +972-54-7634621
>
>
>
--
Yiftach Shoolman
+972-54-7634621
