Hello list, What would be the best zpool configuration for a cache/proxy server (probably based on squid) ? In other words with which zpool configuration I could expect best reading performance ? (there''ll be some writes too but much less). Thanks. -- Francois
Francois, Your best bet is probably a stripe of mirrors. i.e. a zpool made of many mirrors. This way you have redundancy, and fast reads as well. You''ll also enjoy pretty quick resilvering in the event of a disk failure as well. For even faster reads, you can add dedicated L2ARC cache devices (folks typically use SSDs for very fast (15k RPM) SAS drives for this). -Greg Francois wrote:> Hello list, > > What would be the best zpool configuration for a cache/proxy server > (probably based on squid) ? > > In other words with which zpool configuration I could expect best > reading performance ? (there''ll be some writes too but much less). > > > Thanks. > > -- > Francois > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > >
Hi Fran?ois, You should take care of the recordsize in your filesystems. This should be tuned according to the size of the most accessed files. Maybe disabling the "atime" is also good idea (but it''s probably something you already know ;) ). We''ve also noticed some cases where enabling compression gave better I/O results (but don''t use gzip), but this should be done only if your machine is exclusively running the proxy server. About the topology of your pool, in a performance matter, prefer some striped mirrors if you can afford it, or raidz if not ! HTH, Jnm. -- Francois a ?crit :> Hello list, > > What would be the best zpool configuration for a cache/proxy server > (probably based on squid) ? > > In other words with which zpool configuration I could expect best > reading performance ? (there''ll be some writes too but much less). > > > Thanks. > > -- > Francois > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Hi Francois,
I use ZFS with Squid proxies here at MIT. (MIT New Zealand that is ;))
My basic set up is like so.
- 2 x Sun SPARC v240''s dual CPU''s with 2 x 36 GB boot disks
and 2 x 73
GB cache disks. Each machine has 4GB RAM.
- Each has a copy of squid, Squidguard and an apache server.
- Apache server, serves .pac files for client machines and each .pac
file binds you to that proxy.
- Clients request a .pac from round robin DNS "proxy.manukau.ac.nz"
which then gives you the real
system name of one of these two proxies.
Boot disks are mirrored using disksuite and cache and log file systems
are ZFS. My cache pool is just a mirrored
pool which is then split into three file systems. Cache volume is
restricted to 30 GB in squid config. Max cache object size
is 2MB. Internet bandwidth available to these machines is ~15Mbit/s.
[root at xxxxx /]#> zpool status
pool: proxpool
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
proxpool ONLINE 0 0 0
mirror ONLINE 0 0 0
c1t2d0 ONLINE 0 0 0
c1t3d0 ONLINE 0 0 0
errors: No known data errors
[root at xxxxx /]#> zfs list
NAME USED AVAIL REFER MOUNTPOINT
proxpool 39.5G 27.4G 27K /proxpool
proxpool/apache-logs 2.40G 27.4G 2.40G /proxpool/apache-logs
proxpool/proxy-cache2 29.5G 27.4G 29.5G /proxpool/proxy-cache2
proxpool/proxy-logs 7.54G 27.4G 7.54G /proxpool/proxy-logs
This config works very well for our site and has done for several years
using ZFS and quite a few more
with UFS before that. These two machines support ~4500 desktops give or
take a few. ;)
A mirror or stripe of mirrors will give you best read performance. Also
chuck in as much RAM as you can
for ARC caching.
Hope this real world case is of use to you. Feel free to ask any more
questions..
Cheers,
Scott.
Francois wrote:> Hello list,
>
> What would be the best zpool configuration for a cache/proxy server
> (probably based on squid) ?
>
> In other words with which zpool configuration I could expect best
> reading performance ? (there''ll be some writes too but much less).
>
>
> Thanks.
>
> --
> Francois
>
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
--
_________________________________________________________________________
Scott Lawson
Systems Architect
Information Communication Technology Services
Manukau Institute of Technology
Private Bag 94006
South Auckland Mail Centre
Manukau 2240
Auckland
New Zealand
Phone : +64 09 968 7611
Fax : +64 09 968 7641
Mobile : +64 27 568 7611
mailto:scott at manukau.ac.nz
http://www.manukau.ac.nz
__________________________________________________________________________
perl -e ''print
$i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);''
__________________________________________________________________________
Hello Jean-No?l,
Thursday, April 9, 2009, 3:39:50 PM, you wrote:
JNM> Hi Fran?ois,
JNM> You should take care of the recordsize in your filesystems. This should
JNM> be tuned according to the size of the most accessed files.
I don''t think this is necessary and it will rather do more harm than
good in the squid case.
With default recordsize of 128KB zfs will use a smaller block size for
smaller files - recordsize is a maximum size (limit) of a block and
not a fixed block size. This is a common misconception about zfs.
Now, under normal circumstances, when for example Oracle creates large
file zfs will create the file using block size of recordsize (if file
is larger than recordsize) but in most cases Oracle (or any other
programs) will access the data in a much smaller logical block
(db_block_size in oracle case) which in turn will force zfs to read
entire fs block in order to verify it''s checksums. Now if the working
set is larger than a memory and reads are mostly random reads of a
logical size being much smaller than zfs recordsize it will negatively
impact the performance.
In squid case most (all?) files will be read entirely in sequential
manner or not at all so generally the largel fs block the better which
means that default 128KB (which is the maximum supported value) is
best options. If file is for example 8K in size then zfs will use 8KB
fs block if recordsize is >=8KB.
The only issue I''m aware of is a tail block (last block in a file)
which if considerably smaller than current fixed block size for the
file will unnecessary allocate too much disk space. Lowering the
recordsize should alleviate extra disk usage (depending on particular
workset) but generally won''t matter from the performance point of view.
--
Best regards,
Robert Milkowski
http://milek.blogspot.com