Oracle 5.0 Reference Manual page 1368

server changes the distribution of keys, and this in turn requires rebuilding the cached data on the
memcached
The same effect can occur if you actively manage the list of servers configured in your clients, adding
and removing the configured
For example, removing a
be contacted can cause the server selection to fail as described here.
To prevent this causing significant problems and invalidating your cache, you can select the hashing
algorithm used to select the server. There are two common types of hashing algorithm, consistent and
modula.
With consistent hashing algorithms, the same key when applied to a list of servers always uses the
same server to store or retrieve the keys, even if the list of configured servers changes. This means
that you can add and remove servers from the configure list and always use the same server for a
given key. There are two types of consistent hashing algorithms available, Ketama and Wheel. Both
types are supported by libmemcached, and implementations are available for PHP and Java.
Any consistent hashing algorithm has some limitations. When you add servers to an existing list of
configured servers, keys are distributed to the new servers as part of the normal distribution. When you
remove servers from the list, the keys are re-allocated to another server within the list, meaning that
the cache needs to be re-populated with the information. Also, a consistent hashing algorithm does not
resolve the issue where you want consistent selection of a server across multiple clients, but where
each client contains a different list of servers. The consistency is enforced only within a single client.
With a modula hashing algorithm, the client selects a server by first computing the hash and then
choosing a server from the list of configured servers. As the list of servers changes, so the server
selected when using a modula hashing algorithm also changes. The result is the behavior described
above; changes to the list of servers mean that different servers are selected when retrieving data,
leading to cache misses and increase in database load as the cache is re-seeded with information.
If you use only a single
configured for a client never changes, then the selection of a hashing algorithm is irrelevant, as it has
no noticeable effect.
If you change your servers regularly, or you use a common set of servers that are shared among a
large number of clients, then using a consistent hashing algorithm should help to ensure that your
cache data is not duplicated and the data is evenly distributed.
15.6.2.5. Using
memcached
memcached
the server. The probes included can monitor individual connections, slab allocations, and modifications
to the hash table when a key/value pair is added, updated, or removed.
For more information on DTrace and writing DTrace scripts, read the
Support for DTrace probes was added to
can be used to help monitor your application. DTrace is supported on Solaris 10, OpenSolaris, Mac OS
X 10.5 and FreeBSD. To enable the DTrace probes in memcached, build from source and use the
enable-dtrace
The probes supported by
•
conn-allocate(connid)
Fired when a connection object is allocated from the connection pool.
• connid: The connection ID.
•
conn-release(connid)
instances, causing an increase in database reads.
memcached
memcached
memcached
and DTrace
includes a number of different DTrace probes that can be used to monitor the operation of
option. For more information, see
memcached
Using
memcached
instances as each instance is identified as being available.
instance when the client notices that the instance can no longer
instance for each client, or your list of
1.2.6 includes a number of DTrace probes that
memcached
Section 15.6.1, "Installing
are:
1348
servers
memcached
DTrace User Guide.
memcached".
--