Details
-
Bug
-
Resolution: Incomplete
-
Major
-
None
-
1.7.1
-
Security Level: Public
-
ubuntu 10.10 32bit. Ec2. m1.small. Nginx, php-fpm.
/usr/sbin/php5-fpm -v
PHP 5.3.3-1ubuntu9.5 (fpm-fcgi) (built: May 3 2011 00:56:00)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Suhosin v0.9.31, Copyright (c) 2007-2010, by SektionEins GmbH
I downloaded and installed http://packages.couchbase.com/releases/1.7.1/moxi-server_x86_1.7.1.deb, but moxi bin says its version 1.7.0_4.... not sure why the mismatch.
./moxi -h
moxi 1.7.0_4_g6a26e91
I use PHP memcached lib (version 3.0.6 - http://pecl.php.net/package/memcache/3.0.6) to connect my PHP app to client side moxy, which connects to a membase v 1.7.1 cluster, and a MEMCACHED type bucket.
Here is my moxi config:
cat /opt/moxi/etc/moxi.cfg (I use high timeouts as our database this is fronting is far away, and m1.smalls only have 1 CPU)
usr=MyUSER,
pwd=MYPW,
port_listen=11211,
default_bucket_name=mybucket,
downstream_max=1024,
downstream_conn_max=16,
downstream_conn_queue_timeout=800,
downstream_timeout=5000,
wait_queue_timeout=800,
connect_max_errors=5,
connect_retry_interval=30000,
connect_timeout=1600,
auth_timeout=200,
cycle=200
I changed the threads on the moxi /opt/moxi/etc/moxi-init.d to 8:
start_daemon /bin/su -c "$DAEMON -d -P $PIDFILE -Z $MOXI_CFG -z $MOXI_CLUSTER_CFG -t 8" moxi
We are using get_multi but NOT set_multi (via http://www.php.net/manual/en/memcache.get.php - passing array of keys).
We connect to client side moxi server on localhost 11211 via http://www.php.net/manual/en/memcache.pconnect.php
ubuntu 10.10 32bit. Ec2. m1.small. Nginx, php-fpm. /usr/sbin/php5-fpm -v PHP 5.3.3-1ubuntu9.5 (fpm-fcgi) (built: May 3 2011 00:56:00) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies with Suhosin v0.9.31, Copyright (c) 2007-2010, by SektionEins GmbH I downloaded and installed http://packages.couchbase.com/releases/1.7.1/moxi-server_x86_1.7.1.deb, but moxi bin says its version 1.7.0_4.... not sure why the mismatch. ./moxi -h moxi 1.7.0_4_g6a26e91 I use PHP memcached lib (version 3.0.6 - http://pecl.php.net/package/memcache/3.0.6) to connect my PHP app to client side moxy, which connects to a membase v 1.7.1 cluster, and a MEMCACHED type bucket. Here is my moxi config: cat /opt/moxi/etc/moxi.cfg (I use high timeouts as our database this is fronting is far away, and m1.smalls only have 1 CPU) usr=MyUSER, pwd=MYPW, port_listen=11211, default_bucket_name=mybucket, downstream_max=1024, downstream_conn_max=16, downstream_conn_queue_timeout=800, downstream_timeout=5000, wait_queue_timeout=800, connect_max_errors=5, connect_retry_interval=30000, connect_timeout=1600, auth_timeout=200, cycle=200 I changed the threads on the moxi /opt/moxi/etc/moxi-init.d to 8: start_daemon /bin/su -c "$DAEMON -d -P $PIDFILE -Z $MOXI_CFG -z $MOXI_CLUSTER_CFG -t 8" moxi We are using get_multi but NOT set_multi (via http://www.php.net/manual/en/memcache.get.php - passing array of keys). We connect to client side moxi server on localhost 11211 via http://www.php.net/manual/en/memcache.pconnect.php
Description
I'm seeing what almost looks like a memory leak. server running client side moxy has been up for 1 day, using 38% memory (633m RES, 744m virt, 1176k shr).
The total memory on m1.small box is 1665 megs.
There is not much load on the server. When i first start/restart moxi-server the process is consuming about 9 megs of RES. It then goes up from there.
Here are connection stats for a moxi client that has just been running for about 30 minutes (I had to restart the moxi in this bug as it was taking up so much memory)
echo "stats proxy" | nc -q 1 localhost 11211 | grep total_connections
STAT memcached:stats:total_connections 262
In a typical day, we see a range of about 100 to 300 operations per second coming from this moxi client. We run multiple servers with this same setup, all of them see a growth in moxi client memory footprint over time.
I can't tell if this bug is related to the existing bug MB-4168: http://www.couchbase.org/issues/browse/MB-4168