sön 2007-01-21 klockan 21:11 +0100 skrev Marco Barbero: > cache_dir: > ---------- > - SquidBook says about 20MB for every user accessing the proxy I don't have a number on that. The rule 10MB per GB of cache_dir + OS requirements and cache_mem usually works out quite well. > - A lot of people suggest to monitor total traffic for a week and use this > value for cache_dir More accurately a week's worth of cache_dir. The size cache_dir grows to after a weeks operation. Beyond that there is very limited benefits from growing the cache further and the remaining memory is perhaps better used as cache_mem. > - the book "How To Accelerate Your Internet" (bwmo.net) says that size > higher than 18GB are not a good choice It's nearly impossible to place an exact number. It depends on the amount of traffic. > - cache_dir placed on a dedicated disk must be 20% smaller than total size > (squid.conf). Some people suggests 30-50% smaller....What about? Most UNIX filesystems requires at least 20% free space at all times to operate properly. If the filesystem is filled beyond that performance starts to degrade due to fragmentation. > And then...are these suggestions valid for dedicated partition too? The filesystem fill limit is unchanged if it's a shared or dedicated partition. I always recommend dedicated partitions for the cache if you cannot have dedicated disks. This because there is a lot of data moving in the cache directory, and should there be a filesystem problem due to a power failure or similar it's not a major disaster if the cache is lost. If you can it's better to dedicate disks to the cache. This gives better performance. The system disk can be used for logs and swap. > - L1 value: > cache_dir/416 (old post from Henrik) > cache_dir/500 (other post read here) > cache_dir/256 * 0.6 (a more recent post from Henrik) > Opinions? They are all about the same. > -L2 value: 256 > Duan Wessel suggest to try 32/512 with great cache_dir sizes. > ?? I suggest sticking to 256. But it's no big deal. If you increase L2 you should also decrease L1. The cache structure can be defined by the equation N = L1 * L2 * L2 * 2, where N is the number of cached objects. A too small L2 degrades performance due to the directory blocks not being fully utuilized. A too large L2 degrades performance due to directory lookups being more expensive. And a very large L2 has negative impacts on Squid cache maintenance even if you use a filesystem which handles very large directories fine. It all sums up to 256 being a quite reasonable balance for most OS:es. > ufs/aufs > ----------- > -ufs with less than 5req/sec (Duan Wessel) > -aufs for >30req/sec (Henrik) > ?? ufs won't realistically sustain more than about 30req/s and above that you must use aufs. but aufs adds a bit of overhead, and for very low load <5req/sec you may be better suited using the trivial ufs implementation. This is less significant in never versions (2.4 or later I think). > cache_mem > ------------- > - Squidbook says: never greater that 1/4 physical RAM. Yes. > - Henkrik says 16 MB is quite suitable for most installations (no more than > 32MB) Yes. > - Duan Wessel says to set it low than increase if there is RAM unused. > ?? Yes. > What do you think about? All true. And no conflict. * Never set cache_mem larger than 1/4 of the physical ram * Start with the default 16MB, or maybe 32MB. * If you when the cache has been filled find you have a lot of ram unused then maybe increase cache_dir further. But only if there is a lot of ram free. The OS also requires a fair bit of memory for filesystem and networking buffers. Regards Henrik
Attachment:
signature.asc
Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel
