ReleaseNotes148
Date: 2011-10-04
Download Link:
http://memcached.org/files/old/memcached-1.4.8.tar.gz
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
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.
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
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.
### Contributors
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.
* Repo list: https://github.com/memcached/memcached/wiki/DevelopmentRepos
* Web View: http://github.com/memcached/memcached/commits/1.4.8
12 dormando
2 Daniel Pañeda
2 Trond Norbye
1 Dustin Sallings
1 Nate