Thanks in advance for your help and patience :) This particular client is:
- openafs-client-1.6.2-1.el5.x86_64 The OS is: - Linux xxx.xxx.net 2.6.18-164.15.1.el5xen #1 SMP Wed Mar 17 12:04:23 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux (it is a dom0, but is running no VMs) - CentOS 5.4 The server is: - openafs-fileserver 1.6.1-1 x86_64 on Ubuntu Server OS is: - 3.2.0-29-generic #46-Ubuntu SMP - Ubuntu 12.04 LTS I'd like to repeal my earlier data.. turns out I didn't wait long enough... The behavior that is repeatable is this: - Soon after client restart, rsync is very fast.. less than a second, compared to rsync modules at 3-5 seconds - Then, immediately, or after a few iterations, it slows down to 40+ seconds. It stays this way for the duration (days, so far. no change). - Rsync times to rsync modules on the same destination host do not change. - The amount of data is small, as is the number of files (100k or less per file, and 100 or so files each time) - The files are always new. They are not maintained on AFS, they are sync'd TO AFS from a standard file system. They are never there already. - Network speeds are good On Mon, Jun 24, 2013 at 1:39 PM, Andrew Deason <[email protected]>wrote: > On Fri, 21 Jun 2013 16:26:22 -0700 > Timothy Balcer <[email protected]> wrote: > > > This seems counter intuitive... the 100 or so files do not go over the > > 500,000 block cache size. They are fairly small (10's to 100's of > > kilobytes). Why would increasing cache size impact performance > > Negatively in such a case? > > When you say 500,000 or 50,000, etc, you mean 50,000... KiB? So, a > 500MiB vs 50MiB cache? About how big is the entire amount of data pushed > to AFS compared to the cache size? > > Anyway, one _guess_ as to why a larger cache may be slower for that is > that you're invalidating/overwriting a larger amount of data in the > cache. That is, for the 50M cache, you're writing and overwriting <=50M > of data on disk; for the 500M cache, you're writing and ovewriting >50M > of data, possibly all over the disk as we kick out different things from > the cache. If we're limited to overwriting 50M of disk data, the disk > i/o may perform better since our i/o is able to stay inside various > caches at lower levels (OS page cache, disk or controller caches, etc). > If you're not actually using the cached data, the cache can easily be a > hindrance to performance, and a larger cache can make that worse. > > That's just a guess, but I think it's one way you could see the larger > cache seem to perform more slowly. If you want to get more information, > you could run fstrace while the copies are running and provide that. And > as Jeffrey said, details of the platforms and versions in question would > be useful to have, though as I recall, you are running Linux. The > filesystems in use could be useful to know, too. > > -- > Andrew Deason > [email protected] > > _______________________________________________ > OpenAFS-info mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-info > -- Timothy Balcer / IT Services Telmate / San Francisco, CA Direct / (415) 300-4313 Customer Service / (800) 205-5510
