Ya I noticed. But I'm not sure where to post this question. Posted here since relevant discussion was going on, and thought someone could reply.
On 11 August 2017 at 23:07, Boris Partensky <[email protected]> wrote: > 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 a topic in the > Google Groups "memcached" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/memcached/oAXusdLVRfU/unsubscribe. > To unsubscribe from this group and all its topics, 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.
