Seit einigen Wochen habe ich eine OwnCloud 8 Installation auf dem MicroServer am Laufen. In dieser OwnCloud habe ich mein 27 GB großes Bildarchiv abgelegt, da man es auf diese Weise auf allen Rechnern zur Verfügung hat. Die Geschwindigkeit der Synchronisation hat mich allerdings bisher nicht wirklich überzeugt. Sie ist nicht mit einem rsync auf den gleichen Server zu vergleichen. Rsync lastet die Gigabit Ethernet Verbindung fast komplett aus. OwnCloud dagegen schlummert mit maximal wenigen MB/s vor sich hin. Und scheint zwischen den einzelnen Dateien eine großzugige Pause einzulegen. In diesem Artikel habe ich einige Tricks und Kniffe gesammelt, die helfen OwnCloud schneller zu machen. 

Optimierungen am Netzwerk

Mein Server hängt an einer FritzBox, für die ich den DynDNS-Dienst myFritz von AVM benutze. Weil das Zertifikat auf die DynDNS-Domain ausgestellt wurde, muss man in den OwnCloud Clients die Domain eintragen. Dadurch werden Anfragen aber über das Internet geroutet:

$ traceroute to xxxx.myfritz.net (109.42.xxx.xx), 30 hops max, 60 byte packets
 1 fritz.box (192.168.179.1) 0.347 ms 0.426 ms 0.504 ms
 2 ip-109-42-xxx-xx.web.vodafone.de (109.42.xxx.xx) 3.973 ms !X 3.982 ms !X 3.979 ms !X

Man beachte die langen Latenzen (Mobilfunk). Trägt man nun in der /etc/hosts Datei folgendes ein

192.168.179.28 xxxx.myfritz.net

liefert traceroute eine Latenz von unter einer Millisekunde und routet direkt zum Ziel. Bei IPv6 ist dieser Schritt übrigens nicht nötig, Der Router erkennt dann von selbst, dass diejenige IP ‚ihm gehört‘ und fragt garnicht erst den DNS Server des Hosters. Dazu muss man aber eine IPv6 Adresse vom Provider erhalten haben und auch im Heimnetz solche IPs per DHCPv6 verteilen. OpenMediaVault hat mit IPv6 leider noch seine Probleme. Auch auf manchen Android-Geräten scheint IPv6 fehlerhaft implementiert, wie mir AVM bestätigte.

Update 21.04.2015:  Im WLAN blockierte bei mir die FritzBox die Auflösung des Domainnamens. Owncloud funktionierte dadurch im WLAN nicht (ohne hosts-Eintrag). Um das zu ändern, muss man den DNS-Rebind-Schutz für diese Domain deaktivieren. Das geht unter Heimnetz > Netzwerkeinstellungen.

Update 28.05.2016: Es gibt leider ein ernstzunehmendes Problem mit IPv6. Die Owncloud-App für Android hat im WLAN einen Bug, es kommt keine Verbindung zustande. Dieser Bug wird hier  getrackt und hoffentlich bald gefixt. Wenn man diesen Bug kennt, kann man Die App halt nur noch von draussen nutzen. Nervig ist es nur für den Foto-Upload.

 

Eine weitere gute Idee ist auch das aktivieren von Jumboframes. Standardmäßig ist die Nutzlast (Maximum Transfer Unit – MTU) bei Ethernet auf 1500 Bytes beschränkt. Dieser Wert wird aber vorallem aus Gründen der Abwärtskompatibilität benutzt. Bei Gigabit Ethernet sollte ein größerer MTU kein Problem sein. Dazu muss man auf beiden Seiten der Verbindung

$ sudo ifconfig eth0 mtu 9000

setzen. Diese Änderung ist erstmal nicht permanent. Um die festzuklopfen,  ändert man den MTU-Wert in der Datei /etc/network/interfaces. Ich kann allerdings nicht versprechen, dass alle Umgebungen damit klar kommen.

Update:  FritzBoxen können überhaupt nicht mit JumboFrames umgehen. Sehr schade. Das erklärt auch meine Verbindungsabbrüche, wenn ich sie aktiviert habe.

Optimierungen bei OwnCloud

OwnCloud ist out-of-the-Box sehr konservativ eingestellt und vorallem so ausgelegt, dass es auf auf Webservern läuft, wo man keine Rootrechte hat. Zuhause sollte man unbedingt folgende Änderungen machen:

  1. von AJAX auf richtige Cronjobs umstellen. Das beschleunigt aber vorallem die Weboberfläche.
  2. Statt SQLite eine richtige mySQL-Datenbank einsetzen. Diese hat erheblich mehr Performance.
  3. Die mySQL Einstellungen optimieren
  4. Ein PHP Cache Paket installieren, z.B. PHP APC. Dieses soll zumindest die Weboberfläche um den Faktor 3 beschleunigen.
  5. Umgebungsvariablen für den Owncloud Client setzen.
  6. Update: PHP-FPM und NGINX besser konfigurieren

Cronjobs

Für die Cronjobs benutzt man auf einem Debian den Befehl

$ sudo -u www-data crontab -e

Dies bearbeitet die Cronjobs des Benutzers www-date. Das ist wegen den Rechten wichtig. Dort trägt man die Zeile

*/20 * * * * php -f /var/www/owncloud/cron.php

ein. Dadurch wird dann alle 20min der Owncloud-Cronjob ausgeführt. In der Administrationsoberfläche kann man dann von AJAX auf Cron umstellen und prüfen, ob der Cronjob ausgeführt wird.

Umziehen auf eine MySQL-Datenbank

Das Umstieg von der Dateibasierten sqlite-Datenbank auf mySQL ist komplizierter. Man muss sich damit gut mit mySQL auskennen. Hier gibt es eine Anleitung für OC7. Im Prinzip muss man wie folgt vorgehen:

Das Paket mysql-server installieren

sudo apt-get mysql-server

Bei der Installation vergibt man das Root-Passwort. Nun verhindet man sich mit der Konsole:

$ mysql -u root -p

Man sollte für OC einen eigenen Benutzer haben, der nur auf die OC-Datenbank zugreifen kann. Dazu benutzt man folgende mySQL Befehle

CREATE DATABASE <dbname>
<span style="line-height: 1.5;">CREATE USER <username>@localhost IDENTIFIED BY <password></span>

Die Rechte an der Datenbank gibt man dem neun Benutzer mit

<span style="line-height: 1.5;">GRANT ALL PRIVILEGES ON <dbname> . * TO <username>@localhost;</span>

Verlassen kann man die mySQL Konsole mit exit; Nun das Skript /var/www/owncloud/occ ausführbar machen und ausführen:

$ sudo -u www-data chmod +x occ 
$.sudo -u www-data /occ db:convert-type –password=”<password>” –all-apps <username> localhost <dbname>

MySQL Einstellungen optimieren

Das Skript mySQLTuner gibt Tipps, was man verbessern kann. Die Einstellungen einer mySQL-Datenbank befinden sich unter Debian in /etc/mysql5/my.cnf. Nach Änderungen an dieser Datei muss man mySQL neustarten.

Folgende Variablen habe ich geändert. Mein Server hat 4 GB RAM.

  • innodb_buffer_pool_size von 128 MB auf 1 GB
  • query_cache_size von 16 MB auf 64 MB
  • tmp_table_size von 16 MB auf 32 MB
  • max_heap_table_size von 16 MB auf 32 MB

Variablen zeigt man auf der mySQL Konsole so an und kann sie auch ändern:

> SHOW VARIABLES LIKE 'query_cache_size';
<span class="kwd">> SET</span><span class="pln"> GLOBAL query_cache_size </span><span class="pun">=</span> 33554432<span class="pun">;
</span>

Diese Änderungen verfallen aber nach einem Neustart. Will man sie behalten, muss man sie in der my.cnf eintragen. Man sollte sich immer informieren, welche Werte gut sind. Viel hilft nicht immer mehr! Manche Caches sollten eine bestimmte Größe nicht überschreiten

PHP Cache aktivieren

Dazu muss man lediglich die entsprechenden Pakete installieren und den Webserver neustarten

$ sudo apt-get install php-pear php-apc $ sudo service nginx restart

Konfigurieren muss man eigentlich nichts. Der Cache verbessert die Verarbeitungszeit der PHP-Skripte auf dem Server um etwa den Faktor 2x. Das ist natürlich insbesondere für dien Zugriff via Browser gut, aber auch der Sync-Client nutzt letztendlich HTTP-Aufrufe von PHP Skripten zur Dateiübertragung.

Umgebungsvariablen setzen

Bei Owncloud ist der Upload über den Browser erheblich schneller als über den Client. Dies liegt unter anderem daran, dass der Client seine Uploads in sog. Chunks einteilt, die standardmäßig nur 10 MB groß sind. Eine automatische Anpassung an die tatsächliche Bandbreite findet leider nicht statt. Man sieht dies sehr schön, wenn man in der Systemüberwachung den Netzwerkverkehr anzeigt.

Die Umgebungsvariable OWNCLOUD_CHUNK_SIZE ändert ihr  unter Linux in der .profile

OWNCLOUD_CHUNK_SIZE=104857600
export OWNCLOUD_CHUNK_SIZE

Dieser Wert entspricht 100 MB und ist für Gigabit Ethernet ausgelegt. Danach einmal abmelden und ihr solltet ordentliche Uploadraten mit dem Client erhalten.

Man sollte auch immer bedenken, dass die hier genannten hohen Geschwindigkeiten nur mit großen Dateien an einem Stück zustande kommen. Bei Bildarchiven z.B. macht OC trotz der Chunksize zu viele Unterbrechungen. Das wird mit folgender Grafik klar (Chunk Size=50 MB, viele 4-6MB große Dateien):

Owncloud NetzwerkstatistikOwncloud Network Speed

Update: PHP-FPM und NGINX

Bei einem anderen Projekt habe ich gesehen, dass die Anzahl der Prozesse, die PHP-FPM starten darf, zu gering war. Es treten dann Warnungen in den Logfiles auf. Man sollte die Einstellung erhöhen, bis keine Warnungen mehr auftreten.

# /etc/php5/fpm/pool.d<dein-pool>.conf
pm = ondemand
pm.max_children = 32
pm.max_requests = 200
pm.process_idle_timeout = 10s

Diese Einstellungen sind beispielhaft. Durch die Einstellung ondemand werden Prozesse bei Bedarf erzeugt und nicht vorgehalten, was bei Umgebungen mit relativ geringer Last weniger RAM verbraucht [Quelle].

Als Webserver nutze ich Nginx. Bei Apache gibt es natürlich ähnliche Optionen, da verweise ich aber auf Google. Auch in den NGINX-Einstellungen kann man etwas optimieren:

# /etc/ngins/nginx.conf
worker_processes 4; # i.d.R. die Anzahl der CPU-Kerne
gzip on;
gzip_disable „msie6“; # IE 6 deaktivieren
gzip_vary on;
gzip_min_length 10240; # erst ab 10 KB komprimieren
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript # nur Textdateien komprimieren, keine Bilder etc.

Dies verbessert die Performence bei der Komprimierung, da nicht ,mehr jede noch so kleine Datei komprimiert wird. Das Komprimieren von Bildern, Videos usw. kostet nur CPU-Leistung, bringt aber wenig. Daher nur bei Text-Dateien.

Es gibt noch sehr viele andere Einstellungen. Ich möchte hier nur einen Anreiz geben, sich dort einzuarbeiten.

 

Fazit

Nach allen Optimierungen erreiche ich Raten von 50-60 MB/s, (abhängig von der Dateigröße und nicht durchgehend). Die Änderung der Umgebungsvariablen und der Caches auf dem Server hat am meisten gebracht, auch das Routing hatte seinen Anteil. Meine 4 GB RAM auf dem Server sind nun deutlich voller (25% vs. 16%). OwnCloud erzeugt sehr viel Overhead durch die Datenbank, daher lässt sich die Geschwindigkeit nicht mit rsync vergleichen. Für Heimnetz-Geschwindigkeiten ist OwnCloud nicht ausgelegt, aber die Uploadgeschwindigkeit ist trotzdem erheblich besser als per VDSL auf einen fremden Server.

Die Einstellungen bei PHP-FPM und NGINX haben gefühlt etwas mehr Performance gebracht, ich hatte aber auch einen viel zu niedrigen Wert für die Anzahl der Prozesse voreingestellt.

Die Quelle meiner gesammelten Informationen möchte ich euch nicht vorenthalten. Das generelle Problem bei Internetrecherchen zu diesem Thema ist aber, dass sie meistens ältere OC Versionen betreffen.

 

 

Previous Post Next Post