cangwolf / memagent Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/memagent
Automatically exported from code.google.com/p/memagent
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.
Original issue reported on code.google.com by [email protected]
on 22 Mar 2011 at 2:42
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.
Original issue reported on code.google.com by [email protected]
on 11 Jul 2011 at 7:29
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
Original issue reported on code.google.com by [email protected]
on 1 May 2009 at 1:29
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 28 Feb 2011 at 3:02
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
Original issue reported on code.google.com by [email protected]
on 2 Apr 2011 at 2:30
(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.
Original issue reported on code.google.com by [email protected]
on 27 Sep 2008 at 5:54
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. :)
Original issue reported on code.google.com by [email protected]
on 7 Sep 2008 at 2:20
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?
Original issue reported on code.google.com by [email protected]
on 29 Jul 2011 at 6:11
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.
Original issue reported on code.google.com by [email protected]
on 21 May 2010 at 12:16
如何做到动态的添加memcache而不用重启memagent呢
Original issue reported on code.google.com by [email protected]
on 31 Aug 2013 at 5:25
用了一段时间发现有内存泄漏
,现象是每一次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
Original issue reported on code.google.com by [email protected]
on 18 May 2010 at 12:43
Attachments:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.