Poor performance in test grid
Lukas Pirl
tahoe-dev at lukas-pirl.de
Wed Dec 25 13:16:44 UTC 2013
Hi Team Tahoe!
I really like the concept of tahoe-lafs so I tried it out.
Sadly, I was really disappointed when I experienced very poor
performance (~1.6 MB/s for reads and writes). I used multiple gateways
(SFTP via gvfs, SFTP via 'sftp' command, CLI) but it was slow in any case.
I would be very happy if someone would share an idea on how to fix this.
I'd love to use tahoe to backup my servers as a lot of Debian backups
could share a lot of files ;)
My setup looks like this:
* Hardware: Atom CPU (D525) @ 1.80GHz, Storage on SSD
* 30GB free disk space, ext4
* 3GB RAM free
* average system load: almost 0
* all servers on the same machine:
* 3 storage servers
* 1 introducer (obviously)
* 1 gateway server
$ tahoe --version:
allmydata-tahoe: 1.10.0
foolscap: 0.6.4
pycryptopp: 0.6.0.1206569328141510525648634803928199668821045408958
zfec: 1.4.24
Twisted: 13.2.0
Nevow: 0.10.0
zope.interface: unknown
python: 2.7.6
platform: Linux-debian_jessie/sid-x86_64-64bit_ELF
pyOpenSSL: 0.13.1
simplejson: 3.3.1
pycrypto: 2.6.1
pyasn1: 0.1.7
mock: 1.0.1
setuptools: 2.0
$ grep shares tahoes/gw/tahoe.cfg
shares.needed = 3
shares.happy = 2
shares.total = 10
I experienced the same issue on a similar machine with a Core 2 Duo @
2.6GHz.
I observed that while uploading, the gateway ate up 1 core completely.
After all data had been transferred (ex: Nautilus copy progress @
100%), the gateway and 2 storage servers ate up one core each for
quite a while (almost the same time it took to upload the file). After
that, the file-system call returned (ie. Nautilus closed the copy
dialog hat was stuck at 100%).
Uploading via network (20MB/sek) or on the same machine made almost no
difference.
Thanks in advance & happy Xmas!
Lukas
--
+49 174 940 74 71
More information about the tahoe-dev
mailing list