Probably not the answer you want to hear, but memory is so cheap right
now I don't think I have ever seen someone worry about the cache being
full. <br>
<br>
We have a 20GB cache just from the spare memory on all of our servers and our database is only 6GB in size. <br>
<br>
<br><br><div><span class="gmail_quote">On 5/24/07, <b class="gmail_sendername">Ben Hartshorne</b> &lt;<a href="mailto:memcache@green.hartshorne.net">memcache@green.hartshorne.net</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br><br>I am trying to evaluate the schedule for expanding our cache.&nbsp;&nbsp;We have<br>several different types of data all getting thrown into one large<br>central cache (made up of 1 instance on each of 4 machines).&nbsp;&nbsp;Some of it
<br>is transient (caching &#39;popular&#39; data for 5 minutes) and some of it is<br>more permanent (1wk expiration time).&nbsp;&nbsp;All data is backed by permanent<br>storage for cache misses.&nbsp;&nbsp;On cache miss, the data is repopulated into
<br>memcache from permanent storage.<br><br>My problem - the &#39;stats&#39; command has a metric &#39;curr_items&#39; that reports<br>the current number of items stored.&nbsp;&nbsp;However, when a piece of data<br>expires, that counter is not decremented until you issue a &#39;get&#39; on the
<br>data and fail.<br><br>In order to cache &#39;popular&#39; data, all data of that type is cached,<br>assuming that the popular ones will be hit and updated within the<br>expiration time, and so remain in the cache, while the unpopular data
<br>will just expire and nobody cares.<br><br>The problem with the curr_items stat is that if I ever get a cache miss<br>on the transient data, I immediately fetch it from the database and<br>stick it back in the cache, causing the curr_items to decrement and then
<br>increment again.&nbsp;&nbsp;Data that is unpopular is stored (causing an<br>increment) but never retrieved, so the curr_items never decrements.&nbsp;&nbsp;The<br>effect is a monotomically increasing number in curr_items until it tops<br>
out (at 2352883, though I&#39;m not sure what&#39;s special about that number).<br><br>Because of the different types of data and the changing popularity of<br>data, cache hit percentage is not a good proxy for telling me when my
<br>cache has filled up.<br><br>At the moment, I am pretty sure the cache is not full because the more<br>persistent data (1wk expiry time) usually sticks around, though I don&#39;t<br>have a good metric to prove that, it seems to be the case.
<br><br>How do I tell when my cache is full and I need to add the 5th server?&nbsp;&nbsp;I<br>tried watching the memory utilization as reported by the OS but it is<br>also monotomically increasing until it tops out at the limit given to
<br>memcache (7GB, in this case).<br><br><br>Thanks for any advice you might have,<br><br>-ben<br><br><br>--<br>Ben Hartshorne<br>email: <a href="mailto:ben@hartshorne.net">ben@hartshorne.net</a><br><a href="http://ben.hartshorne.net">
http://ben.hartshorne.net</a><br><br>-----BEGIN PGP SIGNATURE-----<br>Version: GnuPG v1.4.1 (GNU/Linux)<br><br>iD8DBQFGVexiKeT3tvTdv64RAkoIAKCHyk3M+eke6x2FuJvLgk/FocWM3ACgkEMv<br>boc59w4ET0ajViacO8YmnaE=<br>=ARV+<br>-----END PGP SIGNATURE-----
<br><br></blockquote></div><br>