Re: Query Lifetime in Memcached 1.2.2
Thanks Brian, that makes much more sense to me. I was concerned that my queries were still being executed all the time to be dumped into Memcached. I've got a basic class set up to handle my actual implementation and thought perhaps I'd done something that caused the query to be set each time instead of just when it wasn't found. I guess this Age stat I'm seeing is meant to be a representation of how long it's been since the query was last accessed, which is fine. Thanks for the quick reply. Stephen On Mar 14, 10:46 pm, Brian Moon br...@moonspot.net wrote: Hi, bytes_written is a network number, not memory. It has written that many bytes out to the network. As for age, memcached has no such metric returned. So, that is likely just the interface you are using that is trying to be like apc faking it. If you want age in your memcache data, wrap all your memcache calls in a class that sets that data in a container and caches the container as a while object and pulls it back apart for you on gets. Its what I do. I do all kinds of neat things like soft timeouts and such. On 3/14/11 10:13 PM, Stephen wrote: Hello, I'm running a Debian Lenny installation, and thus running Memcached 1.2.2. If the statistics that I'm seeing via the tool from http://livebookmark.net/journal/2008/05/21/memcachephp-stats-like-apc... are to be believed, then it appears that my queries are getting refreshed every time a get is called (ie, the Age statistic returns to 0 minutes with each get(QueryName) call). Is this normal behavior? A stat dump: STAT pid 28382 STAT uptime 71174 STAT time 1300154240 STAT version 1.2.2 STAT pointer_size 64 STAT rusage_user 11.485253 STAT rusage_system 53.794821 STAT curr_items 4 STAT total_items 4 STAT bytes 111793 STAT curr_connections 9 STAT total_connections 605498 STAT connection_structures 55 STAT cmd_get 173965 STAT cmd_set 4 STAT get_hits 173961 STAT get_misses 4 STAT evictions 0 STAT bytes_read 3599661 STAT bytes_written 8642675377 STAT limit_maxbytes 536870912 STAT threads 1 So it's written 8GB of data in 20 hours, though it's only using a little over 100KB of the memory I've dedicated to it? I use the following PHP as a test: $lol = new Memcache; // Also tried new Memcache() due to different documentation, same result $lol-connect(localhost, 11211); $res = $lol-get(TestQuery); print_r($res); The results are shown as expected via the print_r(). But, each time that script executes, the Age statistic for TestQuery I'm seeing from the memcache.php utility says 0 minutes again. Have I misconfigured something, or is this how Memcached is supposed to behave, rewriting the data every time it's accessed and resetting the age of the data. I'm just not sure what I should be looking for, but having that many bytes written doesn't seem right to me. Thank you, Stephen -- Brian. http://brian.moonspot.net/
Issue 191 in memcached: Implementation of CHECK command for memcached
Status: New Owner: Labels: Type-Defect Priority-Medium New issue 191 by romanenko.oleg: Implementation of CHECK command for memcached http://code.google.com/p/memcached/issues/detail?id=191 Hello. I've been using memcached for storing data with a short lifetime and I found that the use of the add command to test the existence of a key requires additional expenses, because if the key does not exist already (expired) - it will be recreated. I have implemented a new command check, which allows you to verify the existence of a key. This command also allows you to set a new expiration time for a key. Use: check key [exptime] [noreply] Binary protocol is also supported. I have attached three patches. Patch for memcached, which implements a new command. A patch for the documentation. And a patch for tests. I also publish my patch through a git: memcached forked repo: https://github.com/Slader/memcached and link to commit with patch: https://github.com/Slader/memcached/commit/b0f5d95e2704c6d8dc9b63519646d58db2dda4f2 Attachments: memcached-check.patch 11.0 KB memcached-check-doc.patch 6.9 KB memcached-check-tests-1.4.5.patch 7.0 KB memcached-check-tests-trunk.patch 7.0 KB
Issue 192 in memcached: Crash when sending specially crafted packet
Status: New Owner: Labels: Type-Defect Priority-Medium New issue 192 by stefan.b...@gmail.com: Crash when sending specially crafted packet http://code.google.com/p/memcached/issues/detail?id=192 What steps will reproduce the problem? 1. Start memcached in TCP mode. For example: $ ./memcached -v -p 11211 -U 0 2. Send the specially crafted packet to it: $ echo -en '\x80\x12\x00\x01\x08\x00\x00\x00\xff\xff\xff\xe8\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x01\x00\x00\x00\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' | nc localhost 11211 What is the expected output? What do you see instead? The expected output is an error message (since the packet is not valid). Instead, memcached segfaults. The backtrace in gdb is: #0 0x776a93e2 in _wordcopy_bwd_dest_aligned (dstp=140737352380384, srcp=6497184, len=2305843009213693940) at wordcopy.c:392 #1 0x776a75e9 in memmove (dest=0x77e53053, src=value optimized out, len=18446744073709551581) at memmove.c:99 #2 0x0040a165 in drive_machine (fd=value optimized out, which=value optimized out, arg=0x632200) at /usr/include/bits/string3.h:59 #3 event_handler (fd=value optimized out, which=value optimized out, arg=0x632200) at memcached.c:3732 #4 0x77bc8194 in event_base_loop () from /usr/lib/libevent-1.4.so.2 #5 0x0040db84 in worker_libevent (arg=0x61c0a0) at thread.c:245 #6 0x779ac971 in start_thread (arg=value optimized out) at pthread_create.c:304 #7 0x7770892d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #8 0x in ?? () What version of the product are you using? On what operating system? Memcached 1.4.5 / Ubuntu 10.10 x64 Please provide any additional information below. The packet was generated automatically by a research testing tool under development at the Dependable Systems Laboratory, at the Swiss Federal Institute of Technology (EPFL), Switzerland (http://dslab.epfl.ch/).
Re: Issue 192 in memcached: Crash when sending specially crafted packet
Comment #1 on issue 192 by romanenko.oleg: Crash when sending specially crafted packet http://code.google.com/p/memcached/issues/detail?id=192 it is easy to fix with small patch, but in memcached internals there are so many functions without correct arguments cheking. Attachments: issue-192-crash-fix.patch 1.1 KB
Re: Implementation of CHECK command for memcached
On Mar 15, 9:28 am, Oleg Romanenko romanenko.o...@gmail.com wrote: Hello. I've been using memcached for storing data with a short lifetime and I found that the use of the add command to test the existence of a key requires additional expenses, because if the key does not exist already (expired) - it will be recreated. I have implemented a new command check, which allows you to verify the existence of a key. This command also allows you to set a new expiration time for a key. Hey, saw your change. It looks pretty thorough. :) We've done some similar work in the engine branch for setting expiration. I don't think it makes sense to check for the existence of a key, however. How could this be put to use? i.e. when is knowing that something exists at some point in an ephemeral store useful to an application?
