Gopal, did you noticed that you are replying to the entry from 2009? On Thu, Aug 10, 2017 at 5:58 AM, Gopal Bharath <[email protected]> wrote:
> Hi Anatoly, > > How can check the size of the value, if its a perl hash? I mean if the set > fails, will i be getting any error messages? I tried googling, and found > that there's a method getResultCode give the result code for the previous > executed command. But unfortunately i guess its support in PHP client not > supported in perl client. Is there any way to know why the set is failing? > > Any help would be appreciated. > > On Wednesday, April 22, 2009 at 9:54:51 PM UTC+5:30, Anatoly Vorobey wrote: >> >> On Wed, Apr 22, 2009 at 3:01 PM, tcbarrett <[email protected]> wrote: >> >>> >>> On Apr 22, 12:09 pm, Anatoly Vorobey <[email protected]> wrote: >>> > > 1. My code is no good, and I am not actually inserting into the cache >>> > > for some reason. >>> > >>> > Always possible. >>> >>> I've done the horrible thing, made a wrapping class and logging every >>> get and set (I've got some stupid keys). >>> >>> > > 2. The size of the hash value is bigger than 'limit_maxbytes' >>> > >>> > Actually, the largest a single item may be is about 1Mb (the size of >>> the >>> > largest "bucket"), not limit_maxbytes, which is 1.5G in your case. If >>> your >>> > items are larger, you can change the largest bucket limit (only by >>> changing >>> > the source code and rebuilding, look in slabs.c). >>> >>> OK. So how do I measure whether this is happening? Does set() fail? >> >> >> Right, set() would fail in this case. >> >> >>> >>> Can I measure how big my cache value is going to be before attempting >>> to set it? >> >> >> Just looking at the length of the string (assuming byte strings) holding >> the >> value gives you the right ballpark. >> >> Also, looking at 'stats slabs' might give some additional information. >> >> If you're saying that the following happens: >> >> - you try to store some key-value pair in a memcached server >> - your set commands succeeds (as witnessed by your wrapping class) >> - the set command has an expiration time in the future >> - you try to get the same key later, but before the expiration time is due >> - your get command goes to the same server and requests the same value >> (e.g. you're sure it's the same key, and in case you have many servers, >> you didn't mess with the key-based sharding in the client) >> - your get command fails, while stats command in the server shows 0 >> evictions, so >> your value couldn't have been evicted >> >> If all of these are true, my best remaining guess is that set actually >> failed, but >> some problem in the perl client and/or your code beyond it ate up the >> error and >> prevented you from seeing it. If that can't happen, I'm out of guesses. >> >> Just recently someone posted a link to a tool that freezes a running >> server and dumps >> all its keys; might help you to ascertain that they key made or did not >> make it to the >> server. >> >> >>> >>> >>> > > 3. Something else is using up the memory, silently destroying my >>> > > cache. >>> > >>> > Unlikely. >>> >>> I do hope and pray that you are correct. I have Apache and mod_perl >>> running, and the values from 'top' and 'free' are just all over the >>> place. >>> >>> > > Or have I left something unconsidered? >>> > >>> > 4. You're running with a non-default flag that prevent memcached from >>> > evicting >>> > other items to insert the ones you want. I believe -M does that (sets >>> > settings.evict_to_free=0). >>> >>> It was a standard installlation (memcached 1.2.6), and is a fairly >>> simple invocation like so: >>> /usr/local/bin/memcached -u nobody -d -m 1536 -l 127.0.0.1 -p 11211 - >>> P /tmp/memcached.pid >>> >>> Running the code on a test machine, killing memcache and to re- >>> starting it, then pre-loading as much cache as I can think of at the >>> moment: looking at stats()->{total}->{bytes_written} ... I only appear >>> to be using ~100M. >>> >>> I have absolutely no measuring stick and would be delighted beyond >>> words if this was true. Because if it is then I can't believe the >>> amount data I can keep in cache (if I can get it working). And I >>> should probably upgrade to a more recent version, but I don't think >>> this will change my current problem. >> >> >> >> >> -- >> Anatoly Vorobey, [email protected] >> http://avva.livejournal.com (Russian) >> http://www.lovestwell.org (English) >> >> -- > > --- > 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. > -- --- 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.
