from:"dormando"

What version of memcached is this?

How are you reproducing the bug?

What OS/version are you on?

On Wed, 25 Apr 2012, lee wrote:

 the  memcached main process can't accept  connect when use
 assoc_maintenance_thread function,here is the gdb bt result:
 we have 4 thread :
   |-memcached,28059 -d -p 12111 -c 8192 -m 16384 -u root -l 127.0.0.1
   |   |-{memcached},28060
   |   |-{memcached},28061
   |   |-{memcached},28062
   |   |-{memcached},28063
   |   `-{memcached},28064

 gdb bt result:
  gdb -p 28060
 GNU gdb Fedora (6.8-37.el5)
 Copyright (C) 2008 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/
 gpl.html
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.  Type show
 copying
 and show warranty for details.
 This GDB was configured as x86_64-redhat-linux-gnu.
 Attaching to process 28060

 warning: process 28060 is a cloned process
 Reading symbols from /usr/local/sinawap/bin/memcached...done.
 Reading symbols from /usr/local/sinawap/lib/libevent-1.4.so.2...done.
 Loaded symbols for /usr/local/sinawap/lib/libevent-1.4.so.2
 Reading symbols from /lib64/libpthread.so.0...done.
 [Thread debugging using libthread_db enabled]
 [New Thread 0x7f2ec05b86e0 (LWP 28059)]
 [New Thread 0x434f2940 (LWP 28064)]
 [New Thread 0x42cf1940 (LWP 28063)]
 [New Thread 0x424f0940 (LWP 28062)]
 [New Thread 0x41cef940 (LWP 28061)]
 [New Thread 0x414ee940 (LWP 28060)]
 Loaded symbols for /lib64/libpthread.so.0
 Reading symbols from /lib64/libc.so.6...done.
 Loaded symbols for /lib64/libc.so.6
 Reading symbols from /lib64/libnsl.so.1...done.
 Loaded symbols for /lib64/libnsl.so.1
 Reading symbols from /lib64/librt.so.1...done.
 Loaded symbols for /lib64/librt.so.1
 Reading symbols from /lib64/libresolv.so.2...done.
 Loaded symbols for /lib64/libresolv.so.2
 Reading symbols from /lib64/ld-linux-x86-64.so.2...done.
 Loaded symbols for /lib64/ld-linux-x86-64.so.2
 Reading symbols from /lib64/libnss_files.so.2...done.
 Loaded symbols for /lib64/libnss_files.so.2
 0x003095a0d524 in __lll_lock_wait () from /lib64/libpthread.so.0
 (gdb) bt
 #0  0x003095a0d524 in __lll_lock_wait () from /lib64/libpthread.so.
 0
 #1  0x003095a08e1a in _L_lock_1034 () from /lib64/libpthread.so.0
 #2  0x003095a08cdc in pthread_mutex_lock () from /lib64/
 libpthread.so.0
 #3  0x0040d08e in item_get (key=0x7f2cf8ac1424
 ttt_newuser_2272938860, nkey=128) at thread.c:343
 #4  0x00403c14 in process_get_command (c=0x7f2d3888f080,
 tokens=0x414eded0, ntokens=0, return_cas=false)
 at memcached.c:2542
 #5  0x00408256 in process_command (c=0x7f2d3888f080,
 command=value optimized out) at memcached.c:2975
 #6  0x00408bfe in try_read_command (c=0x7f2d3888f080) at
 memcached.c:3185
 #7  0x0040989d in event_handler (fd=value optimized out,
 which=128, arg=0x7f2d3888f080) at memcached.c:3491
 #8  0x7f2ec05c25f8 in event_base_loop (base=0x63f420, flags=0) at
 event.c:392
 #9  0x0040cbb4 in worker_libevent (arg=0x633f70) at thread.c:
 245
 #10 0x003095a0673d in start_thread () from /lib64/libpthread.so.0
 #11 0x0030952d44bd in clone () from /lib64/libc.so.6

  gdb -p 28061
 GNU gdb Fedora (6.8-37.el5)
 Copyright (C) 2008 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/
 gpl.html
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.  Type show
 copying
 and show warranty for details.
 This GDB was configured as x86_64-redhat-linux-gnu.
 Attaching to process 28061

 warning: process 28061 is a cloned process
 Reading symbols from /usr/local/sinawap/bin/memcached...done.
 Reading symbols from /usr/local/sinawap/lib/libevent-1.4.so.2...done.
 Loaded symbols for /usr/local/sinawap/lib/libevent-1.4.so.2
 Reading symbols from /lib64/libpthread.so.0...done.
 [Thread debugging using libthread_db enabled]
 [New Thread 0x7f2ec05b86e0 (LWP 28059)]
 [New Thread 0x434f2940 (LWP 28064)]
 [New Thread 0x42cf1940 (LWP 28063)]
 [New Thread 0x424f0940 (LWP 28062)]
 [New Thread 0x41cef940 (LWP 28061)]
 [New Thread 0x414ee940 (LWP 28060)]
 Loaded symbols for /lib64/libpthread.so.0
 Reading symbols from /lib64/libc.so.6...done.
 Loaded symbols for /lib64/libc.so.6
 Reading symbols from /lib64/libnsl.so.1...done.
 Loaded symbols for /lib64/libnsl.so.1
 Reading symbols from /lib64/librt.so.1...done.
 Loaded symbols for /lib64/librt.so.1
 Reading symbols from /lib64/libresolv.so.2...done.
 Loaded symbols for /lib64/libresolv.so.2
 Reading symbols from /lib64/ld-linux-x86-64.so.2...done.
 Loaded symbols for /lib64/ld-linux-x86-64.so.2
 Reading symbols from /lib64/libnss_files.so.2...done.
 Loaded symbols for /lib64/libnss_files.so.2
 0x003095a0d524 in __lll_lock_wait () from /lib64/libpthread.so.0
 (gdb) bt
 #0  0x003095a0d524 in __lll_lock_wait () from

Re: Memcached is not responsive to any request

 Hi all,

 I compiled and installed Memcached 1.4.3 from source:
 http://memcached.googlecode.com/files/memcached-1.4.13.tar.gz

 The configuration is quite simple: ./configure --prefix=/usr/local/
 memcached

 It works if I install it on a dedicated Ubuntu 11 server. However, it
 does not work on Linode's Ubuntu 11 VM (Xen-based)

 The source code can be compilable, installable. The server can run but
 it is not responsive.

 === Telnet access ==
 root@spica:/home/dev7# telnet 127.0.0.1 11211
 Trying 127.0.0.1...
 Connected to 127.0.0.1.
 Escape character is '^]'.
 get
 fdsgfdsf
 f
 sdfds
 f
 dsadfs
 ]
 ^]

If running memcached in the foreground with -vvv, does telnetting and
running commands have any output? does strace show the server receiving
those lines as you type them?

Re: Memcached is not responsive to any request

 === I can not see any request or request handling operations logged
 in the session 1 screen or session 3
 It seems that Memcached does not know about any request I sent to it.

 Any idea?

Looks like you're firewalled from it somehow. You'd at least see the
accept() calls on memcached's end, I'd think.


 On Apr 25, 11:05 pm, dormando dorma...@rydia.net wrote:
   Hi all,
 
   I compiled and installed Memcached 1.4.3 from source:
  http://memcached.googlecode.com/files/memcached-1.4.13.tar.gz
 
   The configuration is quite simple: ./configure --prefix=/usr/local/
   memcached
 
   It works if I install it on a dedicated Ubuntu 11 server. However, it
   does not work on Linode's Ubuntu 11 VM (Xen-based)
 
   The source code can be compilable, installable. The server can run but
   it is not responsive.
 
   === Telnet access ==
   root@spica:/home/dev7# telnet 127.0.0.1 11211
   Trying 127.0.0.1...
   Connected to 127.0.0.1.
   Escape character is '^]'.
   get
   fdsgfdsf
   f
   sdfds
   f
   dsadfs
   ]
   ^]
 
  If running memcached in the foreground with -vvv, does telnetting and
  running commands have any output? does strace show the server receiving
  those lines as you type them?

Re: memcached bug can't release the cache_lock

We can't support crashes in old versions.

Please upgrade to the latest (1.4.13) and file again if you still have a
crash.

On Wed, 25 Apr 2012, lee wrote:

 memcached-1.4.5
 i can't reproducing the bug
 2.6.30 x86_64 CentOS

 On 4月25日, 下午12时03分, dormando dorma...@rydia.net wrote:
  What version of memcached is this?
 
  How are you reproducing the bug?
 
  What OS/version are you on?
 
 
 
  On Wed, 25 Apr 2012, lee wrote:
   the  memcached main process can't accept  connect when use
   assoc_maintenance_thread function,here is the gdb bt result:
   we have 4 thread :
 |-memcached,28059 -d -p 12111 -c 8192 -m 16384 -u root -l 127.0.0.1
 |   |-{memcached},28060
 |   |-{memcached},28061
 |   |-{memcached},28062
 |   |-{memcached},28063
 |   `-{memcached},28064
 
   gdb bt result:
gdb -p 28060
   GNU gdb Fedora (6.8-37.el5)
   Copyright (C) 2008 Free Software Foundation, Inc.
   License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/
   gpl.html
   This is free software: you are free to change and redistribute it.
   There is NO WARRANTY, to the extent permitted by law.  Type show
   copying
   and show warranty for details.
   This GDB was configured as x86_64-redhat-linux-gnu.
   Attaching to process 28060
 
   warning: process 28060 is a cloned process
   Reading symbols from /usr/local/sinawap/bin/memcached...done.
   Reading symbols from /usr/local/sinawap/lib/libevent-1.4.so.2...done.
   Loaded symbols for /usr/local/sinawap/lib/libevent-1.4.so.2
   Reading symbols from /lib64/libpthread.so.0...done.
   [Thread debugging using libthread_db enabled]
   [New Thread 0x7f2ec05b86e0 (LWP 28059)]
   [New Thread 0x434f2940 (LWP 28064)]
   [New Thread 0x42cf1940 (LWP 28063)]
   [New Thread 0x424f0940 (LWP 28062)]
   [New Thread 0x41cef940 (LWP 28061)]
   [New Thread 0x414ee940 (LWP 28060)]
   Loaded symbols for /lib64/libpthread.so.0
   Reading symbols from /lib64/libc.so.6...done.
   Loaded symbols for /lib64/libc.so.6
   Reading symbols from /lib64/libnsl.so.1...done.
   Loaded symbols for /lib64/libnsl.so.1
   Reading symbols from /lib64/librt.so.1...done.
   Loaded symbols for /lib64/librt.so.1
   Reading symbols from /lib64/libresolv.so.2...done.
   Loaded symbols for /lib64/libresolv.so.2
   Reading symbols from /lib64/ld-linux-x86-64.so.2...done.
   Loaded symbols for /lib64/ld-linux-x86-64.so.2
   Reading symbols from /lib64/libnss_files.so.2...done.
   Loaded symbols for /lib64/libnss_files.so.2
   0x003095a0d524 in __lll_lock_wait () from /lib64/libpthread.so.0
   (gdb) bt
   #0  0x003095a0d524 in __lll_lock_wait () from /lib64/libpthread.so.
   0
   #1  0x003095a08e1a in _L_lock_1034 () from /lib64/libpthread.so.0
   #2  0x003095a08cdc in pthread_mutex_lock () from /lib64/
   libpthread.so.0
   #3  0x0040d08e in item_get (key=0x7f2cf8ac1424
   ttt_newuser_2272938860, nkey=128) at thread.c:343
   #4  0x00403c14 in process_get_command (c=0x7f2d3888f080,
   tokens=0x414eded0, ntokens=0, return_cas=false)
   at memcached.c:2542
   #5  0x00408256 in process_command (c=0x7f2d3888f080,
   command=value optimized out) at memcached.c:2975
   #6  0x00408bfe in try_read_command (c=0x7f2d3888f080) at
   memcached.c:3185
   #7  0x0040989d in event_handler (fd=value optimized out,
   which=128, arg=0x7f2d3888f080) at memcached.c:3491
   #8  0x7f2ec05c25f8 in event_base_loop (base=0x63f420, flags=0) at
   event.c:392
   #9  0x0040cbb4 in worker_libevent (arg=0x633f70) at thread.c:
   245
   #10 0x003095a0673d in start_thread () from /lib64/libpthread.so.0
   #11 0x0030952d44bd in clone () from /lib64/libc.so.6
 
gdb -p 28061
   GNU gdb Fedora (6.8-37.el5)
   Copyright (C) 2008 Free Software Foundation, Inc.
   License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/
   gpl.html
   This is free software: you are free to change and redistribute it.
   There is NO WARRANTY, to the extent permitted by law.  Type show
   copying
   and show warranty for details.
   This GDB was configured as x86_64-redhat-linux-gnu.
   Attaching to process 28061
 
   warning: process 28061 is a cloned process
   Reading symbols from /usr/local/sinawap/bin/memcached...done.
   Reading symbols from /usr/local/sinawap/lib/libevent-1.4.so.2...done.
   Loaded symbols for /usr/local/sinawap/lib/libevent-1.4.so.2
   Reading symbols from /lib64/libpthread.so.0...done.
   [Thread debugging using libthread_db enabled]
   [New Thread 0x7f2ec05b86e0 (LWP 28059)]
   [New Thread 0x434f2940 (LWP 28064)]
   [New Thread 0x42cf1940 (LWP 28063)]
   [New Thread 0x424f0940 (LWP 28062)]
   [New Thread 0x41cef940 (LWP 28061)]
   [New Thread 0x414ee940 (LWP 28060)]
   Loaded symbols for /lib64/libpthread.so.0
   Reading symbols from /lib64/libc.so.6...done.
   Loaded symbols for /lib64/libc.so.6
   Reading symbols from /lib64/libnsl.so.1...done.
   Loaded symbols for /lib64/libnsl.so.1
   Reading symbols from /lib64/librt.so

Re: Storage Engine ?

2012-04-23 Thread dormando

 On Tue, Apr 10, 2012 at 11:01 PM, Aaron Stone sodab...@gmail.com wrote:
  On Tue, Apr 10, 2012 at 10:45 PM, Dustin dsalli...@gmail.com wrote:
 
  On Sunday, April 8, 2012 10:53:53 PM UTC-7, Aaron Stone wrote:
 
  git cherry reported 443 changesets between master and merge-wip. The first
  few changesets came back as Already up-to-date. I ran through the rest
  thusly:
 
  for i in $(git cherry master | cut -f2 -d\  ); do
    echo $i;
    git merge -Xpatience -Xrename-threshold=100 $i;
    if [ $? -ne 0 ]; then
      echo STOPPED AT $i;
      break;
    fi;
  done
 
  They all came back clear. So... ??? Ship it!
 
 
 
    Really?  I guess that's possible.  I didn't expect it to be that far
  behind, but do you have this somewhere I can see it?
 
  It also didn't do anything; no commits resulted from running that command.

 If the engine merge branch actually has all relevant code from master,
 could we begin releasing memcached 1.4 versions from a memcached14
 branch, and merge engine to master?

It doesn't yet. I'm not sure what happened when you attempted that merge?
I modified the core all over.

Re: Use of memcache

2012-04-22 Thread dormando

Memcached's architecture is a set of tradeoffs:

- Add a little network roundtrip latency
  - Gain global atomic invalidation
  - Gain linearly expanding cache size

Global invalidation means your cache can be more useful, and perhaps you
can use it in more places.

Expansive cache means (if you have enough data) that you hit your backend
less often, which tends to make up for the speed loss from going over
the network.

If neither of those tradeoffs are valueable to you, don't set it up that
way.

On Sat, 21 Apr 2012, Suraj wrote:

 Hi,

 We are having a scenario, where for each request, we call memcache
 about 250 times. Our memcache data size is not much and totals to
 around 1 GB. Multiget is not an a straight forward option, as our
 cache calls are scattered across the code and depends on the business
 scenario.

 Each server nearly serves 10 million requests per day and a cluster
 combined serves nearly 1 billion requests a day. We are having a
 gigabit ethernet. Our server side response time for each request is
 and should be  85 ms.

 What approach should be ideal for this scenario?

 1. Run memcache on each server on unix socket.
 This will reduce the network latency but increase the cache miss ratio
 a bit and data redundancy, as nearly same data is present on each
 node of the cluster.
 We are having similar setup and see around 85% cache hit. Our expiry
 time varies for different keys.

 or

 2. Have a distributed memcache layer. This will probably increase the
 cache hit ratio to more than 99%.
 But this will add the network latency and may be a single point of
 failure.

 I did a very basic get bench marking on a low end machine.
 1. 100,000 get, 1 thread, memcache and benchmarking script on same
 machine - 1.233s
 2. 100,000 get, 1 thread, memcache and benchmarking script on
 different machine  - 9.538s

 From this numbers, approach 1, the one we are doing right now seems to
 be a better one.
 Please let me know your opinion, about what approach seems to be
 better or if there is any different suggestion.

 Thanks.

Re: How to implement 50M key-value pair memcache with 4 M qps?

2012-04-20 Thread dormando

No,

numactl --hardware will tell you how many nodes you have. googling will
tell you more about NUMA. Intel i3/i5's aren't NUMA chips, however, so
those are probably just one node already.

On Mon, 16 Apr 2012, yunfeng sun wrote:

Dear Dormando,
Regards binding one memcached instance per NUMA node, should we understand
NUMA node as a core with Intel i3/i5 4-core processors?

So numactl --cpunodebind=0 ./memcached -m 4000 -t 4 will bind memcached
instance to a CPU core, right?

Thanks again!

On Tuesday, April 17, 2012 8:56:31 AM UTC+8, Dormando wrote:
The business scenario requires:

50M key-value pairs, 2K each , 100G memory in total.

About 40% of key-value will change in a second.

The Java application need Get() once and set() once for each changed
pair, it will be 50M*40%*2=4M qps (query per second) .

We tested memcached - which shows very limited qps.
Our benchmarking is very similar to results showed
herehttp://xmemcached.googlecode.com/svn/trunk/benchmark/benchmark.html

10,000 around qps is the limitation of one memcached server.

That mean we need 40 partitioned memcached servers in our business
scenario- which seems very uneconomic and unrealistic.

In your experience, is the benchmarking accurate in term of
memcached’s designed performance?

Any suggestion to tune memcached system(client or server)?

Or any other alternative memory store system that is able meet the
requirement more economically?

Many thanks in advance!

You should share your actual benchmark code. Also, what version of
memcached, OS, network, etc?

After 1.4.10, a single memcached instance can do nearly one million sets
per second:

http://groups.google.com/group/memcached/browse_thread/thread/972a4cf1f2c1b017/b3aaf416639e81a6

There are a lot of things you need to tune to get that level of
performance in a real scenario, however:

- fast network. you will be limited by your packets per second. a single
gige nic might not do more than 600,000 per second, but also could be as
low as 250,000 before packet loss.

- batch as many commands as you can (using binary protocol, with
noreply). fewer round trips, fewer packets on the wire.

- use as many clients as you can (a single connection doing synchronous
sets will be slow in *any* benchmark)

- as noted in the above link, binding one memcached instance per NUMA
node
can improve performance

- tune the number of threads correctly

- always use the latest version

performance should continue to improve over the coming months, but it's
very difficult to see results of the improvements on actual hardware.
I'd
say you'd need 10 half decent servers to achieve that level of
performance
and have good headroom. If you really tune things hard you could get
that
down to 6. If you left me alone in a room for a few months with a giant
pile of money I could do it with two. three for redundancy.

-Dormando

Re: How to implement 50M key-value pair memcache with 4 M qps?

2012-04-16 Thread dormando

The business scenario requires:

50M key-value pairs, 2K each , 100G memory in total.

About 40% of key-value will change in a second.

The Java application need Get() once and set() once for each changed pair, it
will be 50M*40%*2=4M qps (query per second) .

We tested memcached - which shows very limited qps.
Our benchmarking is very similar to results showed
herehttp://xmemcached.googlecode.com/svn/trunk/benchmark/benchmark.html

10,000 around qps is the limitation of one memcached server.

That mean we need 40 partitioned memcached servers in our business scenario-
which seems very uneconomic and unrealistic.

In your experience, is the benchmarking accurate in term of memcached’s
designed performance?

Any suggestion to tune memcached system(client or server)?

Or any other alternative memory store system that is able meet the
requirement more economically?

Many thanks in advance!

You should share your actual benchmark code. Also, what version of
memcached, OS, network, etc?

After 1.4.10, a single memcached instance can do nearly one million sets
per second:
http://groups.google.com/group/memcached/browse_thread/thread/972a4cf1f2c1b017/b3aaf416639e81a6

There are a lot of things you need to tune to get that level of
performance in a real scenario, however:

- fast network. you will be limited by your packets per second. a single
gige nic might not do more than 600,000 per second, but also could be as
low as 250,000 before packet loss.

- batch as many commands as you can (using binary protocol, with
noreply). fewer round trips, fewer packets on the wire.

- use as many clients as you can (a single connection doing synchronous
sets will be slow in *any* benchmark)

- as noted in the above link, binding one memcached instance per NUMA node
can improve performance

- tune the number of threads correctly

- always use the latest version

performance should continue to improve over the coming months, but it's
very difficult to see results of the improvements on actual hardware. I'd
say you'd need 10 half decent servers to achieve that level of performance
and have good headroom. If you really tune things hard you could get that
down to 6. If you left me alone in a room for a few months with a giant
pile of money I could do it with two. three for redundancy.

-Dormando

Re: How to implement 50M key-value pair memcache with 4 M qps?

2012-04-16 Thread dormando

 The Java application need Get() once and set() once for each changed pair, it 
 will be 50M*40%*2=4M qps (query per second) .

 We tested memcached - which shows very limited qps.
 Our benchmarking is very similar to results showed 
 herehttp://xmemcached.googlecode.com/svn/trunk/benchmark/benchmark.html

 10,000 around qps is the limitation of one memcached server.

Just to be completely clear; 10,000 qps in your test is the limit of
*one java thread client*, the limit of the server is nowhere near that. If
you started ten client threads, each doing gets/sets, you will likely get
100,000 qps.

If you edit your java code and fetch 100 keys at once with multiget, then
set 100 keys (using binary protocol or ASCII noreply for the sets), it
will get even faster still.

Then you do all the other stuff I said. I'd be surprised if you found any
daemon that's faster than memcached though.

Re: Data compression

2012-04-13 Thread dormando

 So, I would like to as, it it would be possible to add (internal)
 compression mechanism to the memcached daemon. I was thinking about a
 switch which would switch the compression on/off (and/or setting the
 level) during memcached start. The data would be compressed
 transparently, so no interface/protocol change will occur in fact (it
 would only use less memory).

The *most* efficient thing for you to do is to use client compression, to
be honest. I know it'll be annoying for you but that reduces bandwidth and
doesn't centralize all the compression/decompression CPU into the server.

*but*, if you want to go the server route, it'd probably be easiest for
you to take the engine-pu branch (the 1.6 tree) and write a storage engine
that compresses its values. Then you don't have to mess with it as much.

Since I've been messing with the locks in the 1.4 tree, that code now has
the potential do things like compression/decompression outside of any
locks. Which means you could have memcached potentially use all cores in a
box while doing server side compression.

Those changes haven't been ported forward, but in all likelyhood the
performance of the current 1.6 tree is more than you need already. Give it
a look?

Re: Data compression

2012-04-13 Thread dormando

 Thank you for your advice. I will have a look at the 1.6 branch.

 May I ask you, however, to share more details about new storage engine
 implementation? Where to look at, what (interface) must be
 implemented? May the new engine be built on the top of an already
 existing (a default) one?

If you search the mailing list archives and the wiki you'll find a bunch
of discussion on it. Possibly the quickest way to learn is to just look at
the code. The default slab engine is implemented as a storage engine in
the 1.6 tree. Since it's a simple engine you can learn how it interacts
with the interface.

Re: documentation

2012-04-10 Thread dormando

Hey,

I do, for the most part. If you'd like to help keep the clients list up to
date I'd love to have the assistance.

E-mail me privately with your google account and I'll add your access.

I had to disable wiki comments since many were spams or people asking for
help in places where nobody would ever see it. :/

On Thu, 5 Apr 2012, Bluejack wrote:


 Question:
 Who keeps the documentation current on the wiki? I was hoping to add a client 
 to the clients list, but cannot even add a comment there. Would be glad to 
 chip in and
 clean up some of that wiki if you would like help with documentation.

 -bluejack

 --
 ---
 Work as though you live in the younger days of a better nation.
 ~~ Dennis Lee
 ---

Re: Possible BUG in expire time in 3.0.6 with PHP 5.4.0?

2012-03-28 Thread dormando

(24 * 60 * 60) == 86400 (a day)

* 5 == 432000

20736000 / 86400 == 240 (days)

expiration times over 30 days are treated as an absolute unix timestamp.

240 days == sometime late in 1970, which is in the past, so the item
immediately expires.

On Wed, 28 Mar 2012, StormByte wrote:

 I've manually ran memcached with -vvv to see what actually happens
 because with older version my code worked good and it does not work
 now (not hitting cache never).
 So I discovered the problem: By default, in my class, I setup the
 expire time in 20736000 which is 5 days in seconds.
 With that value, I always see -nuked by expire in output despite it is
 recently created!

 I discovered that lowering the value, it works indeed, for example
 9000 seconds and it then works:
  FOUND KEY AccountData:3
 28 sending key AccountData:3
 28 END

 So does it lowered its limits in expire option (or indide memcached
 code?)
 Any hint to have greater expire times?

 Thank you

Re: A larger list of sites using memcached?

2012-03-28 Thread dormando

 Hi,

 The memcached website links to a couple of top users of memcached.

 Is there a more comprehensive list of sites using memcached.

It's probably still safe to say that most popular websites use or have
used a form of memcached. It's rare to hit a website which doesn't use it
at some point.

Re: Design Question

2012-03-26 Thread dormando

 I am looking at using memchached for caching blob objects and flush them 
 after a while. My use case is that users may save lots of times and instead
 of persisting every save I would save the data only at logical point to the 
 database or if there was no activity for n seconds then read from
 memcached and flush it to the database. Can someone please give me pointers 
 on how to design this scenario? For instance how to efficiently sync
 memcached with database such that it takes care of stale data, flushing every 
 n seconds etc.

Old blog post on the subject:

http://www.dormando.me/articles/memcached_sessions/

Re: proble while starting memcached service

2012-03-23 Thread dormando

You might want to send this over to the mysql cluster folks. It seems to
be a problem with the ndb_engine, which we don't support directly.

On Wed, 21 Mar 2012, deepak m wrote:

 hi

 i am getting an error while starting memcached 1.6 beta service

 like

 [root@cent2 ~]# /usr/local/mysql/bin/memcached -E /usr/local/mysql/lib/
 ndb_engine.so -e connectstring=10.12.200.117:1186;role=db-
 only;debug=true -vv -u root -c 11
 main -- ndb_initialize()
 main print_debug_startup_info():   sizeof Ndb   : 144
 main print_debug_startup_info():   sizeof NdbInstance   : 64
 main print_debug_startup_info():   sizeof workitem  : 136
 main print_debug_startup_info():   sizeof ExternalValue : 96
 main -- connect_to_primary_cluster()
 22-Mar-2012 10:18:27 IST NDB Memcache 5.5.19-ndb-7.2.4 started [NDB
 7.2.4; MySQL 5.5.19]
 Contacting primary management server (10.12.200.117:1186) ...
 main -- ClusterConnectionPool::connect()
 Connected to 10.12.200.117:1186 as node id 5.
 main -- Configuration::fetch_meta_record()
 main get_supported_version(): 1.2
 main -- config_v1::read_configuration()
 main get_server_role_id(): Name: db-only -- ID: 1
 main -- config_v1::get_policies()
 main get_policies(): ndb-test:  get-2 set-2 del-2 flush-2
 addr-0x9d9fb20
 main get_policies(): caching-with-local-deletes:  get-3 set-3 del-1
 flush-1 addr-0x9d99a60
 main get_policies(): ndb-read-only:  get-2 set-4 del-4 flush-1
 addr-0x9d7bbb8
 main get_policies(): ndb-only:  get-2 set-2 del-2 flush-1
 addr-0x9d75878
 main get_policies(): caching:  get-3 set-3 del-3 flush-1
 addr-0x9da0120
 main get_policies(): memcache-only:  get-1 set-1 del-1 flush-1
 addr-0x9d7f798
 main -- config_v1::get_connections()
 main -- store_connection_pool_for_cluster()
 main get_connections(): [0]:  { 0 = 10.12.200.117 [rtt: 250]}
 main get_connections(): clusters: 1
 main -- config_v1::get_prefixes()
 main QueryPlan(): Using Index: PRIMARY on Table: key_prefixes [SCAN]
 main get_container_record(): demo_table found in database
 (demo_table).
 main get_container_record(): demo_ext found in database
 (demo_table_large).
 main get_container_record(): demo_tabs found in database
 (demo_table_tabs).
 main -- config_v1::log_signon()
 main set_initial_cas(): Sign On GCI: 0x95f70012 | Node Id: [5]
 0x5000 | Engine bit: 0x10
 main set_initial_cas(): Initial CAS: 5276488924397568 0x12bef05000
 main -- config_v1 destructor()
 Retrieved 3 key prefixes for server role db-only.
 The default behavior is that:
 GET uses NDB only
 SET uses NDB only
 DELETE uses NDB only.
 The 2 explicitly defined key prefixes are b: (demo_table_large) and
 t: (demo_table_tabs)
 main -- Configuration::openAllConnections()
 main -- ClusterConnectionPool::connect()
 open_connections_to_all_clusters() failed
 main -- ndb_destroy()
 Segmentation fault



 can any one help me out in finding solution for this


 thanks in adv
 Deepak M

Re: confused about the slab_automove_decision function~

2012-03-22 Thread dormando

 hello，recently i read the memcached code of version 1.4.13.When i read
 about the function of slab_automove_decision,i feel confused about
 it,can you explain the main idea for me and tell me
 something about the local variables like slab_winner and so on?Thank
 you~my english is pool,if you
 can not understand  what i describe,please tell me.I'm glad to accept
 your reply。


There's a perl script in the source repo: scripts/mc_slab_mover. This
implements the same algorithm as inside the C server. It has full
documentation at the top and the code may be easier to follow.

Re: Patch for PEEK command?

2012-03-21 Thread dormando

 I'm thinking about implementing a PEEK command.  It turns out that on
 large payloads ( = 1MB) it would be advantageous to know if the data
 already exists before doing all the work to create the data.  I would
 like to solicited some feedback before I dive into it.

 - Is there already a way to check for the existence of a key before
 fetching the data?  If so, then I would like to know how to do so and
 not waste my time.

 - I was thinking this would be more-or-less a clone of item_get() as
 item_peek() except it returns 1 or 0 to the user instead of the
 payload.

 Thoughts?

Just do a 0 byte add with an expiration time in the past. If the add
succeeds, the item wasn't already there.

For bonus points, you could add with a 5 second timeout, then use set to
overwrite your key. So two processes would serialize on the add call.

touch could probably be used as well.

Re: contribution preferred practices

2012-03-14 Thread dormando

 Is there any documentation or examples on-line describing preferred
 form, method and criteria for offering contributions to the memcached
 project?  My group at work has a number of significant performance
 improvements - some generic, some platform-specific #ifdef - we'd like
 to offer.  However, we'd like to do so in a way that minimizes thrash,
 maximizes utility, assures upward compatibility and provides easily-
 incorporated value.

Best way is to make those changes as small as possible, as well documented
as possible, and have a lot of patience.

We don't have a lot of resources for merging patches, so it could take a
while. We could also end up matching your ideas with new ones that may
work better more generically.

So putting up a git repo somewhere and describing the patchset work well.
From there it's up to you, but sending something to the mailing list is a
requirement.

Also keep in mind that we're presently trying to reconcile the 1.6 tree,
so it's difficult to tell where changes should go (1.4 or 1.6).

-Dormando

Re: How to start contribute to memcached

2012-03-09 Thread dormando

You can submit patches to 1.6 or 1.4 or both.

There isn't really a tutorial. You can look through the commit history to
see how we do things.

On Sat, 10 Mar 2012, 陈 宗志 wrote:

 As I have read all the memcached code. I want to contirbute some codes to 
 memcached. which version should I start? 1.6? I think I need fix some
 small bugs first. 
 Is there a tutorial?
 --
 Blog: http://www.chenzongzhi.info
 Twitter: https://twitter.com/baotiao
 Git: https://github.com/baotiao

Re: Experiences with libevent2 on memcached-1.4.0?

2012-03-09 Thread dormando

 Hi memcached,
 I'm upgrading libevent-1.3a to libevent-2.0.17-stable in our library 
 distribution. Memcached-1.4.0 is one of the packages that relies on libevent
 and I'm trying to catch regressions, if any.

 The basic tests (make test) complete successfully. Before I upgrade our 
 libraries: Did anyone experienced issues with memcached-1.4.0 using
 libevent2+ in production?

I've seen a few folks using libevent2+ in production, and nobody's
complained so far. Some of our test builders are using it as well.

Question though; are you specifically talking about version *1.4.0*, or
the *1.4 series*? 1.4.0 is extremely old and extremely bug laden on its
own.

Re: [Urgent]Memcached on MPSoC

2012-03-04 Thread dormando

 I'm currently working to port memcached to MPSoCs, related to some
 project which use memcahed as benchmark. I have some questions, it
 would be great if you give your views on this,
 a) do you think, is it worth to port memcached to MPSoC which have low
 memory and cache? Do you have any ideas for memcached for embedded
 applications?

Not sure? what's the use case? memcached might be usable if you have many
different devices and need a clever way to share a cache. if you're using
memcached locally on a machine, never accessing it over the network,
that's a huge waste.

 b) how does memcached behaves on single server scenario? Is it just
 like hash table or more than that?

http://memcached.org/tutorial - brains are all in the client, one server
or ten the server itself doesn't care. If you're intending on solely using
it via localhost that's probably a bad idea. just use an LRU library to
deal better with your limited resources.

Re: elapse time for set command ?

2012-02-28 Thread dormando

 On Tue, Feb 28, 2012 at 10:02 AM, Wendy Cheng s.wendy.ch...@gmail.com wrote:
  On Tue, Feb 28, 2012 at 9:47 AM, Wendy Cheng s.wendy.ch...@gmail.com 
  wrote:
  Does anyone have a ballpark number for memslap --server name
  --test=set command ? Somehow I got ~0.6 seconds that is surprising.
  Intuitively, our network round-trip latency for 16K tcp data is less
  than 0.001 second. I expected the memslap set command would not go
  up to msec range (?). Our lab machines are 8-cpu+2926.412 mhz+12GB
  memory with 100gb ethernet. All configurations (memcached-1.4.10 +
  libmemcached-1.0.2) use default setting.
 
  We're not in the tuning stage yet but would like to know beforehand if
  this number is expected.
 
 
  Oops .. my bad :) .. memslap runs 1 loops on default .. so one
  single set must run around 0.68 s (68 usec) (?).
 


 To make it clear, we're happy with the number *now*... Too bad that I
 can' t recall this post. Sorry for the interruption !

You might want to consider mc-crusher as well.
https://github.com/dormando/mc-crusher

it's still rough, but from what it can do it's very flexible.

Re: Issue 256 in memcached: PLEASE do not remove cachedump, better dumping feature needed

 Thanks for the response, i believe it won't work. First i have many
 items of different sizes, so i can't get them to one slab, having 2
 clients would be a performance hit because i'd need to make
 connections twice every request (unfortunately the part that handles
 SQL write stagging is reading/writing some cache data too)

You don't/can't use persistent connections?

 But pulling the full list of keys back so you can find and fast reclaim some 
 is definitely the wrong way to do that
 Why it's wrong? Maybe we can pull the items inside memcached and then
 call item_lock=do_item_unlink=do_item_remove=item_unlock

 If we managed to fork the client every minute we won't have to use
 locking and it probably won't use too much memory too. If it won't be
 possible maybe we could lock one slab (not whole slab class) and just
 process a copy so we can have some inexpensive garbage collection. LRU
 is very lightweight (yes i get the point of not having long lasting
 LOCKs) but not suitable for all use patterns, because it can miss keys
 then you have uncontrolled slab growth and then you need to restart
 (well from my experience it does most of the time when you start to
 have different expiration times). Eg. last time (before using this
 PULL_LIST-CALL_GET method i had 20 million keys in cache, and all
 slabs in 3 classes now i have about 20-30k).
.
 Maybe we could even get rid of all the code that does garbage
 collection and LRU if we just make LRU to be on-slab-cleanup instead
 of on-item-access? (eg. every 10 seconds we'd process all items from
 LRU slab from top to bottom, then move the slab to bottom of LRU
 list). This maybe would allow to have just one-way list instead of 2
 way list and play better with CPU cache, so be more memory efficient.
 I have read the code for about 1 hour or two so probably most of my
 assumptions are wrong. Can anyone suggest most efficient way of making
 fast reclaim?

No, we're not doing that.

 For now im thinking about forking to be honest... i know 2GB lost is
 not much memory but with current LRU approach i can't see any metrics
 on how much memory i need to keep the thing using memcached running
 and even if i use only about 30-40MB of those 2GB for not-expired
 items i still get evictions.

 If we have this kind of garbage collection would you include this into
 the client? Don't know if I'll be able to do this or if there's anyone
 willing to help with this?

 Easiest thing would be probably just increase the LRU keys scanned to
 eg. 10k but it'll probably just kill the server :)

We will never do anything like that. ever. I don't understand why people
constantly suggest that we add feature that will screw up latency as a
workaround for the fact that they can't use persistent connections or come
up with some sort of minor workaround.

Everything is O(1) always, locking for a long scan is forbidden. The worst
we do is in slab rebalance, which holds a slab logically and glances at it
with tiny locks.

The idea I was playing with (which needs time for me to get to and a lot
of testing) is an option to split the LRU per-slab. With the option
enabled each slab class ends up with 3 LRU's, one for short expiration,
one for long, and one for infinite (maybe four LRU's, this is in process
of being thought about! I don't know yet!). Memcached then would use some
algorithm to determine what expiration time classifies as short or
long for the traffic it's seeing, and would sort them.

Then, on allocation it would check the bottom of each for an expired item.

I was also playing with the idea of LRU lurkers which walk up through
the list with tiny locks, but that's tricky to do well and is constantly
interrupting with mostly pointless small locks which can impact latency.

If you're going to insist that you need to do it your own bizarre way, I'd
suggest you check out the 1.6 beta (or engine-pu tree on github) and
write your own storage engine. That should be the easiest method for you.

Re: Issue 256 in memcached: PLEASE do not remove cachedump, better dumping feature needed

  LOCKs) but not suitable for all use patterns, because it can miss keys
  then you have uncontrolled slab growth and then you need to restart

btw, 1.4.11+ can rebalance the slabs if you enable the feature. so you
don't need to restart it in that case.

Re: Issue 256 in memcached: PLEASE do not remove cachedump, better dumping feature needed

 For the running multiple copies... im using persistent connection
 but are you sure the amount of TCP communication will be good for
 performance.

have you tested it? you're making an awful lot of assumptions and seem to
be really itching to go modify some core code and deploy it. Why not
*test* the simplest ideas first and move on when you have to?

 I mean even locking the whole slab that has 1mb and
 scanning it? Will it take more than 1 ms on modern machine? Beside
 it's complicated to rewrite application like this.

If you're blocking the daemon at all, you're causing anything that would
be running in parallel to block for that 1ms. For really low request rates
that's fine, but we must support much more than that.

 @Dormando... why you call it bizzare? :) Rebalancing slabs shouldn't
 be much different.

Because it's a corner case, and your solution is to do a *ton* of work. So
much so that it walks into another corner case itself; someone with a 192G
cache with 100 million entries that are all *valid*, would end up
constantly locking/unlocking the cache while never invalidating anything.
Your tradeoff is to just move the corner case to another area, my
complaint is that it's not sufficiently generic for us to ship.

 What you think about forking the app? (i mean forking the in-memory
 process). Should work well on modern kernel without locking because
 you have copy-on-write? Maybe locking then copying the whole single
 slab? I can allocate some buffer, which will be size of single slab
 then use LOCK, copy ONE slab into the buffer and use another thread to
 build a list of items we can remove. Copying eg. 1 mb of memory should
 happen in no time.

I had some test code which memcpy'd about 2k of memory 5 times per second
while holding a stats lock, and that cut the top throughput by at least
5%. The impact was worse than that, since the test code had removed dozens
of (uncontsted) mutex lock calls and replaced them with the tiny memcpy.

 Generally you think i should move the cleanup into storage engine? How
 advanced is that (production ready?)

  The worst we do is in slab rebalance, which holds a slab logically and 
  glances at it
  with tiny locks.
 The good thing about cleanup is that you won't have to use tiny locks
 (i think). Just lock the slab, copy memory and then wake up some
 thread to take a look, add the keys to some list then just process the
 list from time to time  (or am i wrong?)

 Can you give me some pointers please?

 for now im seeing you're using:
 it = heads[slabs_clsid];
 then iterate it = it-next;

 that's probably why you say it's too slow... but what if we just
 lock=copy one slab's memory=unlock=analyze slab=[make 100 get
 requsts=sleep]repeat? We have fixed size items in slab so we know
 exactly where the key and expiration time is, right?

I tried to explain the method I'd been thinking of for doing this most
efficiently, but you seem to be ignoring that. There's just no way in hell
we'll ever ship something that issues requests against itself or forks or
copies memory around to scan them.

Here are some reasons, and then even more alternatives (since your request
rate is really low):

1) the most common use case has a mix of reads and writes, not as much
writes and then batch reads (which you're doing). Which means common keys
with a 5 second expiration would get fetched and expired more naturally.
everything else would fall through the bottom due to disuse.

2) tossing huge chunks of memory around then issuing mass fetches back
against itself doesn't test well. Issuing more locks doesn't test well
(especially on NUMA; contesting locks or copying memory around causes
cacheline flushes, pipeline stalls, cross-cpu memory barriers, etc). I've
tested this, copying 1mb of memory is not fast enough for us, if I can't
even copy 2k without impacting performance.

3) Issuing extraneous micro locks or scanning does terrible things to
large instances for the above reasons. If your traffic pattern *isn't*
your particular corner case, everything else gets slower.

You could also ship a copy of all your short-expiration SET's to syslog,
and have a daemon tailing the syslog and issuing gets as things expire...
then you don't need to block the daemon at all but you're still issuing
all those extra gets.

but, again, if you're really attached to doing it your way, go ahead and
use the engine-pu branch. In a few months memcached will do this better
anyway, and I don't agree with the method you're insisting on. I see too
many alternatives that have the potential to work far better.

Re: Issue 256 in memcached: PLEASE do not remove cachedump, better dumping feature needed

 No i haven't tested using 2 instances... for now i have it resolved
 using just DUMP/GET... which is not so good in my opinion too (but
 works and isn't affecting performance for my small instance) so... im
 trying to find some better way. Short-expire list seem good, maybe
 this will work... Rewriting the app to use 2 instances is not an
 option for me because staging data has (in many cases) same length as
 normal cache data, so i'd have to check all calls to memcached in the
 whole code.

grep your code for short expiration times, add a key prefix for those,
extend your client with set/get calls that route to the real client
based on key prefix? (then optioanlly remove the key prefix before
sending, to shave some bytes). Shouldn't have to rewrite the application
code if you can change the client out from under it.

 For many assumptions, I have to make assumptions and ask someone with
 greater experience because i have no time to implement / test
 everything because unfortunately i can't devote much time to working
 with memcached code (and there are too many possible resolutions to
 the problem... that'll probably won't work) :)

Your above reasoning is a better start than shrugging off the idea. I
always try to push for the most flexible, simplest method first.

 So i think that if you said that everything i thought about won't
 work... i'll just do a quick patch and modify dump to return only
 expired items using smaller buffer... should be a little (not much, i
 know) better. Or maybe implement short-expire list in syslog if i have
 more time.

Syslog one sounds pretty easy.

 Btw: how large instances you're running (and how many req/s)? You said
 you'll keep 3 or more LRUs in new version, any other improvements?

Lots of ideas, on a roughly monthly release cycle. See the release notes
page on our wiki for the slow crawl; but I don't have a real roadmap at
the moment.

 I see too many alternatives that have the potential to work far better.
 Can you talk about some more, that's interesting

Those were the examples I gave already; syslog, extend the client, write a
storage engine with an internal LRU split. I'm sure I could come up with
more but I have other things to think about right now :P

 On 26 Lut, 21:31, dormando dorma...@rydia.net wrote:
   For the running multiple copies... im using persistent connection
   but are you sure the amount of TCP communication will be good for
   performance.
 
  have you tested it? you're making an awful lot of assumptions and seem to
  be really itching to go modify some core code and deploy it. Why not
  *test* the simplest ideas first and move on when you have to?
 
   I mean even locking the whole slab that has 1mb and
   scanning it? Will it take more than 1 ms on modern machine? Beside
   it's complicated to rewrite application like this.
 
  If you're blocking the daemon at all, you're causing anything that would
  be running in parallel to block for that 1ms. For really low request rates
  that's fine, but we must support much more than that.
 
   @Dormando... why you call it bizzare? :) Rebalancing slabs shouldn't
   be much different.
 
  Because it's a corner case, and your solution is to do a *ton* of work. So
  much so that it walks into another corner case itself; someone with a 192G
  cache with 100 million entries that are all *valid*, would end up
  constantly locking/unlocking the cache while never invalidating anything.
  Your tradeoff is to just move the corner case to another area, my
  complaint is that it's not sufficiently generic for us to ship.
 
   What you think about forking the app? (i mean forking the in-memory
   process). Should work well on modern kernel without locking because
   you have copy-on-write? Maybe locking then copying the whole single
   slab? I can allocate some buffer, which will be size of single slab
   then use LOCK, copy ONE slab into the buffer and use another thread to
   build a list of items we can remove. Copying eg. 1 mb of memory should
   happen in no time.
 
  I had some test code which memcpy'd about 2k of memory 5 times per second
  while holding a stats lock, and that cut the top throughput by at least
  5%. The impact was worse than that, since the test code had removed dozens
  of (uncontsted) mutex lock calls and replaced them with the tiny memcpy.
 
 
 
 
 
 
 
 
 
   Generally you think i should move the cleanup into storage engine? How
   advanced is that (production ready?)
 
The worst we do is in slab rebalance, which holds a slab logically and 
glances at it
with tiny locks.
   The good thing about cleanup is that you won't have to use tiny locks
   (i think). Just lock the slab, copy memory and then wake up some
   thread to take a look, add the keys to some list then just process the
   list from time to time  (or am i wrong?)
 
   Can you give me some pointers please?
 
   for now im seeing you're using:
   it = heads[slabs_clsid];
   then iterate it = it-next

Re: Issue 256 in memcached: PLEASE do not remove cachedump, better dumping feature needed

  Btw: how large instances you're running (and how many req/s)? You said
  you'll keep 3 or more LRUs in new version, any other improvements?

Also uh, I didn't mean to ignore that question, but I'm not at liberty to
divulge hard numbers. They're large enough and hit hard enough to continue
to justify our obsession with performance.

Re: Stable release 1.4.11

2012-02-22 Thread dormando

 @dormando, those are default CFLAGS for different RHEL platforms:

 4 - i386-O2 -g -march=i386 -mcpu=i686
 4 - x86_64  -O2 -g

 5 - i386-O2 -g -march=i386 -mtune=i686
 5 - x86_64  -O2 -g -m64 -mtune=generic

 6 - i386-O2 -g -march=i386 -mtune=i686
 6 - x86_64  -O2 -g

I'm not sure what you're telling me here.

I'm confused at how ./configure  make works, but building it via RPM
doesn't. what is RPM changing?


 BTW, I'm getting random make tests with .13 on i386 platforms, the offender
 is:

 (..)
 ok 10 - strtoul
 ok 11 - strtoull
 testapp: testapp.c:397: start_server: Assertion `fgets(buffer, sizeof(buffer),
 fp) != ((void *)0)' failed.

 As I said, it happens randomly, let me know if you need anything else.

That's not new to .13. that's been there for a few years. it's just a
stupid race condition in the test itself, which will be fixed in the next
cut. doesn't affect the daemon at all.

Re: Stable release 1.4.11

2012-02-21 Thread dormando

  * RHEL-4 (GCC 3.4.6), on both 32 and 64 bits:
  thread.c:98: warning: implicit declaration of function
  `__sync_sub_and_fetch'
 
  * RHEL-5 (GCC 4.1.2) fails only on 32 bits:
  thread.c:83: undefined reference to `__sync_add_and_fetch_2'

 @dormando, building RPM package for memcached 1.4.13 with default rpmmacros
 options fails on RHEL-5 + i386 with same error:

 thread.c:83: undefined reference to `__sync_add_and_fetch_2'

 The ofender is -march=i386 flag exported via CFLAGS, I have fixed with
 something like this:

 # memcached 1.4.13 build fails on RHEL-5 + i386, offender is march gcc flag =
 s/i386/i686
 %ifarch %ix86
%if 0%{?rhel} == 5
   CFLAGS='-O2 -g -march=i686 -mtune=i686'
   export CFLAGS
%endif
 %endif

 This doesn't happen with other memcached versions.. and with .13 only occurs
 on RHEL-5 + i386 platform, FYI.

That's really confusing. It shouldn't be possible for configure and make
to disagree on that... is RPM passing in different CFLAGS to each?

I know it builds find outside of rpm on that platform.. we have a builder
now.

Re: memcached failing

2012-02-09 Thread dormando

I'm not sure why you don't think it's functioning. I see the server
starting, then a *get* but no *sets*. Your mystery is probably in your
application setup somehow. You're probably swallowing some errors that
could be useful, or things aren't quite as synced up as you believe they
are.

And I don't care if the code is synced up or not, I'm curious as to what
your client configuration is for memcached. What is the *exact* server
list you're passing to the clients? Is it just localhost, a cluster, or
...?

On Wed, 8 Feb 2012, Kevin Wincott wrote:

 hi

 thanks for the replies,  I inherited this from a previous developer so please
 accept my apologies for lack of details.

 this was the entire log from when I started the server, the setup stores
 session data between the 3 servers, producing a load balancing effect. the
 code is stored on a central server and is mounted via NFS to the 3 web
 servers, the code works fine on the other 2 so it must be related to memcached
 on this particular server, however, the same version is in use as on all the
 other servers, and this was working and suddenly broke :(


 On 07/02/12 23:37, dormando wrote:
   hi
  
   we are using memcached 1.4.5_2 on 3 servers, each server has the same
   version of all software installed. on two servers memcached is working
   perfectly, however on the 3rd if doesnt work, it appears to not return
   any data, the sql connection is working fine and the code we are using
   is OK as it is shared via NFS to all 3 servers, here is a sample of
   when we try to use memcache:
  
   host# /usr/local/bin/memcached -vv -d -u nobody
   host# slab class   1: chunk size80 perslab   13107
  [snip]
   20 new auto-negotiating client connection
   20: Client using the ascii protocol
   20 get sqlassoc:5770ee132150b6fca3b63c477c9fb12a
20 END
   20 connection closed.
  
   can anyone point me in a direction of where to go next to fix the
   issue
  Was this your *entire* log after starting the server? It looks as though
  you've just sent a 'get' without ever putting data into it via 'set's
  first.
 
  I'm suspicious of your configuration as well. Are all 3 of your servers
  supposed to be using one local memcached instance, or are you configuring
  it as a proper cluster, with all 3 memcached instances listed in the
  client configurations?

Re: decr on Int64.MaxValue fails with CLIENT_ERROR cannot increment or decrement non-numeric value

 Here's the repro on the largest unsigned 64-bit integer
 18446744073709551615 with telnet on memcached 1.4.5

 set aad2ac07-2fd5-42bb-88b9-e7bae3b55f5b 0 200 20
 18446744073709551615
 STORED
 get aad2ac07-2fd5-42bb-88b9-e7bae3b55f5b
 VALUE aad2ac07-2fd5-42bb-88b9-e7bae3b55f5b 0 20
 18446744073709551615
 END
 decr aad2ac07-2fd5-42bb-88b9-e7bae3b55f5b 100
 CLIENT_ERROR cannot increment or decrement non-numeric value


 Is this a known bug?


The max is 18446744073709551614 - as per strtoull(3) I guess.

Re: decr on Int64.MaxValue fails with CLIENT_ERROR cannot increment or decrement non-numeric value

What's your platform?

Escape character is '^]'.
version
VERSION 1.4.5
set foo 0 0 20
18446744073709551614
STORED
decr foo 5
18446744073709551609

fwiw, always report bugs against latest versions of software :P

like I said, it's just calling strtoull(3) internally, so it's whatever
that function likes on your platform.

On Tue, 7 Feb 2012, Sean wrote:

 See my second post. Even 9223372036854775809 won't work.
 9223372036854775807 works.

 On Feb 7, 1:38 pm, dormando dorma...@rydia.net wrote:
   Here's the repro on the largest unsigned 64-bit integer
   18446744073709551615 with telnet on memcached 1.4.5
 
   set aad2ac07-2fd5-42bb-88b9-e7bae3b55f5b 0 200 20
   18446744073709551615
   STORED
   get aad2ac07-2fd5-42bb-88b9-e7bae3b55f5b
   VALUE aad2ac07-2fd5-42bb-88b9-e7bae3b55f5b 0 20
   18446744073709551615
   END
   decr aad2ac07-2fd5-42bb-88b9-e7bae3b55f5b 100
   CLIENT_ERROR cannot increment or decrement non-numeric value
 
   Is this a known bug?
 
  The max is 18446744073709551614 - as per strtoull(3) I guess.

Re: decr on Int64.MaxValue fails with CLIENT_ERROR cannot increment or decrement non-numeric value

set aad2ac07-2fd5-42bb-88b9-e7bae3b55f5b 0 200 20
18446744073709551614
STORED
decr aad2ac07-2fd5-42bb-88b9-e7bae3b55f5b 5
18446744073709551609

Unfortunately we don't really support the windows builds... they're
unofficial, and we have no way of troubleshooting or updating them :/

On Tue, 7 Feb 2012, Sean wrote:

 If the key length is small, it works fine on my machine too:
 set mykey 0 2000 20
 18446744073709551614
 STORED
 decr mykey 5
 18446744073709551609


 However, when I change to use GUID as the cache key, it doesn't work
 on numbers greater than 2^63-1:

 set aad2ac07-2fd5-42bb-88b9-e7bae3b55f5b 0 200 20
 18446744073709551614
 STORED
 get aad2ac07-2fd5-42bb-88b9-e7bae3b55f5b
 VALUE aad2ac07-2fd5-42bb-88b9-e7bae3b55f5b 0 20
 18446744073709551614
 END
 decr aad2ac07-2fd5-42bb-88b9-e7bae3b55f5b 5
 CLIENT_ERROR cannot increment or decrement non-numeric value

 On Feb 7, 1:58 pm, Sean sean.y@gmail.com wrote:
  version 1.4.5_4_gaa7839e on windows 2008 R2 64-bit
 
  On Feb 7, 1:46 pm, dormando dorma...@rydia.net wrote:
 
 
 
 
 
 
 
   What's your platform?
 
   Escape character is '^]'.
   version
   VERSION 1.4.5
   set foo 0 0 20
   18446744073709551614
   STORED
   decr foo 5
   18446744073709551609
 
   fwiw, always report bugs against latest versions of software :P
 
   like I said, it's just calling strtoull(3) internally, so it's whatever
   that function likes on your platform.
 
   On Tue, 7 Feb 2012, Sean wrote:
See my second post. Even 9223372036854775809 won't work.
9223372036854775807 works.
 
On Feb 7, 1:38ï¿½pm, dormando dorma...@rydia.net wrote:
  Here's the repro on the largest unsigned 64-bit integer
  18446744073709551615 with telnet on memcached 1.4.5
 
  set aad2ac07-2fd5-42bb-88b9-e7bae3b55f5b 0 200 20
  18446744073709551615
  STORED
  get aad2ac07-2fd5-42bb-88b9-e7bae3b55f5b
  VALUE aad2ac07-2fd5-42bb-88b9-e7bae3b55f5b 0 20
  18446744073709551615
  END
  decr aad2ac07-2fd5-42bb-88b9-e7bae3b55f5b 100
  CLIENT_ERROR cannot increment or decrement non-numeric value
 
  Is this a known bug?
 
 The max is 18446744073709551614 - as per strtoull(3) I guess.

Re: memcached failing

 hi

 we are using memcached 1.4.5_2 on 3 servers, each server has the same
 version of all software installed. on two servers memcached is working
 perfectly, however on the 3rd if doesnt work, it appears to not return
 any data, the sql connection is working fine and the code we are using
 is OK as it is shared via NFS to all 3 servers, here is a sample of
 when we try to use memcache:

 host# /usr/local/bin/memcached -vv -d -u nobody
 host# slab class   1: chunk size80 perslab   13107
[snip]
 20 new auto-negotiating client connection
 20: Client using the ascii protocol
 20 get sqlassoc:5770ee132150b6fca3b63c477c9fb12a
 20 END
 20 connection closed.

 can anyone point me in a direction of where to go next to fix the
 issue

Was this your *entire* log after starting the server? It looks as though
you've just sent a 'get' without ever putting data into it via 'set's
first.

I'm suspicious of your configuration as well. Are all 3 of your servers
supposed to be using one local memcached instance, or are you configuring
it as a proper cluster, with all 3 memcached instances listed in the
client configurations?

Re: Seeking approval to use Memcached Logo on a poster with other logos

2012-02-02 Thread dormando

 Hey dormando,
 I'm a developer at Chatham Financial, and we're big fans of memcached.

 I was wondering if my company can use the logo for a poster at
 recruiting events.

 The idea is that we want to showcase at a glance some of the software/
 programs that we work with every day - hence displaying the logos
 instead just listing the of names. Memcached would be one of
 (hopefully) 22 other libraries/programs that we'd show the logo for.

 We will specifically note we have no involvement in the creation of
 any of the software or logos that we're using, and that using the
 logos is either okay by a license or written agreement.

 I'm posting from my personal gmail account, but if you need me to
 email from my company email account, then let me know (it's not hooked
 up to Google Groups).

Neat!

Well, I didn't have individual logo's to hand out before. We sorta do now:

http://memcached.org/images/memcached_link_125.png
http://memcached.org/images/memcached_link_100.png

I also have a larger one if necessary.

From your usage it sounds okay, so count this as approval under the terms
you've stated, thank you for asking!

The big issue we had have been companies listing product compatibility
along with the logo, or issuing PR about something something memcached
something. Users would be confused and think that the company was a
contributor or owner.

Company would say that they never explicitly said that nor hinted at it;
however while a business might be used to clever legal maneuvering or
wording to get their way, I do not give a flying fuck. Here are the fucks
I do not give about:

- we did not explicitly say we just used the logo because etc
- we did not say but we stood in your booth with nametags stating our
company
- that's heresay

So if you wish to use these logos, please ask permission and try to not be
full of shit! I watch twitter and I talk to users and it confuses the hell
out of them.

have fun,
-Dormando

memcached 1.4.12

2012-02-01 Thread dormando

Hey,

1.4.11 had some trouble building on a few platforms, and some bugs were
reported in in the meantime. 1.4.12 fixes almost all of these reported
issues.

No new features for now, just bugfixes. Thanks and sorry for the trouble.

have fun,
-Dormando

Re: how to update all values as a daily task with memcached efficiently?

2012-01-30 Thread dormando

 hi all,the problem is like this:There are 10 millions of key/values  in 
 memcached,and it requires to update all the values at 00:00 every  day. 
 For example,it is a daily task,the value data can not be accumulated .so it 
 should clear up the old data value at a fixed time every day.

 Is there any efficient method to handle this problem ? 

 THX for your advise.

Call flush on all the servers at 00:00. all the values are immediately
invalidated.

Re: Cache expiry oddness

2012-01-27 Thread dormando

 We're having some issues with retrieving cached keys from our
 memcached server.

 Tested different data with expiry times of 30s, 120s, and 600s - the
 test was: try to get the data three times in quick succession.

 Obviously, we're expecting the first one from db but then the next two
 should could from the cache.

 On our test local server (win box running couchbase's memcache),
 that's what happened. On our live server (running debian  memcached),
 it failed for 30s  120s, but worked for 600.

 The only things changed in the config on the live box were the
 listening port and the memory cap.

 Just wondering if anyone has any ideas as to why this could be
 happening?

What version of memcached? You could have clock skew, which was repaired
to use a monotonic clock in 1.4.7-ish. Try upgrading to the latest and see
if you still have issues.

MODERATION MADNESS

2012-01-27 Thread dormando

Hello Danga-Projecter-ers!

Many fancy apologies to those who may see this message four times!

I have come to the realization that Google Groups moderation queue is
fucking garbage! It often doesn't send me moderation notices when someone
hits the queue, or if someone is queued I don't get the e-mail once it's
unqueued, and I often have to find new moderators every few months or I
have to unqueue them myself, which is boring.

Wow, that's a long sentence!

I haven't seen much spam hit the moderation queues in a while. I have
delinked each group from googles giant group listing, in hopes of culling
groups-specific spammers. I have disabled the moderation queue for new
users, but still require users register before sending messages.

Lets see how well this works.

G'awd!
-Dormando

Re: Stable release 1.4.11

2012-01-26 Thread dormando

 El 18/01/12 19:04, dormando escribió:

   Closer... Can you try the attached patch against 1.4.11? could've sworn
   I'd tested the other path, but I guess not :(
  
   I added some prints at the bottom that should print something to STDERR
   when started in the foreground:
  
   $ ./memcached
   USING GCC ATOMICS
  
   Any chance you could give me the output from each of your platforms as
   well as the build test results? I'm a little worried that rhel-6 i386
   should be using real atomics, but I haven't figured that out for sure yet.
  Also, are you running 'make test' on these platforms? I'm curious if 'make
  test' actually passes on all of the 32bit machines.

 @dormando, results after applying your last patch:

 - build works on RHEL-{4,5,6} both i386 and x86_64 :)

 - RHEL 4 and 5 return emulated atomics and RHEL-6 gcc atomics

 - make test finish OK in all x86_64 servers, but on i386 t/slabs_reassign
 fails on all RHEL releases, outputs:

 * RHEL-4 = https://gist.github.com/1639453
 * RHEL-5 = https://gist.github.com/1639368
 * RHEL-6 = https://gist.github.com/1639412

 I have also removed t/whitespace.t because I was getting this error and Git is
 installed in all servers:

 fatal: not a git repository
 all skipped: skipping tests probably because you don't have git.

 Let me know if you need to test anything else.. and thanks for your help! :)

Is that t/whitespace.t thing actually stopping the build/compile/etc?
Saying that it skipped tests is informational. That fatal: is probably
git printing something on STDERR.

Anyway; for those of you following at home, we've been committing fixes to
the tree: https://github.com/memcached/memcached

We may be ready for 1.4.12 tonight, or maybe tomorrow. I'm not sure yet.
If you've had build trouble please grab the git tree and give it a go.

-Dormando

Re: Stable release 1.4.11

2012-01-26 Thread dormando

 Today Jan 18, 2012 at 09:51 dormando wrote:

   b) i386 = manual compilation works, but a I'm getting an error 
   building
   the RPM package, it might be related with gcc flags, I'm working on it..
   rpmbuild error output:
  
   https://gist.github.com/1632139
 
  Closer... Can you try the attached patch against 1.4.11? could've sworn
  I'd tested the other path, but I guess not :(

   Now it can be compiled and works even on old FreeBSD 6.2 i386 gcc 3.4.6
   With previous one it hangs after few minutes of use.

while I can't say I'm *glad* that something so old continues to live on
modern software, I guess that's cool.

we'll be adding builders for freebsd, but I hadn't been intending on going
that old :)

Re: A bug in do_item_alloc?

2012-01-20 Thread dormando

 Is there any guarantee that search is not NULL on Line 133? I think if
 Line 107 is true and takes the branch on Line 108, there is nothing
 between there and Line 133 that sets the value for search. So, if
 slabs_alloc fails to allocate memory in all the instances and it
 remains NULL, we can end up dereference a NULL pointer on Line 133.

 Feedback is appreciated. Many thanks in advance.
 \

This was fixed in 1.4.11, sorry :( I fixed it over a month ago but didn't
do an intermediate release.

Re: Stable release 1.4.11

2012-01-19 Thread dormando

 @dormando, results after applying your last patch:

Thank you!

 - build works on RHEL-{4,5,6} both i386 and x86_64 :)

 - RHEL 4 and 5 return emulated atomics and RHEL-6 gcc atomics

Even RHEL5 64bit says emulated atomics ? That shouldn't be :/ I did a
build test on a centos5 host and it seems to be finding gcc atomics.

 - make test finish OK in all x86_64 servers, but on i386 t/slabs_reassign
 fails on all RHEL releases, outputs:

 * RHEL-4 = https://gist.github.com/1639453
 * RHEL-5 = https://gist.github.com/1639368
 * RHEL-6 = https://gist.github.com/1639412

I'd found and fixed this yesterday:
https://github.com/memcached/memcached/commit/97354c326c931ca535e681e8fe3fcd53ff1b4927

 I have also removed t/whitespace.t because I was getting this error and Git is
 installed in all servers:

 fatal: not a git repository
 all skipped: skipping tests probably because you don't have git.

Does that actually fail the test, or just print that it's skipping them?

 Let me know if you need to test anything else.. and thanks for your help! :)

I guess I'll have to do one more patch round... is there any chance I
could get brief access to one of those machines? I don't have any RHEL
guys available, just the centos 64bit and that seems to work correctly.

RHEL5's supposed to have those atomics, and seemed to work under 64bit
before my latest patch, so I want to try a bit harder.

Thank you!
-Dormando

SCALE

2012-01-19 Thread dormando

Yo all,

I'll be speaking at SCALE (http://socallinuxexpo.org/) on saturday on the
topic of modern memcached - underused existing features, and talking
about current and future work on the project.

Re: Stable release 1.4.11

2012-01-18 Thread dormando

 El 17/01/12 21:27, dormando escribió:

   could you please try 1.4.11 with the attached patch on all platforms? I'm
   taking a bit of a guess since google isn't very familiar with this macro.
  
   for bonus points; add an fprintf(stderr, etc) to make sure it's using the
   right path for each.

 Hello @dormando:

 Results after applying your patch to memcached 1.4.11 on different RHEL
 versions:

 - RHEL-4 (gcc 3.4.6) can be compiled without problems on both i386 and x86_64,
 thanks! :)

 - RHEL-5 (gcc 4.1.2) can't built on both i386 + x86_64, with a new error:

 https://gist.github.com/1632081

 - RHEL-6 (gcc 4.4.6):

 a) x86_64 = build without problems

 b) i386 = manual compilation works, but a I'm getting an error building
 the RPM package, it might be related with gcc flags, I'm working on it..
 rpmbuild error output:

 https://gist.github.com/1632139

Closer... Can you try the attached patch against 1.4.11? could've sworn
I'd tested the other path, but I guess not :(

I added some prints at the bottom that should print something to STDERR
when started in the foreground:

$ ./memcached
USING GCC ATOMICS

Any chance you could give me the output from each of your platforms as
well as the build test results? I'm a little worried that rhel-6 i386
should be using real atomics, but I haven't figured that out for sure yet.

Thanks!diff --git a/thread.c b/thread.c
index 5735376..3c90ecb 100644
--- a/thread.c
+++ b/thread.c
@@ -43,7 +43,7 @@ pthread_mutex_t cache_lock;
 /* Connection lock around accepting new connections */
 pthread_mutex_t conn_lock = PTHREAD_MUTEX_INITIALIZER;
 
-#if !defined(__GNUC__)  !defined(__sun)
+#if !defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2)  !defined(__sun)
 pthread_mutex_t atomics_mutex = PTHREAD_MUTEX_INITIALIZER;
 #endif
 
@@ -79,14 +79,14 @@ static pthread_cond_t init_cond;
 static void thread_libevent_process(int fd, short which, void *arg);
 
 inline unsigned short refcount_incr(unsigned short *refcount) {
-#ifdef __GNUC__
+#ifdef __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2
 return __sync_add_and_fetch(refcount, 1);
 #elif defined(__sun)
 return atomic_inc_ushort_nv(refcount);
 #else
 unsigned short res;
 mutex_lock(atomics_mutex);
-*refcount++;
+(*refcount)++;
 res = *refcount;
 pthread_mutex_unlock(atomics_mutex);
 return res;
@@ -94,14 +94,14 @@ inline unsigned short refcount_incr(unsigned short *refcount) {
 }
 
 inline unsigned short refcount_decr(unsigned short *refcount) {
-#ifdef __GNUC__
+#ifdef __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2
 return __sync_sub_and_fetch(refcount, 1);
 #elif defined(__sun)
 return atomic_dec_ushort_nv(refcount);
 #else
 unsigned short res;
 mutex_lock(atomics_mutex);
-*refcount--;
+(*refcount)--;
 res = *refcount;
 pthread_mutex_unlock(atomics_mutex);
 return res;
@@ -665,6 +665,14 @@ void thread_init(int nthreads, struct event_base *main_base) {
 int i;
 int power;
 
+#ifdef __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2
+fprintf(stderr, USING GCC ATOMICS\n);
+#elif defined(__sun)
+fprintf(stderr, USING SUN ATOMICS\n);
+#else
+fprintf(stderr, USING EMULATED ATOMICS\n);
+#endif
+
 pthread_mutex_init(cache_lock, NULL);
 pthread_mutex_init(stats_lock, NULL);

Re: Stable release 1.4.11

2012-01-18 Thread dormando

  El 17/01/12 21:27, dormando escribió:
 
could you please try 1.4.11 with the attached patch on all platforms? 
I'm
taking a bit of a guess since google isn't very familiar with this 
macro.
   
for bonus points; add an fprintf(stderr, etc) to make sure it's using 
the
right path for each.
 
  Hello @dormando:
 
  Results after applying your patch to memcached 1.4.11 on different RHEL
  versions:
 
  - RHEL-4 (gcc 3.4.6) can be compiled without problems on both i386 and 
  x86_64,
  thanks! :)
 
  - RHEL-5 (gcc 4.1.2) can't built on both i386 + x86_64, with a new error:
 
  https://gist.github.com/1632081
 
  - RHEL-6 (gcc 4.4.6):
 
  a) x86_64 = build without problems
 
  b) i386 = manual compilation works, but a I'm getting an error 
  building
  the RPM package, it might be related with gcc flags, I'm working on it..
  rpmbuild error output:
 
  https://gist.github.com/1632139

 Closer... Can you try the attached patch against 1.4.11? could've sworn
 I'd tested the other path, but I guess not :(

 I added some prints at the bottom that should print something to STDERR
 when started in the foreground:

 $ ./memcached
 USING GCC ATOMICS

 Any chance you could give me the output from each of your platforms as
 well as the build test results? I'm a little worried that rhel-6 i386
 should be using real atomics, but I haven't figured that out for sure yet.

Also, are you running 'make test' on these platforms? I'm curious if 'make
test' actually passes on all of the 32bit machines.

Re: Stable release 1.4.11

2012-01-17 Thread dormando

 El 17/01/12 06:36, dormando escribió:

  http://code.google.com/p/memcached/wiki/ReleaseNotes1411

 We're having problems building this release with old GCC versions, for
 example:

 * RHEL-4 (GCC 3.4.6), on both 32 and 64 bits:
 thread.c:98: warning: implicit declaration of function `__sync_sub_and_fetch'

 * RHEL-5 (GCC 4.1.2) fails only on 32 bits:
 thread.c:83: undefined reference to `__sync_add_and_fetch_2'

That sucks. Was hoping rhel5's gcc was new enough, but it seems to be
missing the sync for shorts.

 * RHEL-6 (GCC 4.4.6) build OK on 32/64 bits

 * Lenny (GCC 4.3.2) and Squeeze (GCC 4.4.5-8) build whithout problems (only
 tested with amd64 boxes)

 Full compilation output is available here:

 https://gist.github.com/1626073

Guess I'll adjust the definer. Was really hoping someone would toss the
-rc through... It just needs to fall back to the pthread one. I'll get on
that shortly.

Re: Stable release 1.4.11

2012-01-17 Thread dormando

 El 17/01/12 06:36, dormando escribió:

  http://code.google.com/p/memcached/wiki/ReleaseNotes1411

 We're having problems building this release with old GCC versions, for
 example:

 * RHEL-4 (GCC 3.4.6), on both 32 and 64 bits:
 thread.c:98: warning: implicit declaration of function `__sync_sub_and_fetch'

 * RHEL-5 (GCC 4.1.2) fails only on 32 bits:
 thread.c:83: undefined reference to `__sync_add_and_fetch_2'

ok so... centos5 + gcc 4.1.2 doesn't fail to compile on 64bit. you're
saying it's 32bit builds only?

I wish 32bit would go die :/

Re: Stable release 1.4.11

2012-01-17 Thread dormando

  El 17/01/12 06:36, dormando escribió:
 
   http://code.google.com/p/memcached/wiki/ReleaseNotes1411
 
  We're having problems building this release with old GCC versions, for
  example:
 
  * RHEL-4 (GCC 3.4.6), on both 32 and 64 bits:
  thread.c:98: warning: implicit declaration of function 
  `__sync_sub_and_fetch'
 
  * RHEL-5 (GCC 4.1.2) fails only on 32 bits:
  thread.c:83: undefined reference to `__sync_add_and_fetch_2'

 ok so... centos5 + gcc 4.1.2 doesn't fail to compile on 64bit. you're
 saying it's 32bit builds only?

 I wish 32bit would go die :/

could you please try 1.4.11 with the attached patch on all platforms? I'm
taking a bit of a guess since google isn't very familiar with this macro.

for bonus points; add an fprintf(stderr, etc) to make sure it's using the
right path for each.diff --git a/thread.c b/thread.c
index 5735376..4fdc3da 100644
--- a/thread.c
+++ b/thread.c
@@ -43,7 +43,7 @@ pthread_mutex_t cache_lock;
 /* Connection lock around accepting new connections */
 pthread_mutex_t conn_lock = PTHREAD_MUTEX_INITIALIZER;
 
-#if !defined(__GNUC__)  !defined(__sun)
+#if !defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2)  !defined(__sun)
 pthread_mutex_t atomics_mutex = PTHREAD_MUTEX_INITIALIZER;
 #endif
 
@@ -79,7 +79,7 @@ static pthread_cond_t init_cond;
 static void thread_libevent_process(int fd, short which, void *arg);
 
 inline unsigned short refcount_incr(unsigned short *refcount) {
-#ifdef __GNUC__
+#ifdef __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2
 return __sync_add_and_fetch(refcount, 1);
 #elif defined(__sun)
 return atomic_inc_ushort_nv(refcount);
@@ -94,7 +94,7 @@ inline unsigned short refcount_incr(unsigned short *refcount) {
 }
 
 inline unsigned short refcount_decr(unsigned short *refcount) {
-#ifdef __GNUC__
+#ifdef __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2
 return __sync_sub_and_fetch(refcount, 1);
 #elif defined(__sun)
 return atomic_dec_ushort_nv(refcount);

Stable release 1.4.11

2012-01-16 Thread dormando

http://code.google.com/p/memcached/wiki/ReleaseNotes1411

^ All info is above. If you're on 1.4.10, you should highly consider
upgrading. If you want to start memcached and not hardly ever restart it,
consider learning the new slab reassign options :)

About a month late, given the holidays and some complications with getting
slab reassign to work.

have fun,
-Dormando

1.4.11-rc1

2012-01-11 Thread dormando

http://code.google.com/p/memcached/wiki/ReleaseNotes1411rc1

Tossed in a few more fixes from the issue tracker, punting on the rest for
1.4.12 since this is so late.

I'm going to leave this up for another day or two while I work on the wiki
a bit and try to come up with other tests. Slab rebalancing has been a
desired feature for a long time; please give it a look-see! It was a pain
in the ass to write!

Re: SERVER_ERROR out of memory storing object with memcached 1.4.10

2012-01-09 Thread dormando

 El 09/01/12 06:12, dormando escribió:

  Hey, could you please try to reproduce the issue with 1.4.11-beta1:
  http://code.google.com/p/memcached/wiki/ReleaseNotes1411beta1
 
  I've closed the logic issues and fixed a few other things besides. Would
  be very good to know if you're still able to bug it out.
 
  Thanks!
  -Dormando

 Using 1.4.11-beta1 I can't reproduce out of memory storing object error,
 thanks!

Awesome! Thanks for verifying so quickly. I'll try to wrap this up into an
-rc1 today. Hoping some other people try it too :)

Re: Storage Engine ?

2012-01-09 Thread dormando

 There are archived discussions floating around about this subject,
 particularly with SSD. Are there open source works (implementation,
 src code, interface description, etc) available for people to take a
 look ?

There is a working and well used engine implementation in the engine-pu
branch:
https://github.com/memcached/memcached/tree/engine-pu

There's also a download on the google code site of an older beta release
of 1.6.0. Included in the source tree is the default engine, which should
serve as a good example. Others exist if you google around.

Re: Memcached allocation errors

2012-01-08 Thread dormando

 I just upgraded to 1.4.10 from 1.4.5. In 1.4.5 we used a unix socket
 instead of tcp, and memcached would crash as soon as a single
 Couldn't realloc input buffer error ocurred.

 The server has plenty of memory and is monitored by nagios which
 doesn't show any oddities at the time of the crashes. The only thing
 that worries me is that openvz might have something to do with it?
 Although with these generous limits and few connections I can't think
 of anything.

 Taking a quick look at the source code at the realloc error message
 shows that it's a buffer used to read from a connection to the
 memcached. It doubles this buffer in size whenever not enough memory
 is available to read data from the connection. It starts at 2K. I
 cannot imagine that any connection could have so much data going over
 it that this would ever be a problem?? Very strange.. maybe I should
 add extra debugging info there displaying the amount of memory it
 tried to allocate.

 For now I have just made sure that all the objects do have an expiry
 time set so that it should never hit full capacity. I'll update here
 if this at least solves the crashing / protocol / memory errors.

Can you try the 1.4.11-beta1 cut:
http://code.google.com/p/memcached/wiki/ReleaseNotes1411beta1

I closed a few bugs related to 1.4.10. Would be very interested to see if
you still have issues with it, and what the exact errors are.

If you could get it to crash under gdb and get a backtrace as well, that's
major bonus points.

Thanks, and sorry,
-Dormando

Re: SERVER_ERROR out of memory storing object with memcached 1.4.10

2012-01-08 Thread dormando

 dormando, with a new script setting a random exptime I can reproduce the
 problem in a fresh memcached 1.4.10 (it doesn't happen with earlier versions):

 https://gist.github.com/1564556

 With the first evictions memcached starts reporting SERVER_ERROR out of
 memory storing object. Those are the -default- settings that I'm using:

 [snip]

 Making a diff with 1.4.9 it seems that is something related with
 do_item_alloc()..

Hey, could you please try to reproduce the issue with 1.4.11-beta1:
http://code.google.com/p/memcached/wiki/ReleaseNotes1411beta1

I've closed the logic issues and fixed a few other things besides. Would
be very good to know if you're still able to bug it out.

Thanks!
-Dormando

Re: SERVER_ERROR out of memory storing object with memcached 1.4.10

2012-01-05 Thread dormando

 El 05/01/12 12:00, Santi Saez escribió:
  Making a diff with 1.4.9 it seems that is something related with
  do_item_alloc()..
 More information:

 - reverting remove the depth search from item_alloc commit solves the
 problem:

 https://github.com/memcached/memcached/commit/ca5016c54111e062c771d20fcc4662400713c634

 - using exptime=0 it doesn't happen.

I probably fixed this a few weeks ago in my branch, but I'm still wringing
the bugs from it. If you can hold on for a few days for the beta and test
that when I post it, it should be better.

Thanks!
-Dormando

Re: Memcached allocation errors

2012-01-05 Thread dormando

 We're using memcached to cache content generated by another
 application on the same server. Items that are cached are set to never
 expire, as the application currently self decides when it will refresh
 items already in the cache.

 We run memcache with verbose output, and I occasionally see these one
 or more entries in stderr:

 Couldn't realloc input buffer

 Sometimes, the memcached process will disappear, though I am not
 seeing anything about that in the stderr/stdout output, other than the
 message above. Sometimes there can be multiple realloc error messages
 in stderr with memcached still running.

 It would appear that these issues only start creeping up once memcache
 has reached its full capacity and starts evicting old entries. by
 then, pyblibmc (which uses libmemcached) also occasionally produces
 these errors:

 ProtocolError: error 8 from memcached_set: PROTOCOL
 ERROR
 WriteError: error 5 from memcached_set: WRITE
 FAILURE

 Restarting memcached will stop the flow of errors until its full
 capacity has been reached.

 We run memcached as follows:

 memcached -v -l 127.0.0.1:11211 -d -m 1024 -c 2000 -P /home/user/var/
 run/memcached.pid

 We're running version 1.4.10 on a debian lenny virtual server (OpenVZ)
 on a RedHat 5.4 host (all 32-bits)

 Memcached is run with ulimit -v 3145728 and ulimit -n 2048

 On average, it has only about 10 active connections. Stats output (of
 an instance that is currently showing these errors):

Can you try 1.4.9? You may also be low on system memory. If downgrading
doesn't work, reduce the memory limit from -m

Re: SERVER_ERROR out of memory storing object with memcached 1.4.10

2011-12-30 Thread dormando

 Hello,

 After 3 weeks with memcached 1.4.10 in production, today we have start
 getting randomly this error:

 SERVER_ERROR out of memory storing object with memcached

 I can reproduce it with a simple set+get loop, this is the Python
 script that I have used (running the script from 6 different servers
 it takes ~20 minutes to occur again):

 http://pastie.org/3096017

What client is this script written for, exactly?

By 6 different servers you mean you're running 6 copies of that script
from 6 places, or even more?

 It runs with standard libevent package from Debian (version 1.4.13),
 custom kernel (Linux 2.6.32.41), multiport support (32 x -l flag),
 with -m 42000 (the servers has 48G) and -t 8 threads (same # of
 cores).

Any other startup options? (or just list `stats settings` as well)

 SLAB, item, and general stats are also available on:

 http://pastie.org/3096085

 The server is out of production and we haven't flushed it yet, so if
 you want we can test whatever you want! :)

Now that you've left it out for a while, can you try storing a few things
again and snapshot the items/slabs stats? I'm curious to see if the
tailrepairs counter goes up at all.

Re: benchmarking memcached / low performance

2011-12-14 Thread dormando

 Dormando,

 What exactly do you mean by stack? Do you mean buffering?

 I've tried a few options from libmemcached: buffering and no_reply.
 Both of them seem to make things much much faster.

 With buffering it does 150k/s with no_reply ~750k/s. So it seems
 memcached itself is lightning fast it's just the TCP roundtrip slowing
 it down.

It's not going to go faster than the roundtrip, and given your numbers
that roundtrip is already really low. I mean to run two of your tests at
the same time, in parallel. The mc-crusher benchmark actually iterates
through many connections so it doesn't have to wait for roundtrips.

Unless your application *needs* to run a single thread and hit memcached
in a loop without issuing multigets or multisets (no_reply), your test
won't represent reality anyway. In most cases you have multiple procs on
many application servers hitting it in parallel.

Re: recommended maximum number of nodes in memcache cluster (server pool)

2011-12-08 Thread dormando

 @dormando, great response this is almost exctly what i had in mind, i.e. 
 grouping all of your memcached servers into logical pools so as to
 avoid hitting all of them for every request. infact, a reasonable design, for 
 a very large server installation base, would be to aim for say 10-20%
 node hit for every request (or even less if u can manage it).

  so with the facebook example, we know there's a point you get to where a 
 high node count means all sorts of problems, in this case, it was 800, i
 think (correct me if am wrong) proving the point that logical groupings 
 should be the way to go for large pools -- infact i would suggest groupings
 with varying canopies of granularity as long as your app kept a simple and 
 clear means by which to zap down to a small cross section of servers
 without losing any  intended benefits of caching in the fisrt place..

 in short, most of my anxities have been well addressed (both theoretical and 
 practical)... 

 +1 for posting this in a wiki Dormando.

http://code.google.com/p/memcached/wiki/NewPerformance added to the bottom
of this wiki page... tried to summarize the notes better, but speak up
with edits if something's missing or unclear.

Re: incr command does not update expiration

2011-12-07 Thread dormando

 Hi,

 I'm developing some applications using memcached and I saw that the
 incr operation does not update the key's expiration, requiring the
 usage of get + set if I want to update the expiration.

 Is there a special reason to this behavior?

It's more flexible if that's the default. you can use touch to
periodically extend the expiration if necessary. Since memcached is an LRU
you can simply set the expiration time to something reasonable and let
unused keys get pushed out as they would otherwise.

With fixed expiration times you can do things like rate limits that
automatically roll over every minute, etc.

Re: caching primitives useful in common scenarios

2011-12-06 Thread dormando

 I'm surprised how little I can find on this topic... references to the
 stampeding problem (which is resolved by using get_locked) are about
 all the info I can find. Sorry in advance if i'm missing some earlier
 discussion - i've searched quite a bit and can't find anything about
 it.

 Are people interested in a patch?  It really doesn't seem too hard...


This is actually a decent summary on it:
http://code.google.com/p/memcached/wiki/NewProgrammingTricks#Avoiding_stampeding_herd

The add lock + soft timeout is the best, since blocking sucks hard. If you
must block, Gearman's generally tbe best approach since it has
broadcast-response without adding the complexity into memcached.

I've seen a number of get/lock/etc implementations to do something like
this but none of them feel very complete. Blocking is wrong, add does an
extra roundtrip, etc. I did hear a promising idea recently, and we'll talk
about it more once I have time to go over the full details.

For the meantime you should pick one of the methods above and go nuts :)
They work well enough, without polling, and you don't have to modify
anything that you or we'll have to support forever.

Re: Key can it have a . character

2011-11-30 Thread dormando

Keys can have any characters except newlines or spaces while using the
ASCII protocol. If using the binary protocol exclusively there's no limit
to what, just the length (250 bytes)

On Wed, 30 Nov 2011, Siddharth Jagtiani wrote:

 Can it be -613748077 ?

 On Wed, Nov 30, 2011 at 1:57 PM, smallfish smallfish...@gmail.com wrote:
   yes. only key length must less then 250 bytes.
   --blog: http://chenxiaoyu.org



 On Wed, Nov 30, 2011 at 4:15 PM, MCON Dev mcon...@gmail.com wrote:
   Quick Question, can the key have a '.' (dot) character ?
 Conny

Re: recommended maximum number of nodes in memcache cluster (server pool)

2011-11-27 Thread dormando

 But which client? Usually if you need memcache to scale you will be
 running many clients in parallel - and if they are doing single-key
 operations in many cases adding more servers will make them completely
 separate.   It is only multi-gets with many small keys that don't
 scale forever.

If you enable persistent conns, you'll build up tons of connections (one
per memd per client process). If you don't use persistent conns, but
access memcached several times during a request, the odds of having to do
a 3-way handshake before every request increases.

 Yes, it is more a matter of using smart clients.  But still, you are
 likely to have a problem with your backend persistent storage before
 you get to that point - especially if you expect to recover from any
 major failure that dumps most of your cache at once.

Yes :) Reality trumps most of these issues in a few ways; keeping up with
your backing store is one. Another decent reality is that if you have an
installation that large, odds are you can afford specialists who can
ensure it continues to work.

Re: recommended maximum number of nodes in memcache cluster (server pool)

2011-11-26 Thread dormando

 @Les, you make a clear and concise point. thnx.

 In this thread, i'm really keen on exploring a theoretical possibility (that 
 could become very practical for very large installations):

     -- at what node count (for a given pool) may/could we start to experience 
 problems related to performance  (server, network or even client)
 assuming a near perfect hardware/network set-up?

I think the really basic theoretical response is:

- If your request will easily fit in the TCP send buffer and immediately
transfer out the network card, it's best if it hits a single server.
- If your requests are large, you can get lower latency responses by not
waiting on the TCP socket.
- Then there's some fiddling in the middle.
- Each time a client runs send that's a syscall, so more do suck, but
keep in mind the above tradeoff: A little system cpu time vs waiting for
TCP Ack's.

In reality it doesn't tend to matter that much. The point of my response
to the facebook multiget hole is that you can tell clients to group keys
to specific or subsets of servers, (like all keys related to a particular
user), so you can have a massive pool and still generally avoid contacting
all of them on every request.

     -- if a memcacached client were to pool say, 2,000 or 20,000 connections 
 (again, theoretical but not entirely impractical given the rate of
 internet growth), wud that not inject enough overhead -- connection or 
 otherwise -- on the client side to, say, warrant a direct fetch from the
 database? in such a case, we wud have established a *theoretical* maximum 
 number nodes in a pool for that given client in near perfect conditions.

The theory depends on your setup, of course:

- Accessing the server hash takes no time (it's a hash), calculating it
is the time consuming one. We've seen clients misbehave and seriously slow
things down by recalculating a consistent hash on every request. So long
as you're internally caching the continuum the lookups are free.

- Established TCP sockets mostly just waste RAM, but don't generally slow
things down. So for a client server, you can calculate the # of memcached
instances * number of apache procs or whatever * the amount of memory
overhead per TCP socket compared to the amount of RAM in the box and
there's your limit. If you're using persistent connections.

- If you decide to not use persistent connections, and design your
application so satisfying a page read would hit at *most* something like 3
memcached instances, you can go much higher. Tune the servers for
TIME_WAIT reuse, higher local ports, etc, which deals with the TCP churn.
Connections are established on first use, then reused until the end of the
request, so the TCP SYN/ACK cycle for 1-3 (or even more) instances won't
add up to much. Pretending you can have an infinite number of servers on
the same L2 segment you would likely be limited purely by bandwidth, or
the amount of memory required to load the consistent hash for clients.
Probably tens of thousands.

- Or use UDP, if your data is tiny and you tune the fuck out of it.
Typically it doesn't seem to be much faster, but I may get a boost out of
it with some new linux syscalls.

- Or (Matt/Dustin correct me if I'm wrong) you use a client design like
spymemcached. The memcached binary protocol can actually allow many client
instances to use the same server connections. Each client stacks commands
in the TCP sockets like a queue (you could even theoretically add a few
more connections if you block too long waiting for space), then they get
responses routed to them off the same socket. This means you can use
persistent connections, and generally have one socket per server instance
for an entire app server. Many thousands should scale okay.

- Remember Moore's law does grow computers very quickly. Maybe not as fast
as the internet, but ten years ago you would have 100 megabit 2G ram
memcached instances and need an awful lot of them. Right now 10ge is
dropping in price, 100G+ RAM servers are more affordable, and the industry
is already looking toward higher network rates. So as your company grows,
you get opportunities to cut the instance count every few years.

     -- also, i wud think the hashing algo wud deteriorate after a given 
 number of nodes.. admittedly, this number could be very large indeed and
 also, i  know this is unlikely in probably 99.999% of cases but it wud be 
 great to factor in the maths behind science.

I sorta answered this above. Should put this into a wiki page I guess...

-Dormando

Re: No Expiry of data

2011-11-23 Thread dormando

Just specify 0 and it won't expire.

On Wed, 23 Nov 2011, Siddharth Jagtiani wrote:

 I noticed exp is int, not uint. So I wonder if I give -1 will it consider no 
 expiry :).
 Siddharth

 On Wed, Nov 23, 2011 at 4:25 PM, Siddharth Jagtiani 
 jagtiani.siddha...@gmail.com wrote:
   Hi,
 I am wondering if there is a way to set no expiry for objects in the cache. 
 I understand the fact that under stress, cache may expiry and
 kick out objects, in situations like low memory. But in principle I would 
 like to setup a no expiry cache. 

 I searched in the doc's but did not find anything that resembled no expiry 
 setting.

 Please advice
 Siddharth

Re: Basic Question - Multiple values with the same key

2011-11-22 Thread dormando

 Well, if I need to put another object in the collection, I need to first get 
 it the existing object from the cache. And then insert this new object
 within that collection. Reducing performance by that much. But I understand 
 that perf will not drop considerably since a get is much faster, and its
 only 1 more get for every put. 
 If memcached would provide such a feature, it would have to manage a 
 collection instead of a value. And allow a api to insert duplicate. And 
 fetch
 a collection instead of a object. Much faster than the former approach above.

 Ok, let me ask this question (sorry if Im being lame here, just point me to 
 the doc's if I missed something). Is there a way to define a set (or
 region as it would be on microsoft velocity) ?

You should read through the wiki: http://memcached.org/wiki - there're
some programming sections with examples. Using namespacing is probably
similar to what you're talking about with regions.

If you're managing a list, you may also be able to use the append and/or
prepend commands to stack sets of bytes without re-fetching the object.

Re: Basic Question - Multiple values with the same key

2011-11-22 Thread dormando

 Dormando,Quick question.

 So if I were to 
 put (key, array_of_size_3)
 and then
 append (key, new_item)

 value = get (key)
 size of value will be 4 ?

if array_of_size_3 is 3 bytes, and new_item is 1 byte, then yes.
remember that if you're appending complex structures, you still need to be
able to parse what you get back.

Re: memcache hits max_connections then dies

2011-11-21 Thread dormando

 I am running memcache on an Amazon EC2 large instance (7.5GB RAM, 64 bit, 
 high i/o, etc).  Is there a way to compute the optimum amount of
 storage space and number of connections?  I ask because I am right now using 
 a pulled-out-of-thin-air startup of:
 /usr/bin/memcached -d -r -u nobody -m 7000 -c 4096

 When we get enough (I'm not sure what enough is exactly - either max 
 connections or close to it), memcache stops responding entirely.  You
 try to telnet to port 11211 and it just hangs.  I have to reboot the box when 
 this happens.  Obviously sub-optimal.

How are you verifying this situation? The *box* is hung or memcached is
hung? Is the box swapping, if you can get in can you kill memcached and
restart it, etc?

 Is this expected behavior?  I would have hoped to just get a quick 
 connection refused, instead it gums up the connecting apache processes
 for a long time, which is not good.  Even better, I would like to find some 
 way to avoid running out of connections.  If I can only get 3000
 connections with this configuration then so be it, I'll just add more nodes.  
 Would really like to know for sure one way or the other
 though.

No... If you have to reboot the box legitimately, you're probably just
swapping and need to lower the max memory limit. -m 6500 or whatever.

A lot of other things are discussed here: http://memcached.org/timeouts

If it turns out you're just hitting maxconns; try increasing -c further
(perhaps also lowering -m by a few megs), or try the new -o
maxconns_fast option in 1.4.9+, which immediately rejects conns over the
limit.

-Dormando

Re: Basic Question - Multiple values with the same key

2011-11-21 Thread dormando

 Hi All,
 My scenario needs me to retrieve multiple objects that have the same key. 
 Infact my scenario needs me to identify objects using multiple keys too,
 but I can solve the multiple keys problem by adding one more entry to 
 memcached. So thats not my question. Is it possible to store multiple values
 using the same key ?

 A parallel caching technology is Velocity 
 http://msdn.microsoft.com/en-us/magazine/dd861287.aspx;. Here we can create 
 something called regions,
 within a cache instance. And I can split my data between regions. So that I 
 dont need to store multiple values using the same key. I can just create
 regions, and every region can host my unique data.

 I also referred to 
 http://stackoverflow.com/questions/1049833/multi-valued-hashtable-in-java;. 
 I think its possible in java. But wondering if there
 is a parallel in memcached (or should I do it the hard way/slower way, store 
 a map as value, get, add, set).

Collections aren't supported. Your options are to pack multiple values
into a single key (Not sure why this is an issue? If you're fetching it
all back anyway...), or to give them different keys and issue multigets to
fetch item collections back.

It's really never an issue in practice. If so I'd like to see benchmarks
or code showing otherwise :/ Unless there's some specific feature about
collections that you're looking for.

Re: 1.4.10 is out

2011-11-10 Thread dormando

Thanks, as always!

On Wed, 9 Nov 2011, Paul Lindner wrote:

 Fedora RPMs up for testing.  This release looks nce!

 On Wed, Nov 9, 2011 at 5:00 PM, dormando dorma...@rydia.net wrote:
   Hey,

   http://code.google.com/p/memcached/wiki/ReleaseNotes1410

   See release notes or code for more information. I would be surprised if
   any decent host would top out before overloading its network card. This
   one is a beast.

   -Dormando




 --
 Paul Lindner -- lind...@inuus.com -- linkedin.com/in/plindner

1.4.10 is out

2011-11-09 Thread dormando

Hey,

http://code.google.com/p/memcached/wiki/ReleaseNotes1410

See release notes or code for more information. I would be surprised if
any decent host would top out before overloading its network card. This
one is a beast.

-Dormando

Re: interested in re-purposing slabs.c

2011-10-26 Thread dormando

  It still has a weakness of not being able to reassign memory if you put it
  all into one slab class pool.

 I have 16 fixed sizes (ranging from 1K-6K, all slightly irregular size
 [e.g. 1028 bytes]), so I will use the slab allocator every time I need
 one of these fixed sizes. So I will have 16 different slab-classes
 (unsure of terminology) and there may be minimal overhead (possibly
 1MB per slab-class that is underunused) but I can live w/ that.

 Are my assumptions correct?

If you change the slabs_init routine to presize your exact slab classes,
that'll work. Keep in mind that the slab allocator doesn't handle
re-allocating memory across slabs. Once memory is given to a slab class,
that's it.

Re: how do I not store the keys?

 There's nothing like that currently.  Last discussion I remember is that
 we decided against allowing binary keys at the client because we don't
 know what other clients may expect when trying to get that item.

 We can certainly reconsider that, but it's not been needed thus far.

What the hell? I thought 50% of the whole point of the binary protocol was
to make binary keys possible. It's a flag in most other clients. You know,
like, that whole utf8 argument? Are you absolutely sure about this?

 I might ask, are you doing sha1/md5 because you really need the sum of
 something, or are you doing it to simplify what you use for your key?

He's trying to reduce the bytes of the item to the absolute minimum.

Re: how do I not store the keys?

 Calm down.  It clearly wasn't 50% of the use cases given that it's just
 now come up.  :)

It was part of the whole damn point of implementing the protocol. We
wanted three things: binary keys, proper quiet commands, and CAS on
everything. The rest is exactly the fucking same in ASCII. I reserve the
right to be annoyed. So I guess that's 33.3% of the point...

It's also how we advertise and document the damn thing.

 I'm not absolutely sure, but I do remember something about removing it
 and discussing it with Dustin at some point.  I doubt if either of us
 remember the conversation exactly.  Maybe Dustin will pop up and call me
 a liar.  I doubt that though.

 I'd surely take a patch/issue to add a configuration flag to ignore this
 check, but there's not one currently.

 In my personal opinion, I think we should allow binary keys.  It is
 useful.

I hope someone does send in a patch.

Re: how do I not store the keys?

 I'd prefer a flag that I have to _enable_ to have the library verify my
 damn keys. Let the user do what he wants to do and don't expect every
 client user to be a moron. (just like the stupid ubuntu installations that
 adds all sorts of stupid aliases for rm etc).

Most users won't ever know what the protocol is, so they won't know that
spaces or newlines are even a problem until after it's a problem.

Just document the damn flag right; for bonus points have the client spit
back an error that's googleable to a specific response explaining the
situation. Then they can try it, whoops, understand it, and turn it off if
they don't give a fuck.

Damn.

Re: how do I not store the keys?

 I'd prefer a flag that I have to _enable_ to have the library verify my
 damn keys. Let the user do what he wants to do and don't expect every
 client user to be a moron. (just like the stupid ubuntu installations that
 adds all sorts of stupid aliases for rm etc).

(yes, I'm saying users tend to be uninformed; deal with it, we're sorta
mainstream).

Re: how do I not store the keys?

  I'd prefer a flag that I have to _enable_ to have the library verify my
  damn keys. Let the user do what he wants to do and don't expect every
  client user to be a moron. (just like the stupid ubuntu installations
 that
  adds all sorts of stupid aliases for rm etc).
 
 Most users won't ever know what the protocol is, so they won't know that
 spaces or newlines are even a problem until after it's a problem.

 You should probably read the documentation for the client you're using
 before starting to use it in production. It should contain some pointers
 about what's allowed or not. Like a definitions/restrictions on the key
 and value.

 And If they don't, well then its their own fault ;) Why should we optimize
 the code flow for morons ;)

Nobody fucking does that. Get over it, yo. People read the minimum amount
of crap they have to read until it works. Everyone else doesn't have a
hard time finding work.

Also; because when you don't, people switch to to other systems because
they believe it's easier, or they complain in IRC or on the mailing list
and waste my time.

Re: how do I not store the keys?


 Nobody fucking does that. Get over it, yo. People read the minimum amount
 of crap they have to read until it works. Everyone else doesn't have a
 hard time finding work.

 Also; because when you don't, people switch to to other systems because
 they believe it's easier, or they complain in IRC or on the mailing list
 and waste my time.

For what it's worth; on one side of the aisle I have people flaming me
because we don't support utf8 or long keys or binary whatever or CAS on
everything, then on the other side people make shitty defaults or don't
support these things or whatever.

I just wish you guys could whine at each other *directly* instead of at me
on different days.

Re: how do I not store the keys?

   There were strong arguments for keeping keys compatible with both ASCII and 
 binary clients, to the point where it was decided to keep
 parity between the two.

   We can certainly revisit that now, but I don't remember anyone advocating 
 for arbitrary bytes in keys other than asking if we should and
 having someone else say we should keep the same constraints on both sides.  
 (that's from memory, I don't remember who said what, but it made
 sense at the time)

   The client side checking predates the protocol implementations anyway.  We 
 can pull it from the clients and just wait for the server to
 send it back, but there are cases where it'll cause a lot of confusion in the 
 ascii protocol at least since your key can otherwise look like
 a complete request.

Just... add a flag so it can be turned off? It's a sane default, but
hurtful if you ever need blob keys. None of the original clients checked
keys, and that sucked.

Re: how do I not store the keys?

 On Monday, October 24, 2011 10:50:39 PM UTC-4, Dormando wrote:

   Just... add a flag so it can be turned off? It's a sane default, but
   hurtful if you ever need blob keys. None of the original clients checked
   keys, and that sucked.

 Makes sense.  Disable key checking:  can lead to really confusing errors if 
 you don't know what you're doing. 

Cool, cool. Could start by linking to this thing I wrote years ago:
http://code.google.com/p/memcached/wiki/NewProgramming#Short_Keys and we
can continue by expanding it!

Re: how do I not store the keys?

2011-10-23 Thread dormando

 You have to know the key to map it to a server and RAM location, but I
 do not see any reason why you should have to store it.
 The only explanation seems to distinguish values after a hash
 collision, since you can not even iterate over the keys.

I might provide it as an engine at some point, but in order to do that you
have to change the hash table somewhat significantly, and you lose enough
bytes that it's not worth while:

1) you have to expand the hash table size enough so there're generally few
collissions, and when there are you can store in the bucket to the right
of the intended one. Right now I think the hash table is 1/3rd the total
item store size as a performance tradeoff.

2) You have to store the hashed value with the items, so when pulling them
off of the LRU, you can look up their hash table entry and remove them.
Presently we do that by recalculating the hash from the key.

So if your keys are already short it'd be a toss-up for the byte tradeoff.
If you generally have long keys, you should really just hash them in the
client anyway, as that saves you in a lot of other ways :P

 I'm using the binary protocol. The problem is that both md5 and sha1
 return \n, \r and spaces in the key, which leads to this message: Key
 contains invalid characters. Is there any way to use a byte array as
 key instead of a string?

Are you absolutely sure? Which client is this?

With the binary protocol, keys are binary blobs and it doesn't matter
what's in them. There may be an option you have to swith off in the
client, or the client may not actually be using binprot (run memcached
with -vvv to see what it thinks of your connecting clients).

-Dormando

Re: compile failing on test with item_size_max

2011-10-22 Thread dormando

 hello,
 i am trying to install memcached-1.4.9 on Centos 5.7

 i get these errors (the root one is easy) but not sure what i need to
 change for the others

 t/item_size_max.t  1/7 Item max size cannot be less than 1024
 bytes.
 t/item_size_max.t  2/7 Cannot set item size limit higher than 128
 mb.
 t/item_size_max.t  3/7 WARNING: Setting item max size above 1MB is
 not recommended!
  Raising this limit increases the minimum memory requirements
  and will decrease your memory efficiency.
 WARNING: Setting item max size above 1MB is not recommended!
  Raising this limit increases the minimum memory requirements
  and will decrease your memory efficiency.

These are warnings, not actual test failures (the tests would... fail if
so), but they continue).

Re: how do I not store the keys?

2011-10-22 Thread dormando

 I'm trying to cache 1 billion items in memcached, which have a URL
 key.
 The value of one item has 12 bytes (3 integers). However, the key is
 also been stored in memory, which increases the RAM size greatly. I'm
 using a Base64 of a MD5 of a URL, but even so each item is being
 cached in 160 bytes according to the stats sizes command.

 To save space I would like to not cache these keys. I'm willing to
 accept the collision problem of having different items mapped to the
 same entry.

 Is there any way/setup to not store the keys in memcached (or
 membase) ?

We have to know the key in order for the internal hash table to work.

 Is there any way/setup to reduce the waste space of small items like
 these? How can I set a tiny slab size?

A few things:

1) Use binary protocol, and use direct SHA1 (128bit or 256bit) as the key,
which will save a lot of bytes over base64. MD5 is cutting it a bit close.
2) Use -C startup command, which disables CAS and saves 8 bytes per item
3) Compare `stats sizes` with the slab class sizes after storing some test
items, and adjust -f and/or the minimum slab size to get the slabs closer
to ideal.

Should get you a lot closer.

-Dormando

Re: trying to install on CentOS 5.7

2011-10-21 Thread dormando

 [root@events memcached-1.2.8]# rpm -q libevent

just an aside; 1.2.8 is very very old. you should be on 1.4.9 if you're
building yourself.

Re: Protocol V3 proposal

   I don't have the notes from that discussion, but there was the dream of the 
 five byte get

   A byte of magic, a byte of flags describing the parts, a byte of opcode, 
 and a byte of key length, then a key, a

   The flags would include things like quiet, CAS?, keylenlen, etc...

   It's harder to work with, but really tight.

Too much work I think. Variable length length fields are tempting, so
maybe we could attempt an implementation and decide if it's too
slow/annoying/etc. But if not I won't cry too hard. Can still save tons of
bytes by flipping off features via flags.
  
   My only argument is wanting more opcodes.  :)

ok. see below.

   Yeah, that's the problem with packing the stuff tighter.  You have to move 
 stuff around more to get alignment.

If flags are turning 2 byte fields on/off, is something going to explode
if CAS or bodylen just naturally ends up non-4-byte-aligned? I'm honestly
dubious that this matters hugely.

   It didn't look like opaque was required for quiet commands in ASCII.  I 
 think that's the big difference.

Is that a formal requirement already in binprot? I don't think it is?

   I was thinking about this afterwards and it really seems like a good 
 solution is to just have three magics:

   * Request Magic
   * Response Magic
   * Unsolicited Response Magic

   Then you can receive unsolicited responses at any point without having to 
 worry about confusing it with normal responses.  Does this makes sense?

What's the difference between:

- response packet with an unsolicited response
- response packet with a flag and an unsolicited response

?

Would a response packet have an expected opcode, but not be in response to
anything you've done? Or would unsolicited responses be made up of
specialized opcodes?

If you move the quiet flag back into the magic byte, there're no more bits
for an unsolicated response flag without dropping a second entire byte for
flags.

Re: Protocol V3 proposal



On Wed, 19 Oct 2011, dormando wrote:

    I don't have the notes from that discussion, but there was the dream of 
  the five byte get
 
    A byte of magic, a byte of flags describing the parts, a byte of opcode, 
  and a byte of key length, then a key, a
 
    The flags would include things like quiet, CAS?, keylenlen, etc...
 
    It's harder to work with, but really tight.

Double responding again...

V3 binprot proposal does:

A magic flag byte, opcode byte, 2 bytes of key length, then a. so, five
bytes.

Another thing I'd like to float is that we do sorta lose the ability to
version protocols if I shove the flags into the magic byte :( Another
forceful tradeoff I was thinking about:

1 magic flag byte (req, res, and a 3rd magic for unsolicited v3 res?), 1
flag byte, 1 opcode flag, 1 byte keylen.

Keylen has *never* been longer than 250 bytes. I win every argument
against huge keys by pointing out that it's more efficient to sha1 long
keys in the client than it is to send and store them. Long keys sets the
bar so low that you trip over it.

Given the max key length is 250, we *could* at some point rev the version
again, and enable variable length encoding. Ideally keeping it simpler for
now, and has the same 4 byte minimum as the V3 proposal.

Does feel like a waste of magic bits, but perhaps future-proofing is a
better idea. :/

Re: Protocol V3 proposal

 A magic flag byte, opcode byte, 2 bytes of key length, then a. so, five
 bytes.

 Another thing I'd like to float is that we do sorta lose the ability to
 version protocols if I shove the flags into the magic byte :( Another
 forceful tradeoff I was thinking about:

 1 magic flag byte (req, res, and a 3rd magic for unsolicited v3 res?), 1
 flag byte, 1 opcode flag, 1 byte keylen.

 Keylen has *never* been longer than 250 bytes. I win every argument
 against huge keys by pointing out that it's more efficient to sha1 long
 keys in the client than it is to send and store them. Long keys sets the
 bar so low that you trip over it.

 Given the max key length is 250, we *could* at some point rev the version
 again, and enable variable length encoding. Ideally keeping it simpler for
 now, and has the same 4 byte minimum as the V3 proposal.

 Does feel like a waste of magic bits, but perhaps future-proofing is a
 better idea. :/

Triple responding (there was some discussion on IRC):

http://code.google.com/p/memcached/wiki/ProtocolV3

updated to show:

Required bytes:

Magic byte
Flag byte
Opcode byte
Two byte key length

All other headers are conditional on flags. Shortest possible get
command would be six bytes.

Magic byte:

Magic byte operates the same as binary protocol. New numbers are assigned
for V3, request, response.

Also, maybe a third magic byte value meaning unsolicited response



Also, quiet flag is moved into the new flag byte, and opcode
again has a capacity of 256 commands.

ASCII is unchanged because ASCII don't give a fuck.



Finally, a note; we should really stop lying to users about the key
length. Once this protocol is worked on (or even before), the core engine
needs to be reworked so a startup option will enable long keys.

That startup option should flog you a dozen times first, and force you to
agree that you're doing something very very wrong, but it should work. The
default will forever stay at 250 bytes because it's a good idea, and
increasing the limit may seriously inflate the internal item structure due
to alignment issues, at minimum one byte per item.

-Dormando

Re: Protocol V3 proposal

 On Wednesday, October 19, 2011 2:49:17 PM UTC-7, Dormando wrote:

   That startup option should flog you a dozen times first, and force you 
 to
   agree that you're doing something very very wrong, but it should work. 
 The
   default will forever stay at 250 bytes because it's a good idea, and
   increasing the limit may seriously inflate the internal item structure 
 due
   to alignment issues, at minimum one byte per item.


 But what if I have 
 morethan 7458340731200206743290965315462933837376471534600406894271518333206278385070118304936174890400427803361511603255836101453412728095225302660486
 164829592084691481260792318781377495204074266435262941446554365063914765414217260588507120031686823003222742297563699265350215337206058336516628646
 00361292743355184696865732649900815331989178957883268594741821289062500
 000
 000 items I need to store?  How will I address 
 them?

 (this is in the FAQ, isn't it?)

This reminds me of the old CAS patch. Where I removed the early wrap
detector due to the fact that the sun would have engulfed earth before the
wrap could plausibly occur (without the instance being restarted).

All joking aside; while I am annoyed that I'll likely be the person who
implements it, and it will do nothing but cause harm to people, it's a
little silly to avoid allowing it entirely.

-Dormando

1.4.9 released (NOT the performance release)

Hey,

I'm really sorry this took so long to follow up with. Shortly after
shipping 1.4.8 it was discovered that raising the connection limit had
been broken.

http://code.google.com/p/memcached/wiki/ReleaseNotes149
^ that and a small number of other things have been fixed in 1.4.9. If
you've installed 1.4.8 and ever intend to raise the connection limit above
the default, you should upgrade immediately.

No other major bugs have been reported in the meantime, and I added a few
small notes there.

NOTE; 1.4.9 is *not* what 1.4.9-beta1 was. At this point, 1.4.10 will be
the performance release.

I've pushed over 10 billion requests through what's in the 14perf tree at
rates of over 1.2 million keys/sec sustained. I still have a few important
things to stress test before I mark it final, but that could happen within
the next week.

have fun,
-Dormando

Protocol V3 proposal

yo,

http://code.google.com/p/memcached/wiki/ProtocolV3

I'm going to let this sit for a while before implementing, but here's the
proposal and lets discuss it.

Notes are on the bottom, so please check there before responding. Comments
are also disabled on the wiki because that's what e-mail is for, god
dammit.

I am looking for feedback specifically about *functionality*. I don't give
a flying fuck if it's ugly. I want to know if something's been forgotten,
or if something is impossible, or if something should really *be* possible
that isn't already. If something's going to bite us hard, I want to know
now. It would be nice to not have to do this again for a decade.

ie; compressed binprot now takes more branches to parse into a header
(test for flag, read bytes, subtract from remaining bodylen).

Both sides of V3 are designed to be simple to implement in C, and the
ascii protocol should be trivial to implement in any dynamic language, as
it already is with the ascii protocol.

We may not even do this, who knows. I'd rather have this so I can use it.
Sick of not being able to use binprot features wherever I want.

-Dormando

Re: Protocol V3 proposal

 We had previously talked about an even tighter binary protocol, but perhaps 
 harder to generalize a parser around.  This doesn't seem different
 enough from the existing binary protocol to warrant introducing an 
 incompatibility.

I honestly can't remember what else was removed in our old discussions.
Old man is old. Something about the reserved bytes turning into a longer
flag set maybe? This proposal just drops those bytes.

What I may have mentioned was that uh... size length encoding, similar to
what MySQL uses. So a key length of  252 bytes would be a 1b length. a
body length of just under 2^16 would be 3 bytes (253 as a flag + 2 bytes),
and over would be 4 bytes (254 as a flag + 3 bytes).

Could be nice for getting CAS down in size, but you end up inflating an
extra byte for larger values.

 Couple notes:

 * We can't omit the vbucket in the response if we're doing *K type operations 
 (which I still don't think are necessary).

okay, so vbucket and response stay as separate flags.

 * I like the idea of a separate quiet flag from the opcode (but will happily 
 settle for having the bit in a consistent position)

Using the last spare flag in the magic byte? Even if we bump up a whole
byte for flags, that only gives one extra. Originally I had it listed in
the magic byte, but moved it to the opcode bit to free up a flag. I'd
accept a strong argument to the contrary, though.

 * Tap has a variable length extras, but we could possibly just push that into 
 the body.

I'm too blind at a glance to see where that is in the wiki page you wrote.
Would it be a huge pain to change?

 * I don't quite understand the position of CAS in that diagram -- it looks 
 like it's not aligned, but that doesn't sound right.

I didn't spend a ton of time re-aligning the bytes after removing a chunk
of them. Given the flags you send, CAS may not end up fully aligned in the
header anyway. That's not necessarily how the API end has to implement it
however, that's just how it has to be read off the wire.

 * I like the ASCII stuff, but I would like to see more stuff around quiet 
 that make it harder to get wrong.

Can you expand on this? The way I tried to write it was direct compat with
the way binprot is handled. ie; you can shove commands down the barrel and
read them back asynchronously, matching up opaques or keys to specific
errors. See the (admittedly barely notated) response section for ASCII.

 I'd like to re-propose all of the arguments I lost in the original binary 
 protocol definition that have come back to suck for me and have another
 chance to lose, but with more experience now so I can actually say *where* 
 it's sucked:

 * Untagged responses.
 * Signed incr (and no decr -- again)
 * Quiet as a flag.

 To expand:

 # Untagged Response

 Like IMAP, I'd like to have the ability to send messages from the server that 
 are not responses to requests the client made.  That is, messages can
 be sent *between* other messages.  This allows for things like fully 
 asynchronous responses interleaved with synchronous responses:

 1 something that will take a while
 1 doing
 2 something quick
 2 done
 3 something else quick
 . Hey, that thing from before is done
 3 done

 Clients can ignore (or log or whatever) unsolicited messages they don't know 
 how to handle, but some operations get *very* simple (observing
 internal memory restructuring, jobs over keys, persistence operations, 
 proxy operations, etc...)

How does binprot stop you from doing this presently (besides saying you
can't)?

 # Signed Incr (and no decr)

 5 + -1 = 4

 One operation, one thing to worry about, one thing to test.  We've had bugs 
 in each of them separately.  Counters aren't likely to actually go up
 above 2^63 (though I have had people say they slice a single counter up into 
 multiple smaller counters and address the individual parts, so there's
 at least one reason, though, you know, bah).

This one is so annoying. I think it *may* be fine to change. If a user
wishes to treat it as an unsigned value, they can simply do unsigned
casts with the numbers. That may end up with clients doing horrific
signed/unsigned incr/decr emulation layers though.

Argh. So much hate.

 # Quiet as a Flag

 Again, happy to take it as a consistent bit, but it's not a different 
 command, just different handling of the command both in the server and the
 client.

I wrote my justification above. Hit me back with a stronger response, or
is it fine?

Thanks!
-Dormando

Re: Protocol V3 proposal