dormando edited this page Dec 18, 2016 · 3 revisions

Memcached 1.4.8 Release Notes

Date: 2011-10-04


Download Link:


Feature and bugfix release. New Touch commands, counters, and a change to connection limit functionality.

Included is an important bugfix for binary protocol users. The binary get command was not activating the LRU algorithm. Fetching an item would not prevent it from getting expired early.


  • Fix to write correct pid from start-memcached
  • Fix to enable LRU when using binary protocol
  • Upgrade stats items counters to 64bit
  • Add new stats expired_unfetched, evicted_unfetched
  • Allow setting initial size of the hash table
  • Expose stats for the internal hash table
  • bug220: incr would sometimes return the previous item's CAS
  • Fixed bug on multi get processing
  • Experimental maxconns_fast option
  • Add an ASCII touch command
  • Add binary GATK/GATKQ
  • Backport binary TOUCH/GAT/GATQ commands
  • Issue 221: Increment treats leading spaces as 0
  • Fix compile error on OS X

New Features

Touch Commands

Binary Touch/GAT commands were backported from 1.6. New GATK/GATKQ commands were added for completeness. Finally, an Ascii protocol touch command was also added.

Touch commands are used to update the expiration time of an existing item without fetching it. Say you have a counter set to expire in five minutes, but you may want to push back the expiration time by five more minutes, or change it to 15 minutes. With touch, you can do that.

The binary protocol also adds GAT commands (Get And Touch), which allow you to fetch an item and simultaneously update its expiration time.

Fast Connection Limit Handling

A new option, -o, has appeared! With -o new, experimental, or highly specific options are given full names. The first of which is maxconns_fast

```$ memcached -o maxconns_fast}}}

This option changes the way the maximum connection limit is handled. By default, when memcached runs out of file descriptors, it stops listening for new connections. When this happens, connections will sit in the listen backlog (defaulting to 1024, and adjustable with the -b option). Once some connections close off, memcached will starts accepting new connections again and they will be served.

This is undesireable as it can cause clients to delay or timeout for a long period of time. Long enough that it may be quicker to treat the items as a cache miss.

When a client connects and memcached is configured with maxconns_fast, it writes an error to the client and immediately closes the connection. This is similar to how MySQL operates, whereas the default is similar to Apache.

It is experimental as it is unknown how clients will handle this change. Please help test and report any issues to upstream client maintainers!

Internal Hash Table

STAT hash_power_level 16
STAT hash_bytes 524288
STAT hash_is_expanding 0

Now it's possible to see how much memory the hash table itself uses. This can be useful for deciding on RAM limits for very large instances.

There is also a new option for setting the size of the hash table on startup:

```$ memcached -o hashpower=20}}}

If you run instances with many millions of items, and items are added very rapidly on a restart, it may be desireable to presize the hash table. Normally memcached will dynamically grow the hash table as needed, and this operation is generally very low overhead. If you put decals on your '96 Mazda grapefruit shootermobile, you may like this option.

Just examine the hash_power_level before restarting your instances, and adjust the startup command.

expired_unfetched, evicted_unfetched

The two stats represent items which expired and memory was reused, and valid items which were evicted, but never touched by get/incr/append/etc operations in the meantime.

Useful for seeing how many wasted items are being set and then rolling out through the bottom of the LRU's.

If these counters are high, you may consider auditing what is being put into the cache.


The following people contributed to this release since 1.4.7.

Note that this is based on who contributed changes, not how they were done. In many cases, a code snippet on the mailing list or a bug report ended up as a commit with your name on it.

Note that this is just a summary of how many changes each person made which doesn't necessarily reflect how significant each change was. For details on what led up into a branch, either grab the git repo and look at the output of git log 1.4.7..1.4.8 or use a web view.

    12  dormando
     2  Daniel Pañeda
     2  Trond Norbye
     1  Dustin Sallings
     1  Nate