Skip to content

Commit

Permalink
Wider reaching whitespace cleanup.
Browse files Browse the repository at this point in the history
  • Loading branch information
@dustin
dustin committed Sep 14, 2009
1 parent 071cf9f commit 743fab4
Show file tree
Hide file tree
Showing 11 changed files with 821 additions and 819 deletions.
1,020 changes: 510 additions & 510 deletions doc/Doxyfile
View file

Large diffs are not rendered by default.

40 changes: 20 additions & 20 deletions doc/memcached.1
View file
Original file line number Diff line number Diff line change
Expand Up @@ -12,12 +12,12 @@ memory object caching daemon.
.PP
.B memcached
is a flexible memory object caching daemon designed to alleviate database load
in dynamic web applications by storing objects in memory. It's based on
libevent to scale to any size needed, and is specifically optimized to avoid
in dynamic web applications by storing objects in memory. It's based on
libevent to scale to any size needed, and is specifically optimized to avoid
swapping and always use non-blocking I/O.
.br
.SH OPTIONS
These programs follow the usual GNU command line syntax. A summary of options
These programs follow the usual GNU command line syntax. A summary of options
is included below.
.TP
.B \-s <file>
Expand All @@ -26,15 +26,15 @@ Unix socket path to listen on (disables network support).
.B \-a <perms>
Permissions (in octal format) for Unix socket created with \-s option.
.TP
.B \-l <ip_addr>
.B \-l <ip_addr>
Listen on <ip_addr>; default to INADDR_ANY. This is an important option to
consider as there is no other way to secure the installation. Binding to an
consider as there is no other way to secure the installation. Binding to an
internal or firewalled network interface is suggested.
.TP
.B \-d
Run memcached as a daemon.
.TP
.B \-u <username>
.B \-u <username>
Assume the identity of <username> (only when run as root).
.TP
.B \-m <num>
Expand All @@ -44,21 +44,21 @@ Use <num> MB memory max to use for object storage; the default is 64 megabytes.
Use <num> max simultaneous connections; the default is 1024.
.TP
.B \-R <num>
This option seeks to prevent client starvation by setting a limit to the
number of sequential requests the server will process from an individual
client connection. Once a connection has exceeded this value, the server will
attempt to process I/O on other connections before handling any further
This option seeks to prevent client starvation by setting a limit to the
number of sequential requests the server will process from an individual
client connection. Once a connection has exceeded this value, the server will
attempt to process I/O on other connections before handling any further
request from this connection. The default value for this option is 20.
.TP
.B \-k
.B \-k
Lock down all paged memory. This is a somewhat dangerous option with large
caches, so consult the README and memcached homepage for configuration
suggestions.
.TP
.B \-p <num>
.B \-p <num>
Listen on TCP port <num>, the default is port 11211.
.TP
.B \-U <num>
.B \-U <num>
Listen on UDP port <num>, the default is port 11211, 0 is off.
.TP
.B \-M
Expand Down Expand Up @@ -92,7 +92,7 @@ Show the version of memcached and a summary of options.
Be verbose during the event loop; print out errors and warnings.
.TP
.B \-vv
Be even more verbose; same as \-v but also print client commands and
Be even more verbose; same as \-v but also print client commands and
responses.
.TP
.B \-i
Expand All @@ -103,7 +103,7 @@ Print pidfile to <filename>, only used under \-d option.
.TP
.B \-t <threads>
Number of threads to use to process incoming requests. This option is only
meaningful if memcached was compiled with thread support enabled. It is
meaningful if memcached was compiled with thread support enabled. It is
typically not useful to set this higher than the number of CPU cores on the
memcached server. The default is 4.
.TP
Expand All @@ -126,18 +126,18 @@ specify the protocol clients must speak. Possible options are "auto"
(the default, autonegotiation behavior), "ascii" and "binary".
.br
.SH LICENSE
The memcached daemon is copyright Danga Interactive and is distributed under
The memcached daemon is copyright Danga Interactive and is distributed under
the BSD license. Note that daemon clients are licensed separately.
.br
.SH SEE ALSO
The README file that comes with memcached
.br
.B http://www.danga.com/memcached
.SH AUTHOR
The memcached daemon was written by Anatoly Vorobey
The memcached daemon was written by Anatoly Vorobey
.B <[email protected]>
and Brad Fitzpatrick
.B <[email protected]>
and the rest of the crew of Danga Interactive
and Brad Fitzpatrick
.B <[email protected]>
and the rest of the crew of Danga Interactive
.B http://www.danga.com
.br
70 changes: 35 additions & 35 deletions doc/memory_management.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ From: Trond Norbye <[email protected]>
When started with -L memcached will try to enable large memory
pages, and preallocate all memory up front. By using large memory
pages memcached could reduce the number of TLB misses (depending
on the access pattern), and hence improve performance.
on the access pattern), and hence improve performance.

See http://en.wikipedia.org/wiki/Translation_lookaside_buffer for
a description of TLB.
Expand All @@ -22,44 +22,44 @@ On Fri, Sep 05, 2003 at 12:07:48PM -0400, Kyle R. Burton wrote:
> operates? (slabs.c?)

There's no documentation yet, and it's worth mentioning that this
subsystem is the most active area of memcached under development at the
subsystem is the most active area of memcached under development at the
moment (however, all the changes to it won't modify the way memcached
presents itself towards clients, they're primarily directed at making
memcached use memory more efficiently).

Here's a quick recap of what it does now and what is being worked
on.
on.

The primary goal of the slabs subsystem in memcached was to eliminate
memory fragmentation issues totally by using fixed-size memory chunks
coming from a few predetermined size classes (early versions of
memcached relied on malloc()'s handling of fragmentation which proved
coming from a few predetermined size classes (early versions of
memcached relied on malloc()'s handling of fragmentation which proved
woefully inadequate for our purposes). For instance, suppose
we decide at the outset that the list of possible sizes is: 64 bytes,
128 bytes, 256 bytes, etc. - doubling all the way up to 1Mb. For each
size class in this list (each possible size) we maintain a list of free
chunks of this size. Whenever a request comes for a particular size,
it is rounded up to the closest size class and a free chunk is taken
from that size class. In the above example, if you request from the
it is rounded up to the closest size class and a free chunk is taken
from that size class. In the above example, if you request from the
slabs subsystem 100 bytes of memory, you'll actually get a chunk 128
bytes worth, from the 128-bytes size class. If there are no free chunks
of the needed size at the moment, there are two ways to get one: 1) free
an existing chunk in the same size class, using LRU queues to free the
least needed objects; 2) get more memory from the system, which we
currently always do in _slabs_ of 1Mb each; we malloc() a slab, divide
an existing chunk in the same size class, using LRU queues to free the
least needed objects; 2) get more memory from the system, which we
currently always do in _slabs_ of 1Mb each; we malloc() a slab, divide
it to chunks of the needed size, and use them.

The tradeoff is between memory fragmentation and memory utilisation. In
The tradeoff is between memory fragmentation and memory utilisation. In
the scheme we're now using, we have zero fragmentation, but a relatively
high percentage of memory is wasted. The most efficient way to reduce
the waste is to use a list of size classes that closely matches (if
the waste is to use a list of size classes that closely matches (if
that's at all possible) common sizes of objects that the clients
of this particular installation of memcached are likely to store.
For example, if your installation is going to store hundreds of
thousands of objects of the size exactly 120 bytes, you'd be much better
off changing, in the "naive" list of sizes outlined above, the class
of 128 bytes to something a bit higher (because the overhead of
storing an item, while not large, will push those 120-bytes objects over
of 128 bytes to something a bit higher (because the overhead of
storing an item, while not large, will push those 120-bytes objects over
128 bytes of storage internally, and will require using 256 bytes for
each of them in the naive scheme, forcing you to waste almost 50% of
memory). Such tinkering with the list of size classes is not currently
Expand All @@ -68,28 +68,28 @@ possible with memcached, but enabling it is one of the immediate goals.
Ideally, the slabs subsystem would analyze at runtime the common sizes
of objects that are being requested, and would be able to modify the
list of sizes dynamically to improve memory utilisation. This is not
planned for the immediate future, however. What is planned is the
ability to reassign slabs to different classes. Here's what this means.
planned for the immediate future, however. What is planned is the
ability to reassign slabs to different classes. Here's what this means.
Currently, the total amount of memory allocated for each size class is
determined by how clients interact with memcached during the initial
phase of its execution, when it keeps malloc()'ing more slabs and
dividing them into chunks, until it hits the specified memory limit
(say, 2Gb, or whatever else was specified). Once it hits the limit, to
allocate a new chunk it'll always delete an existing chunk of the same
size (using LRU queues), and will never malloc() or free() any memory
from/to the system. So if, for example, during those initial few hours
of memcached's execution your clients mainly wanted to store very small
items, the bulk of memory allocated will be divided to small-sized
chunks, and the large size classes will get fewer memory, therefore the
life-cycle of large objects you'll store in memcached will henceforth
always be much shorter, with this instance of memcached (their LRU
queues will be shorter and they'll be pushed out much more often). In
general, if your system starts producing a different pattern of common
object sizes, the memcached servers will become less efficient, unless
you restart them. Slabs reassignment, which is the next feature being
worked on, will ensure the server's ability to reclaim a slab (1Mb of
memory) from one size class and put it into another class size, where
determined by how clients interact with memcached during the initial
phase of its execution, when it keeps malloc()'ing more slabs and
dividing them into chunks, until it hits the specified memory limit
(say, 2Gb, or whatever else was specified). Once it hits the limit, to
allocate a new chunk it'll always delete an existing chunk of the same
size (using LRU queues), and will never malloc() or free() any memory
from/to the system. So if, for example, during those initial few hours
of memcached's execution your clients mainly wanted to store very small
items, the bulk of memory allocated will be divided to small-sized
chunks, and the large size classes will get fewer memory, therefore the
life-cycle of large objects you'll store in memcached will henceforth
always be much shorter, with this instance of memcached (their LRU
queues will be shorter and they'll be pushed out much more often). In
general, if your system starts producing a different pattern of common
object sizes, the memcached servers will become less efficient, unless
you restart them. Slabs reassignment, which is the next feature being
worked on, will ensure the server's ability to reclaim a slab (1Mb of
memory) from one size class and put it into another class size, where
it's needed more.

--
--
avva
72 changes: 36 additions & 36 deletions scripts/memcached-init
View file
Original file line number Diff line number Diff line change
@@ -1,13 +1,13 @@
#! /bin/sh
#
# skeleton example file to build /etc/init.d/ scripts.
# This file should be used to construct scripts for /etc/init.d.
# skeleton example file to build /etc/init.d/ scripts.
# This file should be used to construct scripts for /etc/init.d.
#
# Written by Miquel van Smoorenburg <[email protected]>.
# Modified for Debian
# by Ian Murdock <[email protected]>.
# Written by Miquel van Smoorenburg <[email protected]>.
# Modified for Debian
# by Ian Murdock <[email protected]>.
#
# Version: @(#)skeleton 1.9 26-Feb-2001 [email protected]
# Version: @(#)skeleton 1.9 26-Feb-2001 [email protected]
#

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
Expand All @@ -23,37 +23,37 @@ test -x $DAEMONBOOTSTRAP || exit 0
set -e

case "$1" in
start)
echo -n "Starting $DESC: "
start-stop-daemon --start --quiet --exec $DAEMONBOOTSTRAP
echo "$NAME."
;;
stop)
echo -n "Stopping $DESC: "
start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE --exec $DAEMON
echo "$NAME."
rm -f $PIDFILE
;;
start)
echo -n "Starting $DESC: "
start-stop-daemon --start --quiet --exec $DAEMONBOOTSTRAP
echo "$NAME."
;;
stop)
echo -n "Stopping $DESC: "
start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE --exec $DAEMON
echo "$NAME."
rm -f $PIDFILE
;;

restart|force-reload)
#
# If the "reload" option is implemented, move the "force-reload"
# option to the "reload" entry above. If not, "force-reload" is
# just the same as "restart".
#
echo -n "Restarting $DESC: "
start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE
rm -f $PIDFILE
sleep 1
start-stop-daemon --start --quiet --exec $DAEMONBOOTSTRAP
echo "$NAME."
;;
*)
N=/etc/init.d/$NAME
# echo "Usage: $N {start|stop|restart|reload|force-reload}" >&2
echo "Usage: $N {start|stop|restart|force-reload}" >&2
exit 1
;;
restart|force-reload)
#
# If the "reload" option is implemented, move the "force-reload"
# option to the "reload" entry above. If not, "force-reload" is
# just the same as "restart".
#
echo -n "Restarting $DESC: "
start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE
rm -f $PIDFILE
sleep 1
start-stop-daemon --start --quiet --exec $DAEMONBOOTSTRAP
echo "$NAME."
;;
*)
N=/etc/init.d/$NAME
# echo "Usage: $N {start|stop|restart|reload|force-reload}" >&2
echo "Usage: $N {start|stop|restart|force-reload}" >&2
exit 1
;;
esac

exit 0
Loading

0 comments on commit 743fab4

Please sign in to comment.