Yeah, this was my impression as well. I wrote a small test-script in ruby to fill the cache with a bunch of objects of the same size, and then try to put in a small object, but it still did not reproduce the problem. I don't have a spare 3G of ram box to try it on.
<br><br>What happens if you try to store an object of N bytes, but there are no slabs with buckets of that size? I'd assume that you'd either put it in a bigger bucket or retire an entire slab.<br><br><div class="gmail_quote">
On Nov 13, 2007 5:25 PM, Jeremy Blain <<a href="mailto:jeremy@belent.com">jeremy@belent.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I've seen this happen in the past as well, but forgot about it till now.<br>Bouncing the server also fixed it.<br><br>My not very thorough looking about seemed to suggest the cache had<br>allocated all it's slabs already to certain sized objects, and it wanted
<br>to store the current object in a slab that had chunks of sizes that<br>didn't exist.<br><div class="Ih2E3d"><br><br><br><br>Matt Knox wrote:<br><br>> The problem seems to have gone away on bouncing memcache, and we can't
<br>> replicate it, even though we started memcache in exactly the same way,<br>> on the same machines. We'll probably make 3 1Gb instances instead of<br>> the 3G instances if it recurs.<br>><br>> thanks for the help!
<br>><br>> matt<br>><br>><br>> On Nov 11, 2007 9:06 PM, dormando <<a href="mailto:dormando@rydia.net">dormando@rydia.net</a><br></div><div><div></div><div class="Wj3C7c">> <mailto:<a href="mailto:dormando@rydia.net">
dormando@rydia.net</a>>> wrote:<br>><br>> *pulls old mail out of garbage*<br>><br>> Curious if you're still having this issue? If it's been fixed/etc? I<br>> didn't see any noise on the list about it since.
<br>><br>> Matt Knox wrote:<br>> > I consistently get an out of memory error when performing < 44<br>> byte<br>> > (key+data) puts to memcache, but when 'put'-ing the same key
<br>> with data<br>> > that is long enough to exceed 44 chars key + data , I succeed. I<br>> > observe this behavior using both the ruby client<br>> (memcache-client 1.5)<br>> > and the python one (python-memcached), although the python
<br>> client seems<br>> > to break at 59 chars, rather than 44.<br>><br>> Spiffy! Can't reproduce it on a 64-bit host. Haven't tried 32-bit.<br>><br>> > I'm running memcached
1.2.2 with the following options:<br>> ><br>> > memcached -d -p 11211 -u nobody -c 1024 -m 3072<br>> ><br>> > The offending servers are recent CentOS running 3G of cache each on<br>
> > 32-bit boxes with 4G ram-if it matters, I can get details about<br>> these.<br>><br>> I suspect that's a big deal. The maxbytes limit doesn't include random<br>> buffers that are used for connections, stats commands, this and
<br>> that. So<br>> you'll be apt to bowl over the 32-bit address space. I've never<br>> trusted<br>> that the different splits even work.<br>><br>> So, if you are still having this issue:
<br>><br>> - How'd you build memcached?<br>> - Exactly what version of centos?<br>> - Does it happen after memcached has been up for a long time, or<br>> immediately?<br>> - Does it still happen if you lower the -m option to
1.6-1.8<br>> gigabytes?<br>><br>> Thanks,<br>> -Dormando<br>><br>><br>><br><br></div></div></blockquote></div><br><br clear="all"><br>-- <br>(def (eval e l d c)<br> (if (atom? e)<br> ((ahandler (type e)) e l d c)
<br> (eval (car e) l d <br> (fun (x) <br> (evapp x (cdr e) l d c)))))