> There's also another issue, which is that setting the transfer size too > large may impact fileserver performance on large files for which there is > lots of demand, because currently only one client can be fetching from a > given file at a time. While it's probably a good idea to change that in > the long term, doing so would probably mean non-trivial changes to the way > the volume package works, so it's not going to be a quick fix. > > In addition, a large transfer size means that when you access a large file, > you have to wait longer before you get to access any of it. So while the > average performance goes up if you are transferring entire large files, you > lose if you are only interested in a couple of pages out of a large > database.
Hrrm.. how often is this the case that someone is running a database out of AFS? For gigabit and other fast networks (aka, infiniband), I'm finding that a chunksize of 20 limits me to about half a gigabit, and a chunksize of 18 is just way too small. I just ran a couple of tests on what might very well be the worlds first InfiniBand connected AFS server. The server is a dell 2650 running Debian linux (kernel 2.6.11-1-686-smp), with a 5 disk raidset for the /vicepa partition, with an XFS filesystem. Local benchmarks (using plain old 'dd') show around 100mb/sec read throughput on a 4GB file. The client machine is a dual opteron, with kernel 2.6.11, and a 1.3.79 or so afs client. I'm running the IPoIB infiniband drivers in the 2.6.11 kernel release. The client machine has a 100mb memcache. Reading a 9GB file via NFS with wsize=32k,rsize=32k results in approximagely 65MB/sec (as reported by 'dd if=file of=/dev/null bs=65536' (65563500 bytes/sec) Reading a 9GB file via AFS with chunksize=18 gives around 5-7MB/sec. Reading the same file via AFS with chunksize=20 gives around 55MB/sec. (55155504 bytes/sec) _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
