Search squid archive

Re: rock questions ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/23/2013 03:56 AM, Omid Kosari wrote:
> I am using rock on one of SSD drives to check its performance .
> 
> 
> before choosing rock the filesystem was reiserfs because it shows good
> performance in huge number of little files but i read somewhere the rock
> uses one big file . so i choose ext4 with discard to got the benefits of
> discard/trim .
> 
> the rock creates one file with the name rock in /cache2 directory with the
> size 105906MB from begin and still it has same size . but "df " shows 27%
> used and grows each day .


This is normal. The db file is initialized using ftruncate(). Until the
db file is filled with content, there will be a difference between the
size of the db file shown by "ls" and the amount of space actually
occupied by that file on disk (shown by "df").


> 1. is the max-size=31000 is the maximum size rock may store ? 

Max-size is the maximum size of a single cache_dir entry. In SMP
environment (i.e. multiple workers and/or multiple Rock diskers), the
maximum usable max-size value for official Rock implementations is
approximately 32752 bytes (32KB - sizeof(Rock::DbCellHeader), to be
precise).

This ~32KB limit comes from SMP sharing requirements. It is eliminated
by the Large Rock project:
http://wiki.squid-cache.org/Features/LargeRockStore

I do not think there is currently any diagnostic that will warn you that
your max-size exceeds the largest supported value. This a bug,
complicated by the fact that the largest supported value depends on
whether your configuration uses diskers, which, in turn, is a
non-trivial question to answer in general. If you use 32000 or a similar
value, you should be OK regardless of these complications.


> 2. is my fstab line shows bellow optimal for rock ? i have created it with
> "mkfs.ext4 /dev/sdb" on OCZ-VERTEX3 120GB

As discussed further below, I would not be able to answer that question
anyway, but please note that you are posting from a Nable.com interface
that eats all quoted lines such as your "fstab lines shown below". We do
not know what you actually posted because of that nibbling by Nable
software outside our control.

[ Rant: I wonder if this mailing list should start rejecting all Nable
posts both because those posts often come with critical information
stripped and because they lack context? Perhaps somebody who likes Nable
can approach Nabble.com and ask them to at least fix their nibbling bugs?]



> 3. it seems the the disk is more idle since switched to rock . how to force
> it use the disk more aggressive ?

You may need to define "more aggressive" for the above question to be
clearer.

In general, Squid will cache everything that HTTP rules and your
configuration allow it to cache. If you want to cache more, you either
need more traffic or a more "permissive" configuration. Please keep in
mind that max-size is one of those configuration limits. Due to this
size limit, an official SMP Rock cache_dir will not cache [large]
objects that a UFS-based cache_dir without max-size will cache.

However, one should always start from higher level metrics that are
important to one's deployment environment (response time, bandwidth
savings, robustness, etc.). Making sure that Squid caches everything is
often (but not always) the wrong optimization approach.


> 4. the following is output of dumpe2fs of that drive . is it better to
> resize the block size to 32KB which is the size of rock store size ? any
> other suggestion for filesystem ?
> 
> dumpe2fs /dev/sdb | more


Same "Nable nibbling at your post" problem as discussed in question #2.

In my experience, preventing disk I/O queue overflows (and resulting
blocking of Squid worker processes) is the key here. There are many
parameters that affect that, especially parameters that deal with
OS-initiated flushing of disk write buffers. The optimal settings are
going to depend on your specific environment.

Will 32KB block size be always better than 16KB? Hard to say. In an
average environment, more than half of the stored objects are going to
be smaller than 16KB so it may not make sense to force the OS to load
all 32KB all the time (if that is what 32KB fs blocks will do).

Similarly, is ext4 better than ext2 or Reiser for Rock? I personally
find ext2 easier to tune correctly but YMMV.

For more specific (but far from comprehensive!) advice, please see
"Performance Tuning" at http://wiki.squid-cache.org/Features/RockStore


HTH,

Alex.





[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux