WordPress-Blog mit Themes in eine neue Domäne auf einem anderen Apache-Server umziehen

Gestern hat mich ein Problem meiner Frau etwas Nerven gekostet:
Sie erstellt gerade eine Webseite für eine Firma auf Basis von WordPress [WP] unter Einschluss des Pinnacle Themes. Ich selbst bin ehrlich gesagt kein Freund solcher viel zu komplexen und deshalb wenig performanten Themes. Aber ich hatte da nichts zu entscheiden.

Jedenfalls stand am gestrigen Morgen der Transfer der WP-Installation von einer gehosteten Testdomäne bei "1&1" zur endgültigen Zieldomäne des Auftraggebers an. Letztere wird auch gehostet - allerdings beim Provider "Strato". Unter "Hosting" verstehe ich dabei klassisches Web-Hosting: Man erhält auf einem Server einen per "chroot" abgesicherten Web-Space. Man teilt sich aber die Ressourcen des Webservers mit anderen Usern und hat keinerlei Kontrolle über die Serverkonfiguration selbst.

Schritte für einen WP-Umzug zu einer anderen Domäne und auf einen anderen Webserver

Zu bewältigen war also ein WordPress-Umzug zwischen zwei Domänen bei zwei klassischen deutschen Web-Hosting-Providern. Beide Provider nutzen Apache- und MySQL-Server. Man stellt sich den Umzugsprozess deshalb als gut beherrschbar vor. Als notwendige Teilschritte fallen einem sofort die folgenden ein:

  • Datenbank-Export vom Datenbankserver des alten Hosters (hier 1&1) auf ein eigenes Linux-System; den Export kann man mit PhpMyAdmin vornehmen. Wir erhalten dadurch ein Text-File mit den erforderlichen SQL-Statements für einen späteren Import und natürlich mit den Inhalten der Datenbankfelder selbst.
  • Änderung der Domain-Adresse [URL] und ggf. auch absoluter Server-Pfade in der SQL-Datei. Diesen Schritt kann man z.B. mittels eines schrittweisen "Search und Replace" unter "kate" oder einem anderen Linux-Editor vornehmen.
  • Datenbankimport des modifizierten SQL-Files in die Zieldatenbank eines MySQL-Servers beim neuen Provider; wieder mit PhpMyAdmin.
  • Kopieren der WordPress-Verzeichnisse und WP-Dateien per SFTP vom alten Web-Server (Webspace) auf einen Linux-Desktop und von dort weiter auf den Ziel-Webserver (Strato). Hierzu verwendet man ein FTP-Tool wie etwa Filezilla.
  • Änderung der Einträge in der "wp-config.php" (u.a. der Datenbank Access Daten) und Transfer der modifizierten Datei auf den Zielserver.

Leider ist ein WP-Umzug manchmal nicht ganz so einfach. Gestern stolperte ich in 2 typische Fallen. Die zweite davon war mir schon mal begegnet; ich hatte sie aber schlicht vergessen.

Problem 1: Erfordert der Zielserver bestimmte Gruppenrechte für den Zugriff auf Dateien?

Der Standard-Rechtekamm auf Web-Servern, die per FTP erreichbar sind, kann sich durchaus unterscheiden. Und manchmal sind gezielte Rechtesetzungen erforderlich, damit eine Web-Anwendung anstandslos läuft.

Interessant ist in diesem Zusammenhang u.a. eine Unterscheidung des Owners der zugänglichen Web-Verzeichnisse/Dateien von demjenigen User unter dem die Apache-Prozesse laufen. Von Bedeutung ist etwa die Gruppenzugehörigkeit des letzteren Users. Ich selbst lege eigene Apache2-Server oft so an, dass die Apache-Prozesse unter einem User laufen, der Mitglied einer Standard-Gruppe ist, welche wiederum den Webserver-Verzeichnissen zugeordnet wird. Für neu anzulegende Verzeichnisse/Dateien unterhalb des chroot-Pfades werden die Rechte dann über SGID und/oder ACLs gesteuert.

Nun gibt es aber leider keine allgemeingültigen Regeln, was die erforderlichen Zugriffsrechte auf verschiedene Dateitypen anbelangt, damit komplexe Web-Anwendungen funktionstüchtig laufen.

So kann man etwa die PHP-Ausführung sowohl in FastCGI- als Apache-Modul-Installationen so einrichten, dass der Apache-Prozess dabei die Rechte des PHP-File-Owners annimmt und mit diesen Rechten auf weiteren Dateien operiert ("suexec"-Varianten). Anders mag es aber aussehen, wenn ein Webserver oder andere Prozesse unabhängig von PHP direkt auf Dateien zugreifen müssen. Beispiel: PHP erstellt auf Anforderung eines Browsers auf dem Server eine HTML-Datei; diese lädt im Browser JS-Programme nach und letztere wiederum fordern Bilder zur Darstellung im Browser an. Nehmen wir an, der Apache-Prozess gehöre zu der Gruppe von Nutzern, die auf die hochgeladenen Dateien des Webservers zugreifen darf. Dann muss die Gruppe ggf. zwar nicht unbedingt ein "read"-Recht haben, um PHP-Dateien ausführen zu können, wenn das über suexec-Mechanismen geregelt wird. Aber wenn ein nachgelagertes Javascript-Programm eine Bilddatei lesen muss, gibt es womöglich doch ein Problem, falls diese Bild-Datei auf dem Webserver nicht mit dem erforderlichen Gruppenrecht versehen wurde.

Warum werden Rechte im Kontext eines WP-Umzugs u.U. wichtig?
Installiert man WP, so analysiert WP selbst, unter welchen Rechten (bzw. welcher UID) ein PHP-Programm läuft - unter denen des Apache-Prozesses oder denen des File-Owners? Daran richtet sich dann die Installation aus. Was aber, wenn das Analyseergebnis auf einer Test-Umgebung nicht zur Ziel-Umgebung des späteren Produktivservers passt?

Genau eine solche Situation trat gestern in unserem Fall auf und führte gleich zwei Teil-Probleme mit sich.

Problem 1.1: Kann die ".htaccess"-Datei von relevanten Prozessen gelesen werden?
Ich beschreibe mal, was mir im Zuge unseres geplanten Umzugs passierte:
Auf dem Zielsystem bei Strato schien die von WP ursprünglich auf dem 1&1-Server angelegte und von uns kopierte ".htaccess"-Datei nicht zu wirken. Die ".htaccess" ist aber für den gesamten WordPress-Prozess entscheidend: Sie aktiviert die "Rewrite Engine" des Apache-Servers und verweist alle URL-Anfragen zu nicht existierenden Dateien und Verzeichnissen zur Auflösung an die zentrale "index.php" der WP-Installation.

Beim Aufruf bestimmter Dateien im Browser kam auf unserem Zielsystem laufend die Meldung, dass ich auf diese Dateien "nicht zugreifen dürfe". Das geschah etwa, wenn ich den Zugriff auf HTML-Dateien versuchte. Löschte ich dagegen die ".htaccess" auf dem Zielserver und transferierte eine eigens neu angelegte HTML-Datei in das Domain-Verzeichnis auf dem Zielserver, so war alles OK. Die HTML-Datei wurde auf Anforderung anstandslos im Browser dargestellt.

Zunächst dachte ich an einen seltsamen Fehler in der ".htaccess"-Datei. Der Grund war aber ein anderer:

Mein FTP-Programm hatte die auf dem 1&1-Server geltenden Berechtigungen 1:1 auf mein lokales Linux-System abgebildet und diese Berechtigungen danach auch auf den Zielserver transportiert. (Die meisten FTP-Programme haben heute Parameter, die das Erzeugung des Rechtekamms auf dem Zielsystem steuern, soweit dieses die Rechtevergabe gem. eigener Regeln/ACLs überhaupt zulässt). Der Rechtekamm für die ".htaccess"-Datei war auf dem 1&1-Server ursprünglich aber "604" gewesen.
Auf dem Zielsystem bei Strato hing die Lese- (und auch die Schreib-) Berechtigung bestimmter Webserver-Prozesse dagegen offenbar an den Gruppen-Rechten! Mindestens mal für das Auslesen der ".htaccess"-Datei!

[In diesem Zusammenhang ist es übrigens bemerkenswert, dass bei Strato schon das Anlegen eines Dateischutzes per ".htaccess" irgendwelche besonderen Programme zu involvieren scheint ...]

Bei 1&1 hingegen musste die Gruppe hingegen keine Zugriffsrechte auf die ".htaccess"-Datei haben; dort genügte vielmehr das Leserecht von "Others". Offenbar weichen die Server-Installationen der beiden Provider für Web-Hosting deutlich voneinander ab!

Lesson learned:

Das Leserecht für die Gruppe ist auf manchen Serverinstallationen zwingend erforderlich, damit eine ".htaccess"-Datei ordnungsgemäß ausgewertet werden kann.

Ich kam in unserem Fall bei Strato zufällig drauf, als ich das ".htaccess"-File auf meinem Desktop händisch neu anlegte, mit wachsendem Inhalt versah und immer wieder auf den Zielserver hochlud. Das führte erst zur Vergabe von Standardrechten für den Gruppenzugriff auf meinem Linux-Desktop (644); diese Rechte wurden nach dem SFTP-Transfer auch auf dem Server wirksam. Mit positiven Folgen! Die ".htaccess" griff nun endlich.

Problem 1.2: Können auch andere Dateien ohne Gruppenrechte gelesen werden?
Tja, meine einleitenden Sätze deuteten ja schon an, dass die Politik von Providern hier nicht zwingend einheitlich aussehen muss. Der ursprüngliche, von 1&1 vielfach kopierte Rechtekamm "604" erwies sich auf dem Zielserver jedenfalls auch bzgl. anderer Dateien als der ".htaccess" als problematisch: U.a. konnten vorhandene Bild- und Medien-Dateien nicht ausgelesen werden.

Das erklärt sich etwa wie folgt: Laufen bestimmte Server-Prozesse über User, die Mitglied der Gruppe, aber nicht der Owner der zu verarbeitenden Datei sind, so können diese Prozesse (ohne weitere besondere Massnahmen wie suexec) im Falle eines Rechtekamms "604" die Datei trotz des Leserechts von "Others" in keinem Fall lesen! [Off Topic: Das ist unter Linux nützlich, um bestimmte Gruppen von Usern definitiv vom Zugang zu bestimmten Dateien auszusperren, zu denen aber alle anderen Nutzer ungehinderten Lese-Zugang haben sollen.]

Selbst als die ".htaccess" wieder griff, kam es deshalb nach unserem WP-Umzug zu weiteren Fehlern - nämlich immer dann, wenn der Webserver Dateien lesen und bereitstellen sollte, für die die Gruppenrechte nicht hinreichend waren.

Ein pauschales Setzen der "644"-Berechtigung für relevante Zieldateien (bzw. "755" für Verzeichnisse) war per FTP-Programm dann aber schnell durchgeführt. Danach konnten auf dem Zielserver alle Webseiten angesprochen werden.

Wichtiger Hinweis: Die wp-config.php sollte natürlich nie für "Others" lesbar sein - also für diese Datei bitte einen Rechtekamm "600" oder "640" wählen!

Problem 1.3: Laufen PHP-Dateien evtl. auch ohne Gruppenrechte?
Der obige Befund deutet zunächst mal an, dass der Apache-Web-Prozess unter einem User läuft, der Mitglied der Gruppe ist, die beim Hoster Strato den Webspace-Dateien zugeordnet werden. Weitere Tests ergaben aber, dass der Webserver sehr wohl auf PHP-Dateien zugreifen und die ohne Gruppenrechte ausführen konnte. (Strato bietet die PHP-Ausführung im rahmen aktuellen Web-Hostings übrigens über eine FastCGI-Implementierung an.)

Ich zeige mal den Rechtekamm für verschiedene Dateien:

Man erkennt, dass die ".htaccess"-Datei nun das Gruppenrecht zum Lesen aufweist. Hingegen sind der Gruppe alle Zugriffsrechte auf die PHP-Dateien entzogen. Dennoch läuft WordPress inkl. Pinnacle Theme einwandfrei; auch andere, selbst angelegte PHP-Dateien lassen sich mit dem Rechtekamm "600" anstandslos ausführen. Probleme gab und gibt es jedoch bzgl. des Lesens von Dateien mit Rechten wie der "readme.html" auf dem Bild; der Abruf dieser Datei über einen Browser führt zu einer Fehlermeldung

Forbidden
You don't have permission to access /readme.html on this server.

Also sind - wie oben angedeutet - spezielle "suexec"-Mechanismen für die Ausführung von PHP-Dateien mit den Rechten des Owners zu vermuten. Das lässt sich mit bestimmten Apache-Modulen bewerkstelligen.

Bei 1&1 sah ein funktionierender Kamm dagegen wie folgt aus:

Hier erfordert das Lesen und Bereitstellen von anderen als PHP-Dateien offenbar das "read"-Recht von "others". Das mag nun jeder selbst bewerten.

Fazit:

Auf unserem gehosteten Strato-Webspace benötigt man für die Ausführung und das Lesen von PHP-Dateien nur einen Rechtekamm der Form "600". Der Abruf und die Bereitstellung von anderen Dateien durch den Webserver verlangen aber mindestens einen Kamm der Form "640".

Was bedeutet das für Leute, die eine WP-Installation nach einem Umzug besonders härten wollen und sich nicht mit pauschalen Rechte-Kämmen zufrieden geben wollen? Leider muss man sich auf dem gehosteten Web-Space mancher Provider - wie etwa Strato - selbst um eine unterschiedliche Rechtevergabe für PHP-Dateien im Gegensatz zu anderen Dateien kümmern. (Wohl dem, der dafür einen SSH-Zugang hat und zur Abänderung der Rechte mit Linux-Shell-Kommandos arbeiten kann!)

Lesson learned:

Web-Server-Konfigurationen sehen bei verschiedenen Web-Hosting-Providern unterschiedlich aus. Man sollte schon vor einem WP-Umzug von einem Provider zu einem anderen genauer studieren, welche Zugriffsrechte für eine volle Funktionalität erforderlich sind. Dabei sind vor allem Gruppenrechte interessant. PHP-Dateien können ggf. allein mit den Rechten des File-Owners ausgeführt werden. Der Zugriff auf andere Dateien kann dagegen aber zwingend Gruppenrechte erfordern. Ggf. müssen die Datei-Rechte beim Umzug also an die Erfordernisse auf dem Zielserver angepasst werden. Das Leserecht für die Gruppe kann speziell für den Zugriff auf die ".htaccess"-Datei relevant sein.

Nach dem Umzug und einer Vergabe der minimal erforderlichen Rechtekämme für die unterschiedlichen Dateitypen in den WP-Verzeichnissen sollte man übrigens unbedingt auch mal testen, ob sich WP selbst und auch alle Plugins noch über entsprechende WP-Funktionalitäten upgraden lassen!


Problem 2: Serialisierte Information in den Datenbanktabellen verträgt eine Änderung der Länge des Domain-Strings nicht!

Nach der Bereinigung der Rechte-Probleme funktionierte in unserem Fall zwar das Apache-Rewriting wieder - und auch alle erstellten WP-Seiten wurden im Browser wieder samt eingebundenen Bilddateien angezeigt. Aber leider nicht im gewünschten Layout!

Sämtliche im Usprungssystem vorgenommenen Theme-Einstellungen und eigene CSS-Einstellungen (und das waren viele!) funktionierten nicht mehr! Es schien zunächst so, als ob sämtliche Theme- und CSS-Einstellungen beim Umzug des WP-Blogs verloren gegangen wären! Es gab also noch ein Problem, das zu lösen war.

Es ist ein wenig unübersichtlich, wie WP-Themes modifizierte CSS-Anweisungen behandeln und wo sie sie hinterlegen. Ein Teil fließt in reguläre CSS-Dateien ein. Ein anderer Teil aber - wie z.B. CSS-Einstellungen durch den User - werden (je nach Theme) auch in Datenbanktabellen hinterlegt. Das ist etwa beim Pinnacle-Theme der Fall. Ich begab mich bei der Analyse des Problems also zunächst einmal in die Niederungen der WP-Datenbank-Einträge.

Betrachtet man das exportierte SQL-File einer WP/Pinnacle-Installation und sucht dort ein wenig, so findet man tatsächlich die spezifischen CSS-Vorgaben, die man als User/Admin vorgenommen hat, als Datenbankeintrag der "Options"-Tabelle wieder. Warum also zogen z.B. diese Anweisungen auf dem Zielsystem nicht?

Beim genaueren Hinsehen entdeckt man weiter, dass der betreffende String-Eintrag wie auch viele andere Feldeinträge in den WP-Tabellen die Form sog. serialisierter Arrays haben. Unter der Serialisierung eines Arrays einer Programmmiersprache (hier eines PHP-Arrays) versteht man die Transformation der (PHP-) Array-Information (indizierte Elemente und deren Inhalte) in einen nach vorgegebenen Regeln codierten String (mit definierten Trennzeichen und Hinweisen zum Array-Aufbau). Im Rahmen von WP und WP-Themes erfolgt eine Array-Serialisierung i.d.R. durch die PHP-Funktion "serialize()". (Oder für die Deserialisierung später durch das Pendant "unserialize()").

Das Entscheidende dabei ist, dass die Länge der Sub-String-Information zu einem bestimmten Array-Element im serialisierten String über eine vorgestellte Zahl des entsprechenden String-Abschnitts kodiert wird. Bsp: s:5"Ralph". Gemeint ist hier, dass die Information "Ralph" 5 Zeichen lang ist.

Siehe hierzu etwa https://stackoverflow.com/questions/8641889/how-to-use-php-serialize-and-unserialize oder die PHP-Doku!

Array-Serialisierung vereinfacht die persistente Hinterlegung komplex strukturierter Information in Datenbank-Feldern (z.T. zu Lasten der Performance). Leider machen sich viele der Entwickler dabei das Leben leicht: Unter WP bzw. WP-Themes taucht in etlichen Datenbankeinträgen innerhalb serialisierter Arrays leider auch die URL für die Blog-Domäne auf.

Ändert man nun, unbedarft wie ich, pauschal die Domänen-URL im SQL-File auf die neue Zieldomänen-URL durch "Search und Replace"-Funktionalität ab, so wird das nicht in allen Fällen ohne Nebenwirkungen bleiben. In allen Fällen, in denen sich die Domänen-Bezeichnung innerhalb eines Serialisierungs-Strings wiederfindet, wird es i.d.R. ein Problem geben:

Die Länge des URL-Strings zu einer Testdomäne wird ja nur sehr selten mit der Länge der URL der Zieldomäne übereinstimmen! Versuchen PHP-Programme von WP oder WP-Themes nach dem Umzug, die serialisierte Information wieder in PHP-Arrays umzuwandeln, geht das natürlich schief - mit katastrophalen Folgen. Da Grenzen überschritten werden, lässt sich die Information nicht korrekt aus dem String extrahieren. Dies führt dann u.U. dazu, dass unserialize() leere oder fehlerhafte Strings in den aufzubauenden Arrays zurückliefert. Ein Ergebnis: Wichtige Formatierungsinformationen von Themes stehen gar nicht oder nur fehlerhaft zur Verfügung.

Lesson learned:

Man muss die Ersetzung von Domänen-Strings in der SQL-Datei mit Bedacht vornehmen - und eben, wo nötig, auch die vorgeschaltete Längeninformation in Strings mit serialisierter Information abändern!

Nutze für den Datenbank-Export ein WP-Plugin!

Die Modifikation der Domän-URL mit gleichzeitiger Anpassung der Serialisierungs-Information kann man zwar händisch oder unter Linux auch mit Hilfe von kleinen Scripts (awk, sed mit Regex) durchführen. Aber netterweise gibt es auch ein WordPress-Plugin, das einem zur Seite steht - nämlich "WP Migrate DB" (von Delicious Brains):

Das Plugin erzeugt einem bei Bedarf ein Datenbank-Export-File, das die notwendigen Korrekturen der Serialisierungsstrings bereits beinhaltet!

Als Input muss man dem Plugin die zu ändernde Domänen-URL sowie den absoluten (!) Serverpfad des Blogs auf dem Ziel-Webserver mitgeben. Ja, auch letztere Information taucht tatsächlich, je nach WP-Theme, in einigen wenigen Datenbankeinträgen auf! Wie kommt man nun an die Info zum absoluten Serverpath? Am einfachsten über ein PHP-File mit dem Inhalt:

<?php
  echo getcwd();
?>

Das transferiert man per SFTP in sein Domän-Verzeichnis auf den Web-Server, ruft es anschließend im Browser auf und kopiert dann die ausgegebene Info in den Plugin-Dialog. Das SQL-Exportfile das Plugins (im UTF-8-Format) kann man schließlich wie gewohnt per PhpMyAdmin in die MySQL-Datenbank auf dem Zielserver laden.

Funktionierte bei mir anstandslos! Danach waren standen sämtliche Theme-Einstellungen wieder zur Verfügung und auch die privaten CSS-Anpassungen meiner Frau wurden korrekt gelesen und im Layout der Webseiten erwartungsgemäß umgesetzt.

Nebeneffekt: Wenigstens einmal konnte ich meine Frau mit Linux und ein wenig PHP-Kenntnissen glücklich machen!

Performance of Linux md raid-10 arrays – negative impact of the intel_pstate CPU governor for HWP?

Last November I performed some tests with "fio" on Raid arrays with SSDs (4 Samsung EVO 850). The test system ran on Opensuse Leap 42.1 with a Linux kernel of version 4.1. It had an onboard Intel Sunrise Point controller and an i7 6700k CPU.

For md-raid arrays of type Raid10, i.e. for Linux SW Raid10 arrays created via the mdadm command, I was quite pleased with the results. Both for N2 and F2 layouts and especially for situations where the Read/Write load was created by several jobs running in parallel. Depending on the size of the data packets you may, e.g., well reach a Random Read [RR] performance between 1.0 Gbyte/sec and 1.5 GByte/sec for packet sizes ≥ 512 KB and %gt; 1024k, respectively. Even for one job only the RR-performance for such packet sizes lay between 790 MByte/sec and 950 Mbyte/sec - i.e. well beyond the performance of a single SSD.

Significant drop in md-raid performance on Opensuse Leap 42.2 with kernel 4.4

Then I upgraded to Opensuse Leap 42.2 with kernel 4.4. Same system, same HW, same controller, same CPU, same SSDs and raid-10 setup.
I repeated some of my raid-array tests. Unfortunately, I then experienced a significant drop in performance - up to 25% depending on the packet size. With absolute differences in the range of 60 MByte/sec to over 200 Mbyte/sec, again depending on the chosen data packet sizes.

In addition I saw irregular ups and downs in the performance (large spread) for repeated tests with the same fio parameters. Up to some days ago I never found a convincing reason for this strange performance variation behavior of the md-Raid arrays for different kernels and OS versions.

Impact of the CPU governor ?!

Three days ago I read several articles about CPU governors. On my system the "intel_pstate" driver is relevant for CPU power saving. It offers exactly two active governor modes: "powersave" and "performance" (see e.g.: https://www.kernel.org/doc/html/latest/admin-guide/pm/intel_pstate.html).

The chosen CPU governor standard for Opensuse Leap 42.2 is "powersave".

Just for fun I repeated some simple tests for the raid array again - one time with "powersave" active on all CPU cores/threads and a second time with "performance" active on all cores/threads. The discrepancy was striking:


Test setup

HW: CPU i7 6700K, Asus Z170 Extreme 7 with Intel Sunrise Point-H Sata3 controller

Raid-Array: md-raid-10, Layout: N2, Chunk Size: 32k, bitmap: none

SSDs: 4 Samsung Evo 850

Fio parameters:

size=500m
directory=/mnt2
direct=1
ioengine=sync
bs=512k
; bs=1024k
iodepth=1
numjobs=1
[read]
rw=randread
[write]
stonewall
rw=randwrite


Test results:

Fio test case 1 - bs=512k, Random Read [RR] / Random Write [RW]:

Leap 42.1, Kernel 4.1:
RR: 780 MByte/sec - RW: 754 MByte/sec,
RR Spread around 35 Mbyte/sec

Leap 42.2, Kernel 4.4, CPU governor powersave :
RR: 669 MByte/sec - RW: 605 MByte/sec,
RR Spread around 50 Mbyte/sec

Leap 42.2, Kernel 4.4, CPU governor: performance :
RR: 780 MByte/sec - RW: 750 MByte/sec,

RR Spread around 35 Mbyte/sec


Fio test case 2 - bs=1024k, Random Read [RR] / Random Write [RW]:

Leap 42.1, Kernel 4.1:
RR: 860 MByte/sec - RW: 800 MByte/sec
RR Spread around 30 Mbyte/sec

Leap 42.2, Kernel 4.4, CPU governor: powersave :
RR: 735 MByte/sec - RW: 660 MByte/sec
RR Spread > 50 Mbyte/sec

Leap 42.2, Kernel 4.4, CPU governor: performance :
RR: 877 MByte/sec - RW: 792 MByte/sec
RR Spread around 25 Mbyte/sec

Interpretation

The differences are so significant that one begins to worry. The data seem to indicate two points:

  • It seems that a high CPU frequency is required for optimum performance of md-raid arrays with SSDs.
  • It seems that the Leap 42.1 with kernel 4.1 reacts differently to load requests from fio test runs - with resulting CPU frequencies closer to the maximum - than Leap 42.2 with kernel 4.4 in powersave mode. This could be a matter of different CPU governors or major changes in drivers ...

With md-raid arrays active, the CPU governor should react very directly to a high I/O load and a related short increase of CPU consumption. However, the md-raid-modules seem to be so well programmed that the rise in CPU load is on average below any thresholds for the "powersave"-governor to react adequately. At least on Leap 42.2 with kernel 4.4 - for whatever reasons. Maybe the time structure of I/O and CPU load is not analyzed precisely enough or there is in general no reaction to I/O. Or there is a bug in the related version of intel_pstate ...

Anyway, I never saw a rise of the CPU frequency above 2300 Mhz during the tests on Leap 42.2 - but short spikes to half of the maximum frequency are quite normal on a desktop system with some applications active. Never, however, was the top level of 4200 Mhz reached. I tested also with 2000 MB to be read/written in total - then we talk already of time intervals around 3 to 4 secs for the I/O load to occur.

Questions

When reading a bit more, I got the impression, that the admins possibilities to influence the behavior of the "intel_pstate" governors are very limited. So, some questions arise directly:

  1. What is the major difference between OS Leap 42.1 with kernel 4.1 compared to Opensuse 42.2 with kernel 4.4? Does Leap 41.1 use the same CPU governor as Leap 42.2?
  2. Is the use of Intel's standard governor mode "powersave" in general a bad choice on systems with a md-raid for SSDs?
  3. Are there any kernel or intel-pstate parameters that would change the md-raid-performance to the better again?

If somebody knows the answers, please contact me. The whole topic is also discussed here: https://bugzilla.kernel.org/show_bug.cgi?id=191881. At least I hope so ...

Addendum, 19.06.2017:
Answer to question 1 - I checked which CPU governor runs on Opensuse Leap 42.1:
It is indeed the good old (ACPI-based) "ondemand" governor - and not the "new" intel_pstate based "powersave" governor for Intel's HWP. So, the findings described above raise some questions regarding the behavior of the "intel_pstate based "powersave" governor vs. comparable older CPU_FREQ solutions like the "ondemand" governor: The intel_pstate "powersave" governor does not seem to support md-raid as well as the old "ondemand" governor did!

I do not want to speculate too much. It is hard to measure details of the CPU frequency changes on small timescales, and it is difficult to separate the cpu consumption of fio and the md-modules (which probably work multithreaded). But it might be that the "ondemand" governor provides on average higher CPU frequencies to the involved processes over the timescale of a fio run.

Anyway, I would recommend all system admins who use SSD-Raid-arrays under the control of mdadm to check and test for a possible performance dependency of their Raid installation on CPU governors!

 

SSD Raid Arrays unter Linux – IX – Chunk Size und Performance eines md-Raid-10-Arrays

In früheren Blogbeiträgen hatte ich mich Ende 2016 ein wenig mit SSD-Raid-Arrays unter Linux auseinandergesetzt:

SSD Raid Arrays unter Linux – I – ein facettenreiches Thema
SSD Raid Arrays unter Linux – II – Hardwarecontroller ?
SSD Raid Arrays unter Linux – III – SW- Raid vs. Intel-iRST-Raid – Performance?
SSD Raid Arrays unter Linux – IV – OS und Daten auf einem Raid-Array?
SSD Raid Arrays unter Linux – V – SW-Raid vs. iRST-Raid – Boot-Unterstützung?
SSD Raid Arrays unter Linux – VI – SW-Raid vs. iRST-Raid – Flexibilität?
SSD Raid Arrays unter Linux – VII – problematische Aspekte von Raid-5-Arrays
SSD Raid Arrays unter Linux – VIII – Setup von Raid-10-Arrays mit mdadm

Ich möchte in diesem Blog-Beitrag einige Performance-Daten für ein Raid-10-Setup mit SSDs nachreichen. Wir betrachten dabei ein SW-Raid-Array (md-Raid), dass mit Hilfe von "mdadm" erstellt wurde. Die Daten, die auf einem Opensuse-System gewonnen wurden, unterstreichen den großen Einfluss der "Chunk-Size" auf einige Einsatzszenarien. Wichtigstes Ergebnis:

Man kann nicht grundsätzlich davon ausgehen, dass eine große Chunk-Size (≥ 512 KB) die beste Performance liefern wird.

Test-Voraussetzungen

Die Voraussetzungen für die nachfolgend ermittelten Daten waren:

Raid-Array:
Linux SW-Raid-10-Array aus 4 SSDs (Samsung EVO 850); Near N2-Layout. Verwendete Partitionsgrößen auf den SSDs: 40 GiB. Das Array wurde z.B. für eine Chunk Size von 32kiB z.B. erzeugt mit

 
mdadm --create --verbose /dev/md/d02 --level=raid10 --bitmap=none --chunk=32 
--layout=n2 --raid-devices=4 /dev/sda5 /dev/sdb5 /dev/sdc5 /dev/sdd5 

Eine "Bitmap" (s. hierzu den letzten Artikel) wurde also nicht angelegt. Für die "Chunk Size" wurden test-abhängig Werte von 8k, 16k, 32k, 512k verwendet. Vor jedem Einzeltest wurde ein fstrim-Befehl auf die zu testende Partition des Raid-Systems abgesetzt. Hinsichtlich der Schreibtests lagen also optimale Voraussetzungen vor. Es wurden LVM2 Logical Volumes verwendet, die mit einem "ext4"-Fielssystem versehen wurden. Der LVM- und Filesystem-Overhead gegenüber einem Schreiben mit dem Tool "fio" (s.u.) auf unformatierte Partitionen erwies sich als unerheblich.

OS und HW:
Opensuse Leap 42.1 mit Kernel 4.1; i7 6700K; Onboard Z170 Intel Raid-Controller (Kernel-Modul: pinctrl_sunrisepoint). Scheduler: Deadline.
Die Kernelversion ist leider wichtiger als man meinen möchte. Die nachfolgend ermittelten Daten lassen sich z.B. auf einem System mit Opensuse Leap 42.2 mit Kernelversion 4.4 nicht erzielen! Bei gleichem Setup, gleicher FIO-Version und identischem HW-Unterbau ist die Performance zum Teil deutlich schlechter. Für Einzelprozesse und Daten-Paket-Gößen unterhalb 1 MB waren auf derselben HW-Plattform Perfromance-Einbrüch von 25 bis zu 30 % zu verzeichnen. Unverständlicherweise! Im asymptotischen Bereich (große Daten-Pakete, die die Chunk Size weit übersteigen und/oder viele parallel arbeitende Jobs) werden aber die gleichen Werte wie unter einem 4.1 Kernel erreicht. Vorläufige Untersuchungen zeigen, dass die schlechtere Performance ein Effekt ist, der schon bei Einzel-SSDs auftritt und durch das Raid10-System nur noch verstärkt wird.

Test-SW und Datenstruktur:
Ich habe primär "fio" in der Version 2.2.10 und für sequentielles Lesen/Schreiben großer Datenpakete ergänzend auch "gnome-disks" eingesetzt. Es wurden Daten von insgesamt 500 MB Größe geschrieben. Unter "fio" galten dabei besondere Bedingungen: Die Nutzung des Linux-Caches wurde durch Optionen umgangen; wir wollen ja die tatsächliche Raid-Performance testen. Typische Einstellungen für die FIO-Jobs waren in etwa solche wie nachfolgend für einen "Random Write"-Job angegeben:

[global]
size=500m
direct=1
bs=64k
ioengine=sync

[write]
bs=64k
numjobs=1
rw=randwrite

Die fio-Blocksize "bs" wurde im Test zwischen 8k und 20000k variiert - damit wurde im Test abgefragt, wie das System auf unterschiedliche strukturiertes Datenaufkommen reagiert: Kleine einzelne Datenpakete (spike-artig) vs. größere Datenpakete (etwa größere Files).

Nur 1 Job liest oder schreibt auf das Array:
Von großer Bedeutung für die Testergebnisse ist die fio-Einstellung, dass nur genau ein (1) Job zu einem Zeitpunkt ein Datenpaket lesen oder schreiben soll. Die Ergebnisse würden sich drastisch ändern, wenn mehrere Jobs gleichzeitig auf das Raid-System zugreifen würden. Im Besonderen würde die Schreibperformance bei "Random Write"-Tests deutlich nach oben gehen. Damit wird sich ein kommender Artikel befassen.

Man kann in etwa sagen, dass eine zunehmende Zahl von Jobs einen ähnlichen Effekt hat wie eine deutliche Vergrößerung der Größe "bs": Es stehen zu einem Zeitpunkt immer viele Datenblöcke, die über Chunks möglichst parallel auf die Platten geschrieben werden. Die Chunksize wird dann einfach früher und trotz evtl. kleiner "bs"-Werte überschritten.

Schwankungsbandbreite
Die Ergebnisse zu den Transferraten haben eine Schwankungsbandbreite zwischen 8 und 25 MB/sec. Tendenziell ist die Schwankungsbreite bei kleinen Datenpaketgrößen höher. Das liegt u.a. auch an der sonstigen Auslastung des Testsystems. Ich habe versucht, so viele Prozesse wie möglich abzuschalten; ferner wurde jede der durchgeführten Messungen 3 mal wiederholt. Es wurde ein sinnvoller Mittelwert bei leichter Bevorzugung hoher Werte angegeben.

Daten

Die nachfolgende Tabelle ist wie folgt zu lesen:

Am Kopf der verschiedenen Testblöcke ist die Art des Lesen/Schreibens (Random vs. Sequential) angegeben.

  • Die Variation der "Chunk Size" entnimmt man der zweiten Spalte.
  • Es folgen pro Zeile mehrere Blöcke aus jeweils 2 (oder 3) zusammengehörigen Spalten mit der verwendeten fio-"bs" und dem zugehörigen Messwert für die Datentransferrate in MiB/s. Zu den mit "gdisk" bezeichneten Spalten s.u..
  • Die Zeilen mit SSD am Anfang zeigen Werte, die für eine einzelne SSD-Partition außerhalb des Raid-Verbunds gemessen wurden (Einzelzugriff auf eine SSD).
  • Die Spalten mit der Überschrift "gdisk" stehen für zusätzliche Werte, die mit dem Tool "gnome-disks" gewonnen wurden. Sie betreffen nur sequentielle Lese- und Schreibtests.

Grün markierte Werte markieren aus meiner Sicht akzeptable Werte; bei ihnen kommt auch die Performance-Verbesserung durch Einsatz eines Raid-vebrunds gegenüber einer Einzel-SSD voll zum Tragen. Werte für sequentiell Zugriffe und eine Chunk Size von 16K habe ich leider noch nicht erhoben; sorry.

500M

                                     

Random Read

                           

gdisk

   

gdisk

 

chunk

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

MB/s

bs

MB/s

MB/s

SSD

-

8

64

16

126

32

200

64

278

128

327

512

433

1024

460

 

20000

497

 

R10_0

16

8

66

16

149

32

235

64

448

128

604

512

753

1024

832

 

20000

851

 

R10_1

32

8

66

16

128

32

215

64

390

128

720

512

791

1024

868

 

20000

932

 

R10_2

512

8

64

16

128

32

209

64

277

128

318

512

436

1024

851

 

20000

976

 
                                       

Random Write

                                     
 

chunk

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

MB/s

bs

MB/s

MB/s

SSD

-

8

166

16

243

32

409

64

457

128

458

512

478

1024

492

 

20000

502

 

R10_0

16

8

158

16

285

32

484

64

615

128

680

512

730

1024

775

 

20000

790

 

R10_1

32

8

166

16

295

32

384

64

609

128

731

512

754

1024

816

 

20000

850

 

R10_2

512

8

130

16

299

32

347

64

430

128

464

512

463

1024

837

 

20000

873

 
                                       

500M

                                     

Seq Read

                                   
 

chunk

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

MB/s

bs

MB/s

MB/s

SSD

-

8

 

16

371

32

425

64

480

128

483

512

493

1024

506

 

20000

517

 

R10_0

16

8

 

16

 

32

 

64

 

128

 

512

 

1024

 

986

20000

   

R10_1

32

8

 

16

355

32

432

64

796

128

724

512

773

1024

883

950

20000

980

1030

R10_2

512

8

 

16

354

32

425

64

472

128

495

512

485

1024

950

998

20000

1010

1100

                                       

Seq Write

                                     
 

chunk

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

MB/s

bs

MB/s

MB/s

SSD

-

8

 

16

333

32

410

64

456

128

485

512

484

1024

490

 

20000

502

 

R10_0

16

8

 

16

 

32

 

64

 

128

 

512

 

1024

 

380

20000

   

R10_1

32

8

 

16

298

32

377

64

647

128

734

512

756

1024

812

399

20000

850

840

R10_2

512

8

 

16

301

32

370

64

423

128

450

512

464

1024

836

374

20000

886

841

                                       

 

Interpretation

Wir kommen zu folgenden Ergebnissen und möglichen Erklärungen des festgestellten Verhaltens:

Feststellung 1: Besonders das Lesen kleiner Datenpakete liegt den Samsung SSDs nicht.

Erklärungsansatz: Typischer SSD-Leistungseinbruch bei kleinen Datenpaketen
Wir sollten nicht allzu sehr überrascht sein, wenn wir bei kleinen Datenpaketen einen generellen Performance-Verlust der SSDs feststellen. Dieses Verhalten ist schon bei Einzel-SSDs gegeben - und übrigens auch bei klassischen Harddisks nicht anders. Viele Leute sind sich dessen aber nicht bewusst; in der Werbung geben die Hersteller ja meist nur die sequentiell erreichbaren Maximalraten an. Diese Werte spiegeln aber das tatsächliche, im Mittel deutlich kleinere Leistungsvermögen bei kleinen Einzeldatenpaketen überhaupt nicht wieder. Der Fairness sei auch gesagt, dass HDDs im Bereich kleiner Datenpakete sehr viel schlechtere Werte zeigen.

Erklärungsansatz: Erwartbar stärkerer Einbruch der Lese- als der Schreibperformance bei kleinen Datenpaket-Größen
Offenbar ist es ein verbreitetes Phänomen, dass bei vielen SSDs für geringe Datenpaketgrößen die Leseperformance hinter der Schreibperformance zurückfällt. Siehe hierzu:
http://www.anandtech.com/show/6935/seagate-600-ssd-review/5
Ich habe leider keine Ahnung, wie das technisch zu begründen ist. Besseres Caching zu schreibender Daten auf dem internen SSD-Controller? Jedenfalls zeigen meine Daten genau diesen Effekt - z.T. mit einer überraschend großen Diskrepanz zwischen Lese- und Schreibperformance.

Feststellung 2: Erst wenn die Datenpaketgröße die "Chunk Size" (deutlich) übersteigt, hebt sich auch die Performance des Raid-10-Arrays deutlich gegenüber der einer einzelnen SSD ab.

Feststellung 3: Unterhalb einer Datenpaketgröße von 1MB wird auch bei Überschreiten der Chunk Size keine Verdoppelung der Performance gegenüber einer Einzel SSD erreicht.

Erklärungsansatz: Fundamentale Bedeutung der Chunk Size
In den vorhergehenden Blogbeiträgen hatte ich bereits diskutiert, dass die Chunk Size eine Mindestgröße angibt, ab der parallele Zugriffe auf die 2 Stripeset-Komponenten des Raid-10-Arrays überhaupt erst ermöglicht werden. Deshalb würde man für Situationen, in denen der "bs"-Wert - also die Größe des zu verarbeitenden Datenpakets - die Chunk Size unterschreitet, einen deutlichen Einbruch der Performance erwarten. Da das Raid-System auch Overhead verursacht, würde man bei kleinen Datenpaketen ggf. sogar damit rechnen, dass die Performance des Raid-Arrays die einer Einzel-SSD (also außerhalb des Raid-Verbunds) unterschreitet. Statistisch geschieht das tatsächlich; in der Tabelle kommt das durch eine leichte Bevorzugung besserer Werte aber nicht zum Tragen.

Feststellung 3: Eine annähernde Verdoppelung der Leistung wird erst asymptotisch bei großen Datenpaketen erreicht. Das gilt für Random Read/Write wie für Sequential Read/Write. Im asymptotischen Bereich mit Datenpaketgrößen > 1MB sind auf einem Raid-10-Array mit Consumer-SSDs aber Schreibraten jenseits von 850 MB/sec und Leseraten jenseits von 1000 MB/sec möglich (SSD: EVO 850).

Erklärungsansatz: ???
Ehrlich gesagt, hier kann ich keine fundierte Erklärung liefern. Timing-Probleme des SSD-Controllers? Timing-Probleme zwischen Kernel, SW-Raid und dem Controller? Zusammenspiel interner SSD-Caches mit dem Test? Besonders erklärungsbedürftig scheint mir zu sein, dass beim sequentiellen Lesen sowie einer Chunk Sitze von 32 KB im Bereich von Datenpaket-Größen zwischen 64KB und 512 KB keine Systematik vorzuliegen scheint. Es wäre an dieser Stelle auch interessant zu sehen, wie sich eigentlich ein Raid-0-Array verhält.

Feststellung 4: Bei großen Datenpaketen nähern sich die Random-Raten den sequentiellen Raten an.

Erklärungsansatz: Asymptotik
Mit wachsender Größe der Datenpakete gibt man dem System die Möglichkeit, ein immer sequentielleres Verhalten zu erreichen.

Feststellung 5: gnome-disks liefert vor allem beim sequentiellen Schreiben von Datenpaketen mit 1MB Größe seltsame und gegenüber fio viel zu kleine Werte.

Erklärungsansatz: ???
Keine Ahnung. Hier stimmt jedenfalls irgendetwas nicht. Ich persönlich traue hier "gnome-disks" nicht.

Erstes Fazit

Auch wenn wir nicht alle Daten schlüssig erklären können, sind vier Befunde offenkundig:

  • Mit Hilfe eines Raid-10-Arrays kann man eine deutlich höhere Performance als mit Einzel-SSDs erreichen.
  • Eine theoretisch mögliche Verdoppelung von Datentransferraten wird nur asymptotisch für große Datenpakete und sequentielle Zugriffe erreicht.
  • Für Szenarien, in denen nur 1 Job zu einer Zeit Daten liest oder schreibt, hängt der mögliche Performance-Gewinn stark davon, ob die Größe der Datenpakete im Mittel die "Chunk Size" übersteigt oder nicht. Die richtige Wahl der "Chunk Size" ist vor allem dann wichtig, wenn regelmäßig einzelne kleine Datenpakete vom und zum Raid-10-Array transferiert werden müssen. Das kann z.B. für bestimmte Datenbank-Anwendungen relevant sein.
  • Eine Chunk Size von 32K stellt einen guten Kompromiss bzgl. der Unterstützung relativ kleiner Datenpaketgrößen und einer gleichzeitigen Performanceverbesserung gegenüber Einzel-SSDs dar.

Ausblick

Themen weiterer Artikel sollten Test für mehrere parallel lesende/schreibende Jobs, für andere Kernelversionen und auch für Raid-5-Arrays sein. Ich bitte diesbzgl. um etwas Geduld.