[OpenAFS] Catastrophic r/w performances on Linux OpenAFS client

lstep@adequat.net lstep@adequat.net
Mon, 5 Jan 2004 10:38:35 +0100


No, both machines are just separated by a simple switch, no firewall, no 
filtering rules at all.
About the specs of the machines, the server is a PII UP 500Mhz with 512MB of 
RAM and several SCSI disks. The client is a PIII SMP 500Mhz with 512MB of RAM 
and a IDE disk.
I tried to access files from a Windows machine where I installed Kerberos + 
OpenAFS client, and I get the same problem, that is, at most 5KB/s. It means 
the problem is on the server?

Another thing I noticed, is that the problem is not just on write access, but 
also on read access, which is really really strange.
Aren't there any tool to see what's happening?

Thanks,
Luc

On Friday 02 January 2004 19:04, Michael Loftis wrote:
> No firewalls, traffic shapers, running on either machine, at all?  Also you
> didn't mention system hardware specs either...
>
> --On Friday, January 02, 2004 12:46 +0100 lstep@adequat.net wrote:
> > Hello,
> >
> > I've installed a test OpenAFS server (debian packages, v1.2.10, dbserver
> > and  fileserver on a same machine) and a client on another machine
> > (debian  package, v1.2.10). I made a volume for one of my user (the only
> > one :-) and  I'm trying to make it have some decent performance.
> >
> > Everything works fine except it's exceptionnaly slow. The client local
> > cache  seems to be correctly configured:
> >
> > bash-2.05b$ fs getcacheparms
> > AFS using 13 of the cache's available 100000 1K byte blocks.
> >
> > But when I try to create a file, I see a bottleneck where it never goes
> > above  5KB/s! In fact, it seems locked to 5KB/s
> > When trying to create a simple file of 1Mo:
> >
> > bash-2.05b$ dd if=/dev/zero of=fichier.raw bs=1024k count=1
> > 1+0 records in
> > 1+0 records out
> > 1048576 bytes transferred in 190.847965 seconds (5494 bytes/sec)
> >
> > Or even a file of 256k:
> >
> > bash-2.05b$ dd if=/dev/zero of=fichier.raw bs=256k count=1
> > 1+0 records in
> > 1+0 records out
> > 262144 bytes transferred in 46.871588 seconds (5593 bytes/sec)
> >
> > I tried to create a file up to 2777 bytes, where it still makes 5KB/s.
> > Below,  it creates the file at 653Ko/s, but I guess it's not really
> > representative,  as the filesize is so small.
> > But, for any size, it *always* transfer the data exactly at 5KB/s.
> >
> > I even activated the storebehind option, but it didn't change anything:
> >
> > bash-2.05b$ fs storebehind -allfiles 2048 -verbose
> > Default store asynchrony is 2048 kbytes.
> >
> > Making a tcpdump on the client machine, I noticed a lot of traffic, the
> > packet  sizes set to the maximum (I think):
> >
> > 10:03:59.451896 192.168.0.7.7000 > 192.168.0.36.7001:  rx ack (65) (DF)
> > 10:03:59.452007 192.168.0.36.7001 > 192.168.0.7.7000:  rx data (1440)
> > (DF) 10:03:59.453560 192.168.0.7.7000 > 192.168.0.36.7001:  rx ack (65)
> > (DF) 10:03:59.453730 192.168.0.36.7001 > 192.168.0.7.7000:  rx data
> > (1440) (DF) 10:03:59.453777 192.168.0.36.7001 > 192.168.0.7.7000:  rx
> > data (1440) (DF) 10:03:59.960355 192.168.0.36.7001 > 192.168.0.7.7000: 
> > rx data (1440) (DF) 10:03:59.961905 192.168.0.7.7000 > 192.168.0.36.7001:
> >  rx ack (65) (DF) 10:03:59.962009 192.168.0.36.7001 > 192.168.0.7.7000: 
> > rx data (1440) (DF) 10:03:59.963557 192.168.0.7.7000 > 192.168.0.36.7001:
> >  rx ack (65) (DF) 10:03:59.963736 192.168.0.36.7001 > 192.168.0.7.7000: 
> > rx data (1440) (DF) 10:03:59.963784 192.168.0.36.7001 > 192.168.0.7.7000:
> >  rx data (1440) (DF) 10:04:00.470368 192.168.0.36.7001 >
> > 192.168.0.7.7000:  rx data (1440) (DF) 10:04:00.471921 192.168.0.7.7000 >
> > 192.168.0.36.7001:  rx ack (65) (DF) 10:04:00.472072 192.168.0.36.7001 >
> > 192.168.0.7.7000:  rx data (1440) (DF) 10:04:00.473632 192.168.0.7.7000 >
> > 192.168.0.36.7001:  rx ack (65) (DF) 10:04:00.473760 192.168.0.36.7001 >
> > 192.168.0.7.7000:  rx data (1440) (DF) 10:04:00.473806 192.168.0.36.7001
> > > 192.168.0.7.7000:  rx data (1440) (DF) 10:04:00.980346
> > 192.168.0.36.7001 > 192.168.0.7.7000:  rx data (1440) (DF)
> > 10:04:00.981915 192.168.0.7.7000 > 192.168.0.36.7001:  rx ack (65) (DF)
> > 10:04:00.982026 192.168.0.36.7001 > 192.168.0.7.7000:  rx data (1440)
> > (DF) 10:04:00.983590 192.168.0.7.7000 > 192.168.0.36.7001:  rx ack (65)
> > (DF) 10:04:00.983681 192.168.0.36.7001 > 192.168.0.7.7000:  rx data
> > (1440) (DF) 10:04:00.983711 192.168.0.36.7001 > 192.168.0.7.7000:  rx
> > data (516) (DF) 10:04:01.490370 192.168.0.36.7001 > 192.168.0.7.7000:  rx
> > data (1440) (DF)
> >
> > (192.168.0.36 being the client machine, and 192.168.0.7 being the OpenAFS
> > server).
> >
> > The options I set where the one set by default on the afs.conf file
> > created by  the debian package script (I added the chunksize, without any
> > change):
> >
> > /usr/sbin/afsd -stat 2800 -dcache 2400 -daemons 5 -volumes 128 -chunksize
> > 20  -dynroot -fakestat -afsdb -nosettime
> >
> > I'd like to know if there is some parameter that I might have
> > forgotten/not  set that locks the bandwidth to 5KB/s, or how can I debug
> > that problem, I  don't know of any way/tools to see what's wrong.
> >
> > Thanks for your help,
> > Luc
> > _______________________________________________
> > OpenAFS-info mailing list
> > OpenAFS-info@openafs.org
> > https://lists.openafs.org/mailman/listinfo/openafs-info
>
> --
> Undocumented Features quote of the moment...
> "It's not the one bullet with your name on it that you
> have to worry about; it's the twenty thousand-odd rounds
> labeled `occupant.'"
>    --Murphy's Laws of Combat

-- 
Luc Stepniewski <luc.stepniewski@adelux.fr>
Adelux - Securite, Linux  Public key: <http://lstep.free.fr/pubkey.txt>
Key BC0E3C2A fingerprint = A4FA466C68D27E46B427  07D083ED6340BC0E3C2A