http://permalink.gmane.org/gmane.comp.web.cache.memcached hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.web.cache.memcached/14262 <pre>memcached is BSD licensed, which means companies can do what they will with it... What would work better is if you released a storage engine for the 1.6 tree. Then we don't have to distribute it, or can at least warn that that particular file is encumbered. On Fri, 25 May 2012, Nezer Zaidenberg wrote: </pre> dormando 2012-05-25T19:55:13 http://permalink.gmane.org/gmane.comp.web.cache.memcached/14261 <pre>well there's about 5 algorithms (well know) that do the cache policy job 2012/5/25 Nezer Zaidenberg &lt;nzaidenberg&lt; at &gt;expay-global.com&gt;: </pre> Roberto Spadim 2012-05-25T19:00:29 http://permalink.gmane.org/gmane.comp.web.cache.memcached/14260 <pre>(Working with Yuval Meir and Limor Gavish on this project) IBM has a policy that Open Source products may use it's patent so we didn't see ARC patent as a barrier. (PostgreSQL problem was with ARC interfering with closing the source of PostgreSQL in the future) We will also try to setup a parameter so that caching algorithm can be changed at will. There are other algorithm that provides comparable results. Nezer On May 24, 10:12 pm, Yuval M &lt;yuva...&lt; at &gt;gmail.com&gt; wrote: </pre> Nezer Zaidenberg 2012-05-25T18:45:41 http://permalink.gmane.org/gmane.comp.web.cache.memcached/14259 <pre> Comment #13 on issue 141 by dorma...&lt; at &gt;rydia.net: memcached 1.4.5 - Segmentation Fault http://code.google.com/p/memcached/issues/detail?id=141 please upgrade libevent and/or memcached. </pre> memcached< at >googlecode.com 2012-05-25T03:40:56 http://permalink.gmane.org/gmane.comp.web.cache.memcached/14258 <pre> Comment #12 on issue 141 by mor...&lt; at &gt;gmail.com: memcached 1.4.5 - Segmentation Fault http://code.google.com/p/memcached/issues/detail?id=141 adding attachment Attachments: memcache-1.jpg 50.8 KB </pre> memcached< at >googlecode.com 2012-05-25T03:24:42 http://permalink.gmane.org/gmane.comp.web.cache.memcached/14257 <pre>just some doubt... i read about 2q algorithm that is (or was i didn´t checked) used by postgresql did you have some experience if it´s a good 'idea' too? about memcache... i think that policy is a 'key feature' of a cache system... maybe could be nice to implement a option at memcache command line to user select what policy should be used? 2012/5/24 Roberto Spadim &lt;roberto&lt; at &gt;spadim.com.br&gt;: </pre> Roberto Spadim 2012-05-25T03:24:07 http://permalink.gmane.org/gmane.comp.web.cache.memcached/14256 <pre>guy! i must talk, this is a very very nice and wonderful implementation, congratulations! i will try it and check if i get some increase in performance 2012/5/24 dormando &lt;dormando&lt; at &gt;rydia.net&gt;: </pre> Roberto Spadim 2012-05-25T02:52:28 http://permalink.gmane.org/gmane.comp.web.cache.memcached/14255 <pre> Comment #11 on issue 141 by mor...&lt; at &gt;gmail.com: memcached 1.4.5 - Segmentation Fault http://code.google.com/p/memcached/issues/detail?id=141 adding attachment Attachments: Munin __ nimbuzz.com __ mcd19.nimbuzz.com.jpg 50.8 KB </pre> memcached< at >googlecode.com 2012-05-25T02:44:18 http://permalink.gmane.org/gmane.comp.web.cache.memcached/14254 <pre> Comment #10 on issue 141 by mor...&lt; at &gt;gmail.com: memcached 1.4.5 - Segmentation Fault http://code.google.com/p/memcached/issues/detail?id=141 I experienced same issue with memcached 1.4.5-1 and libevent-1.4-2 1.4.13-stable-1 (Debian Squeeze), some times memcache crashed with:[err] event_queue_remove: 0x2097408(fd 30) not on queue 8 [err] event_queue_remove: 0x733408(fd 30) not on queue 8 [err] event_queue_remove: 0x1fe4408(fd 30) not on queue 8 [err] event_queue_remove: 0x6bb408(fd 30) not on queue 8 [err] event_queue_remove: 0x22c3408(fd 26) not on queue 8 [err] event_queue_remove: 0x1014408(fd 26) not on queue 8 [err] event_queue_remove: 0x1283428(fd 30) not on queue 8 [err] event_queue_remove: 0xc85428(fd 30) not on queue 8 [err] event_queue_remove: 0x19e9428(fd 26) not on queue 8 [err] event_queue_remove: 0x1c12428(fd 26) not on queue 8 while having to many connections. </pre> memcached< at >googlecode.com 2012-05-25T02:27:34 http://permalink.gmane.org/gmane.comp.web.cache.memcached/14253 <pre>Ooh, interesting! I was researching ways to improve the LRU a few months ago (it'll be a few more months before I start integrating any of it). ARC was very interesting, but unfortunately is very patented. Even if we can't use ARC, your research on improving the LRU should be interesting, thanks! Have you tried out the 1.6 storage engine branch, btw? On Thu, 24 May 2012, Yuval M wrote: </pre> dormando 2012-05-24T19:21:05 http://permalink.gmane.org/gmane.comp.web.cache.memcached/14252 <pre>Hello, My name is Yuval Meir and I am a M.Sc student in Tel Aviv University. As part of my academic research I have implemented the ARC (Adaptive Replacement Cache) caching policy in Memcached I ran benchmarks using a modified version of memaslap and the results were very good: cache misses were reduced by up to to 30% on some loads, and in terms of run time, memory usage and CPU usage, my implementation performed similar to the original Memcached. I attached the diff (based on Memcached 1.4.13) and the results I have so far in the excel file (note that it has several tabs). ARC was introduced in the following publication by Nimrod Megiddo, Dharmendra Modha: http://www.almaden.ibm.com/cs/people/dmodha/arcfast.pdf which was published in USENIX 2003. I will be very glad to get you reviewes and comments. Regards, Yuval Meir Computer Science department Tel-Aviv University </pre> Yuval M 2012-05-24T19:12:33 http://permalink.gmane.org/gmane.comp.web.cache.memcached/14251 <pre> Comment #6 on issue 272 by dorma...&lt; at &gt;rydia.net: Memcached "hung" in do_item_alloc http://code.google.com/p/memcached/issues/detail?id=272 Any updates? </pre> memcached< at >googlecode.com 2012-05-23T21:04:04 http://permalink.gmane.org/gmane.comp.web.cache.memcached/14250 <pre>I revised memcached1.4.13 to make cas ID unique between server reboots. But It seemed that two memcached instances on a server has eaten up almost all memory under stressing load. 1. OS: centerOS5.3, 64bit 2. memcached startup command: /opt/memcached1.4.13.0503b/bin/memcached -u nobody -d -m 4096 -c 1024 - l 192.168.8.224 -p 11211 -v &gt; /var/log/memcached-11211.log 2&gt;&amp;1 /opt/memcached1.4.13.0503b/bin/memcached -u nobody -d -m 4096 -c 1024 - l 192.168.8.224 -p 11211 -v &gt; /var/log/memcached-11211.log 2&gt;&amp;1 3. Memory usage: [root&lt; at &gt;dell1-12 ~]# free -m total used free shared buffers cached Mem: 16044 15986 58 0 85 24 -/+ buffers/cache: 15876 168 Swap: 7820 6911 908 Stats on one instance: stats STAT pid 32205 STAT uptime 60090 STAT time 1336177937 STAT version 1.4.13.0503b STAT libevent 1.4.12-stable STAT pointer_size 64 STAT rusage_user 1125.852844 STAT rusage_system 2174.782382 STAT curr_connection</pre> Smiling Ai 2012-05-05T02:36:18 http://permalink.gmane.org/gmane.comp.web.cache.memcached/14249 <pre>Hi! Added support for setting options via ENV variable LIBMEMCACHED. Fix corner case on last used result. Bug fixes. http://launchpad.net/libmemcached Cheers, -Brian</pre> Brian Aker 2012-05-23T07:42:50 http://permalink.gmane.org/gmane.comp.web.cache.memcached/14248 <pre>i readed some nosql features at mysql and mariadb (a mysql trunk) they are starting some nosql/cache solutions, could be nice check it i know that oracle company is a 'problem'/'solution' to mysql open source version, check others trunks, mariadb is a nice trunk and is more 'opensource' with some interesting features the memcache + db solution is nice, but i think in futures a more unified solution will exists just wait or develop it =) 2012/5/22 Jakub Łopuszański &lt;qbolec&lt; at &gt;gmail.com&gt;: </pre> Roberto Spadim 2012-05-23T02:52:56 http://permalink.gmane.org/gmane.comp.web.cache.memcached/14247 <pre>Well this is already deployed to a production system and works just great. The reason this is faster is that in some situations you can not easily shard a database as some queries would cross shards boundaries. Of course this means that a regular DB will not scale unless you change your queries. On the other hand a cache is easier to distribute/shard/scale. It is also easier (and in fact I do that on production) to have a memcache runing on each frontend machine (while this would be a strange idea to put shards of database on frontends which are usually diskless). Of course one could argue, that you should just avoid complicated queries and shard everything, but even then, the cost of communicating over network between a frontend and mysql backend can be larger than a cost of a single multiget to a memcached (even if the network latency is similar, I believe that network stack of memcahed is one of the fastest). In my particular example I have 6 frontend diskless machines, each running apache2 an</pre> Jakub Łopuszański 2012-05-22T22:08:07 http://permalink.gmane.org/gmane.comp.web.cache.memcached/14246 <pre> Comment #3 on issue 274 by vlak...&lt; at &gt;gmail.com: typo in memcached wiki http://code.google.com/p/memcached/issues/detail?id=274 http://code.google.com/p/memcached/wiki/NewUserInternals s/chukn/chunk </pre> memcached< at >googlecode.com 2012-05-20T17:46:31 http://permalink.gmane.org/gmane.comp.web.cache.memcached/14245 <pre> Comment #2 on issue 274 by vlak...&lt; at &gt;gmail.com: typo in memcached wiki http://code.google.com/p/memcached/issues/detail?id=274 Sorry that's not "512" but "5*12". The asterisk probably tricked the formatting engine. </pre> memcached< at >googlecode.com 2012-05-20T17:40:10 http://permalink.gmane.org/gmane.comp.web.cache.memcached/14244 <pre> Comment #1 on issue 274 by vlak...&lt; at &gt;gmail.com: typo in memcached wiki http://code.google.com/p/memcached/issues/detail?id=274 another typo: http://code.google.com/p/memcached/wiki/NewConfiguringServer s/maxiumum/maximum also noticed this strange formatting: ... you may receive is 5 &lt;b&gt;12. Always leave a few extra slots ... should rather be: ... you may receive is 512. &lt;b&gt;Always leave a few extra slots ... </pre> memcached< at >googlecode.com 2012-05-20T17:38:30 http://permalink.gmane.org/gmane.comp.web.cache.memcached/14243 <pre>Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 274 by vlak...&lt; at &gt;gmail.com: typo in memcached wiki http://code.google.com/p/memcached/issues/detail?id=274 http://code.google.com/p/memcached/wiki/NewInstallFromPackage s/rececnt/recent </pre> memcached< at >googlecode.com 2012-05-20T17:31:39 http://permalink.gmane.org/gmane.comp.web.cache.memcached/14242 <pre> cmd_flush increasing means your application, or some cron, or some human, or some internet script (if your instance isn't protected) is issuing the command "flush_all" over and over. Also, your version is very old, but I doubt that's what's causing your flushes to happen :) -Dormando </pre> dormando 2012-05-11T22:35:16 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.web.cache.memcached