|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2007-07-10 09:08 UTC] ivyrake at gmail dot com
[2007-11-01 09:05 UTC] mikael at synd dot info
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sun Nov 02 19:00:02 2025 UTC |
Description: ------------ Two related descriptions. 1. On heavy loaded server (20-40 requests/s) I periodically (once a second) get an error message from memcached extension: # tail -f php-error_log |grep failed PHP Notice: Memcache::get(): marked server '127.0.0.1:11211' as failed ... But the server is up, the maximum number of connections (-m 1024) is not reached. And this error does not depend on how long the memcached server is running: a couple of minutes after memcached restart I can watch the same error, the statistics is: stats STAT pid 19854 STAT uptime 337 STAT time 1181115051 STAT version 1.2.2 STAT pointer_size 64 STAT rusage_user 1.727737 STAT rusage_system 6.867955 STAT curr_items 63413 STAT total_items 64222 STAT bytes 114838739 STAT curr_connections 16 STAT total_connections 3888 STAT connection_structures 27 STAT cmd_get 259618 STAT cmd_set 64563 STAT get_hits 196161 STAT get_misses 63457 STAT evictions 0 STAT bytes_read 148496793 STAT bytes_written 394115419 STAT limit_maxbytes 1073741824 STAT threads 1 I tried to disable setCompressThreshold, increase memcache.chunk_size, disable persistent connections, enlarge timeout parameters, but an error still happens. Furthermore, this error happens on Windows more frequently, even without heavy load, but I cannot reproduce. I have the only memcached server added: $this->connection = new Memcache(); $this->connection->addServer( "localhost", 11211, true, 1, 10, 2 ); 2. Seems in some cases I could reproduce this bug: if the key length is wuite large (in my situation - 361 bytes), "marked server '127.0.0.1:11211' as failed" is always reproducible. And this message is generated not immediately, but after the timeout (10 seconds in the example above) - very strange behaviour.