On Fri, Feb 21, 2014 at 12:13 AM, Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > On 02/15/2014 06:12 AM, Nikolai Gorchilov wrote: >> I'm trying to avoid the following scenario (excerpt from store.log): >> >> 1392406208.398 SWAPOUT 00 00000000 8C2B9C51268EFEEDEB33FB9EC53030A1 >> 200 1392406217 1382373187 1394998217 image/jpeg 21130/21130 GET >> http://www.gnu.org/graphics/t-desktop-4-small.jpg >> 1392406242.459 SWAPOUT 00 00000000 8C2B9C51268EFEEDEB33FB9EC53030A1 >> 200 1392406217 1382373187 1394998217 image/jpeg 21130/21130 GET >> http://www.gnu.org/graphics/t-desktop-4-small.jpg >> >> First request was served by kid1. It fetched the object by >> HIER_DIRECT, memory cached it, and stored it to it's storage (say >> /S1). >> Seconds later, the same request arrives to kid2. It retrieves the >> object from shared memory (hierarchy code NONE), then swaps it out to >> it's own storage (say /S2). >> >> The question is how to prevent kid2 from saving the duplicate object? >> Is there any mechanism other then switching memory_cache_shared off? > > Yes, rock store. If you get the above behavior while using rock > cache_dirs (shared by all workers) and no other cache_dirs, then it is a > bug. Nope, it's aufs. Due to my stalled connections issue with the rock store I'm forced to go with aufs for 32K. objects. Niki
