-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29/12/2014 11:46 a.m., HackXBack wrote: > you're explain is complicated for me and sorry for that but i want > to understand more if that not bother you. at first lets talk > about cache_dir what you are telling me is to do rock and aufs for > each HDD what you mean is like this : cache_dir rock /cache01/rk > 50000 120 256 max-size=31744 cache_dir aufs/cache01/au 400000 961 > 256 min-size=31745 > > for each HDD but in this way i will consume only 450 GB from > 3TerraByte and this is not enough for me and will be full very fast > especially for caching videos and large files and this is a problem > while i cant add more rams for this hardware, so what is the > solution for this ? It is a starting point. The size parameter on the AUFS cache_dir can be increased as needed later with only a "squid -k reconfigure" and no data loss. Just set the L1/L2 cache parameters suitable for a large cache size, they cannot be changed easily. NP: I also notice your L1 parameter is 961 ... both numbers need to be even (multiples of 2, or better powers of 2). 15 TB cache (5x 3TB) may be too much and never filled if our traffic is mostly small objects. Only if your users request a lot of video will it be used. If you are expecting a large number of under-32KB objects you can double the rock cache to 100GB. But it gets slow to manage the Rock DB if it gets too big (rock is a singe database file containing DB records/slots with an object in each). The key problem(s) currently is that you have/had too many cache_dir on each HDD. The memory required to handle them is bigger than the machine contains and they are competing for disk I/O bandwidth. Both of which slow Squid down - sometimes a lot. > > also you said that is for only http objects , so what about caching > https files like youtube videos ? why i cant take these traffic > also ? HTTPS is HTTP. Just using a TLS transport instead of TCP transport. When it comes to caching there is no difference. Amos -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUoNySAAoJELJo5wb/XPRjxIYH/Rc8yzu4tZ1MKwg5dfJYWINl GKeIESk1bZWGBqRYWGHjRihy4NlwYqWB9qD0TYdskbGW0VgpcRH97OBmroSD6BZn EPVGwLhINpqJo7PEb9TIg7FIXCoI8ADH5rKUmq/5/SCoSuF4cOIq9tFZuQaBOjT0 PH2OYFuVd+uJ3AA5uWtulzBDMAPyDW5V7RraZYokBPws+kRoIE0r60oqGbFUuwLo VXd+d97E1HRL4uPsaLbZuVG/VenbGzm1/ppn2zn5pSm5/cmqFYJWjg5686Qcp+1x wY/xxMyxrAO4FNcMtB8VVSd+EnLGFbHvc6dc3F3bOK+EUNZJCc/TPoVY7DhwcJw= =zzIG -----END PGP SIGNATURE----- _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
