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 <tcba...@gmail.com
> <javascript:>> wrote:
>
>>
>> On Apr 22, 12:09 pm, Anatoly Vorobey <avoro...@gmail.com> 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, avor...@gmail.com <javascript:>
> 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 memcached+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
