arthasxcp / memagent Goto Github PK

1. /usr/local/magent/magent -s 192.168.1.102:11211 -b 192.168.1.101:11211 -p 
2222 -v
   I just run one server on 192.168.1.102:11211
   and bakcUp server   192.168.1.101:11211 
2. when I break down 192.168.1.102:11211  by manual
3. then My client to get SomeKey, I can't get value from bakup Server.

My Questoin is  1： how many server are supported? 
                2:  when only one server and it down, could bakup server can get value By Key? 

What steps will reproduce the problem?
1. open magent with port 12000
2. use xmemcached binnarycommand to connect magent
3. set some value to memcached

What is the expected output? What do you see instead?

  i wish the set is ok,but it's operation timeout

What version of the product are you using? On what operating system?

   v0.5 v0.6 
   centos 6.5

Please provide any additional information below.

What steps will reproduce the problem?
1. /usr/sbin/magent -p 11211 -s 127.0.0.1:11212 -b 10.149.207.16:11211 -n
30000 -k -D
2. Wait a few seconds
3. see the tool crash with [err] event_queue_remove: 0x128276b8(fd 177) not
on queue 8


What is the expected output? What do you see instead?
[root@memcached-06 ~]# /usr/sbin/magent -p 11211 -s 127.0.0.1:11212 -b
10.149.207.16:11211 -n 30000 -k -D
using ketama algorithm
[err] event_queue_remove: 0x128276b8(fd 177) not on queue 8
[root@memcached-06 ~]# 

What version of the product are you using? On what operating system?
Centos 5.2
libevent-1.1a-3.2.1

Please provide any additional information below.

What steps will reproduce the problem?
1. use ketama algorithm
2. 4 memcached servers 
3.

What is the expected output? What do you see instead?

Memagent v0.6 use ketama algorithm, encountered same kind of crash, three times 
on diffrent servers.

crash info:
Core was generated by `/usr/sbin/magent -l 127.0.0.1 -p 8087 -s 
192.168.103.105:8086 -s 192.168.103.10'.
Program terminated with signal 6, Aborted.
#0  0x00000032b8030265 in raise () from /lib64/libc.so.6
#1  0x00000032b8031d10 in abort () from /lib64/libc.so.6
#2  0x00000032b806a84b in __libc_message () from /lib64/libc.so.6
#3  0x00000032b807230f in _int_free () from /lib64/libc.so.6
#4  0x00000032b807276b in free () from /lib64/libc.so.6
#5  0x0000000000401e30 in list_free (l=0xdb08b20, keep_list=1) at magent.c:329
#6  0x00000000004037fd in process_get_response (fd=<value optimized out>, 
which=<value optimized out>, arg=0xdb09410) at magent.c:1408
#7  drive_memcached_server (fd=<value optimized out>, which=<value optimized 
out>, arg=0xdb09410) at magent.c:1285
#8  0x0000000000407a1a in event_base_loop ()


What version of the product are you using? On what operating system?
v0.6
Linux 2.6.18-194.32.1.el5xen x86_64 (RedHat )

Please provide any additional information below.

用了一段时间发现有内存泄漏 
，现象是每一次get都会有20byte的内存泄漏。
查了一下代码，发现了泄漏点
以 r28版为例，

在magent.c文件的 1595行，   b = buffer_init_size(len + 3);  
分配了一个buffer

但在1733行 ，退出了函数，虽然1732行有conn_close(c); 
但因为1595分配的buffer 还没有加入到c->request(这个加入
动作要到1745行完成), 
所以1732行的conn_close(c)并没有释放1595行分配的buffer

另外,在使用中发现,因为mamagent没有考虑超过机制，memagent在��
�台memcached突然死掉的情况下，会造成
memagent长久等待，这样所有的客户端都会卡死，造成整个web前
台死掉，这是很难让人接受的，我对代码临时加了
一些超时机制，但无法保证都加对了，我并在附件中了，因��
�联系不上作者，如果作者有兴趣，请联系我 
gnujava[at]gmail.com

magent started at Fri Apr  1 21:30:23 CST 2011
*** glibc detected *** /usr/bin/magent: corrupted double-linked list: 
0x00000000016835f0 ***
======= Backtrace: =========
/lib/libc.so.6(+0x775b6)[0x7f53f8ec05b6]
/lib/libc.so.6(+0x7aa25)[0x7f53f8ec3a25]
/lib/libc.so.6(cfree+0x73)[0x7f53f8ec6e83]
/usr/bin/magent[0x40445b]
/usr/local/lib/libevent-1.4.so.2(event_base_loop+0x3b9)[0x7f53f94565c9]
/usr/bin/magent[0x405978]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7f53f8e67c4d]
/usr/bin/magent[0x401719]
======= Memory map: ========
00400000-00409000 r-xp 00000000 fb:00 2764648                            
/usr/bin/magent
00608000-00609000 r--p 00008000 fb:00 2764648                            
/usr/bin/magent
00609000-0060a000 rw-p 00009000 fb:00 2764648                            
/usr/bin/magent
0166d000-016d0000 rw-p 00000000 00:00 0                                  [heap]
7f53f4000000-7f53f4021000 rw-p 00000000 00:00 0 
7f53f4021000-7f53f8000000 ---p 00000000 00:00 0 
7f53f83da000-7f53f83f0000 r-xp 00000000 fb:00 524343                     
/lib/libgcc_s.so.1
7f53f83f0000-7f53f85ef000 ---p 00016000 fb:00 524343                     
/lib/libgcc_s.so.1
7f53f85ef000-7f53f85f0000 r--p 00015000 fb:00 524343                     
/lib/libgcc_s.so.1
7f53f85f0000-7f53f85f1000 rw-p 00016000 fb:00 524343                     
/lib/libgcc_s.so.1
7f53f85f1000-7f53f8609000 r-xp 00000000 fb:00 527876                     
/lib/libpthread-2.11.1.so
7f53f8609000-7f53f8808000 ---p 00018000 fb:00 527876                     
/lib/libpthread-2.11.1.so
7f53f8808000-7f53f8809000 r--p 00017000 fb:00 527876                     
/lib/libpthread-2.11.1.so
7f53f8809000-7f53f880a000 rw-p 00018000 fb:00 527876                     
/lib/libpthread-2.11.1.so
7f53f880a000-7f53f880e000 rw-p 00000000 00:00 0 
7f53f880e000-7f53f8824000 r-xp 00000000 fb:00 527878                     
/lib/libresolv-2.11.1.so
7f53f8824000-7f53f8a23000 ---p 00016000 fb:00 527878                     
/lib/libresolv-2.11.1.so
7f53f8a23000-7f53f8a24000 r--p 00015000 fb:00 527878                     
/lib/libresolv-2.11.1.so
7f53f8a24000-7f53f8a25000 rw-p 00016000 fb:00 527878                     
/lib/libresolv-2.11.1.so
7f53f8a25000-7f53f8a27000 rw-p 00000000 00:00 0 
7f53f8a27000-7f53f8a2e000 r-xp 00000000 fb:00 527879                     
/lib/librt-2.11.1.so
7f53f8a2e000-7f53f8c2d000 ---p 00007000 fb:00 527879                     
/lib/librt-2.11.1.so
7f53f8c2d000-7f53f8c2e000 r--p 00006000 fb:00 527879                     
/lib/librt-2.11.1.so
7f53f8c2e000-7f53f8c2f000 rw-p 00007000 fb:00 527879                     
/lib/librt-2.11.1.so
7f53f8c2f000-7f53f8c46000 r-xp 00000000 fb:00 524675                     
/lib/libnsl-2.11.1.so
7f53f8c46000-7f53f8e45000 ---p 00017000 fb:00 524675                     
/lib/libnsl-2.11.1.so
7f53f8e45000-7f53f8e46000 r--p 00016000 fb:00 524675                     
/lib/libnsl-2.11.1.so
7f53f8e46000-7f53f8e47000 rw-p 00017000 fb:00 524675                     
/lib/libnsl-2.11.1.so
7f53f8e47000-7f53f8e49000 rw-p 00000000 00:00 0 
7f53f8e49000-7f53f8fc3000 r-xp 00000000 fb:00 524659                     
/lib/libc-2.11.1.so
7f53f8fc3000-7f53f91c2000 ---p 0017a000 fb:00 524659                     
/lib/libc-2.11.1.so
7f53f91c2000-7f53f91c6000 r--p 00179000 fb:00 524659                     
/lib/libc-2.11.1.so
7f53f91c6000-7f53f91c7000 rw-p 0017d000 fb:00 524659                     
/lib/libc-2.11.1.so
7f53f91c7000-7f53f91cc000 rw-p 00000000 00:00 0 
7f53f91cc000-7f53f924e000 r-xp 00000000 fb:00 524671                     
/lib/libm-2.11.1.so
7f53f924e000-7f53f944d000 ---p 00082000 fb:00 524671                     
/lib/libm-2.11.1.so
7f53f944d000-7f53f944e000 r--p 00081000 fb:00 524671                     
/lib/libm-2.11.1.so
7f53f944e000-7f53f944f000 rw-p 00082000 fb:00 524671                     
/lib/libm-2.11.1.so
7f53f944f000-7f53f9469000 r-xp 00000000 fb:00 2796180                    
/usr/local/lib/libevent-1.4.so.2.2.0
7f53f9469000-7f53f9668000 ---p 0001a000 fb:00 2796180                    
/usr/local/lib/libevent-1.4.so.2.2.0
7f53f9668000-7f53f9669000 r--p 00019000 fb:00 2796180                    
/usr/local/lib/libevent-1.4.so.2.2.0
7f53f9669000-7f53f966a000 rw-p 0001a000 fb:00 2796180                    
/usr/local/lib/libevent-1.4.so.2.2.0
7f53f966a000-7f53f966b000 rw-p 00000000 00:00 0 
7f53f966b000-7f53f968b000 r-xp 00000000 fb:00 524337                     
/lib/ld-2.11.1.so
7f53f9871000-7f53f9876000 rw-p 00000000 00:00 0 
7f53f9888000-7f53f988a000 rw-p 00000000 00:00 0 
7f53f988a000-7f53f988b000 r--p 0001f000 fb:00 524337                     
/lib/ld-2.11.1.so
7f53f988b000-7f53f988c000 rw-p 00020000 fb:00 524337                     
/lib/ld-2.11.1.so
7f53f988c000-7f53f988d000 rw-p 00000000 00:00 0 
7fff0c01a000-7fff0c02f000 rw-p 00000000 00:00 0                          [stack]
7fff0c035000-7fff0c036000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  
[vsyscall]
magent started at Fri Apr  1 22:35:21 CST 2011

What steps will reproduce the problem?
1. cd /tmp/magent;tar zxvf magent-0.6.tar.gz
2. make
output this error: 
gcc -Wall -g -O2 -I/usr/local/include -m64 -o magent magent.o ketama.o 
/usr/lib64/libevent.a /usr/lib64/libm.a 
gcc: /usr/lib64/libm.a：no file or directory

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

What steps will reproduce the problem?
1. ketama.c:ketama_hashi returns 0 for some keys e.g. wp_:posts:84
2. This makes magent to crash if using ketama (in ketama.c:get_server)

What is the expected output? What do you see instead?

magent crashing from time to time with a segfault, when using ketama. This
makes it impossible to use magent with ketama.

What version of the product are you using? On what operating system?

 - Linux 2.6.28-11 
 - libevent 1.3
 - gcc 4.3.3


Please provide any additional information below.

I do not quite understand what ketama_hashi does and whether 0 is a valid
value. But as a work around I'm not searching for the server in
ketama.c:get_server (aprox line 431). Instead of while (1), I'm doing while
(h) .

I have attached my patch, but please use it at your own risk

ketama_hashi return unsigned int ,but in this function you made the ret 
unsigned char.
so the return just are the lower 4 bits of the (int) ret;
static unsigned int ketama_hashi( const char* inString )
{
    unsigned char digest[16], ret;
    ketama_md5_digest( inString, digest );
    ret = ( digest[3] << 24 )
                        | ( digest[2] << 16 )
                        | ( digest[1] <<  8 )
                        |   digest[0];

    return ret;
}
in file ketama.c 355 line.
---------------------------------------------------------
so this make the balance of memcaches fail.

Not really an issue, but some questions:

1. Does magent duplicates a key-value pair to multiple memcached backends, or 
just one of them?
2. How many connections magent will establish to *one* backend?
3. Is there a way to know whether a backend is live or dead, and how to 
manually mark a backend 
as live or dead?

Thanks a lot, it's a good idea. :)

(1)

~/box/magent# make
gcc -Wall -O2 -g  -c -o magent.o magent.c
magent.c: In function 'writev_list':
magent.c:592: error: 'SSIZE_MAX' undeclared (first use in this function)

<limits.h> should be #include'd.

(2)

~/box/magent# make
gcc -Wall -O2 -g  -c -o magent.o magent.c
magent.c: In function 'writev_list':
magent.c:606: warning: implicit declaration of function 'writev'

<sys/uio.h> should be #include'd.

如何做到动态的添加memcache而不用重启memagent呢