Sync schreibt sehr langsam. Ubuntu 10.10, 32 Bit, ext4

Ich verwende ActiveMQ auf meinem Macbook Pro, auf dem Ubuntu 10.10, 32 Bit, mit einer ext4-Partition ausgeführt wird.

Linux iker-laptop 2.6.35-23-generic-pae #40-Ubuntu SMP Wed Nov 17 22:32:51 UTC 2010 i686 GNU/Linux

Wenn ich die Persistenz in ActiveMQ aktiviere, sinkt die Leistung erheblich. Ich habe dasselbe auf anderen Maschinen getestet und der Unterschied beträgt 2 Größenordnungen.

Es gibt ein Tool mit activeMQ zum Testen der Festplatte. Hier sind die Ergebnisse:

iker@iker-laptop:~/apps/apache-activemq-5.4.1$ java -classpath lib/kahadb-5.4.1.jar org.apache.kahadb.util.DiskBenchmark 

Benchmarking: /home/iker/apps/apache-activemq-5.4.1/disk-benchmark.dat
Writes: 
  146171 writes of size 4096 written in 11.074 seconds.
  13199.477 writes/second.
  51.560455 megs/second.

Sync Writes: 
  197 writes of size 4096 written in 10.006 seconds.
  19.688187 writes/second.
  0.07690698 megs/second.

Reads: 
  5589861 reads of size 4096 read in 10.001 seconds.
  558930.2 writes/second.
  2183.321 megs/second.

Die Leistung für Sync Writes ist s ** t. Es muss etwas falsch konfiguriert sein, aber dies ist die einzige App, bei der ich ein Problem mit der HD-Leistung festgestellt habe.

hdparm löst erwartete Werte aus:

iker@iker-laptop:~$ sudo hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   6282 MB in  2.00 seconds = 3141.73 MB/sec
 Timing buffered disk reads:  240 MB in  3.00 seconds =  79.88 MB/sec

Der Hauptbeschränkungsfaktor für synchrone E / A ist nicht der Durchsatz Ihrer Festplatte, sondern die Zeit, die benötigt wird, wenn der Schreibvorgang ausgegeben und auf die Festplatte übertragen wird. Die relevanteste Leistungsmetrik für eine Festplatte in dieser Hinsicht wäre die Suchzeit der Festplatte und nicht ihr Durchsatz unter idealen Umständen.

Zusätzlich zu der Hardware, die gegen Sie arbeitet, und auch dem Kernel, werden Sie wahrscheinlich eine kleine Verbesserung feststellen (obwohl Sie wahrscheinlich nicht annähernd das erreichen, was Sie durch asynchrone E / A erhalten), wenn Sie den Benchmark (die Anwendung) auf ionisieren können Führen Sie unter der Echtzeit-E / A-Planungsklasse aus. Standardmäßig werden Anwendungen unter der Best-Effort-Klasse geplant, was wahrscheinlich auch die Wartezeit Ihrer Schreibvorgänge verlängert. Verwenden Sie die Echtzeit-Planungsklasse auf eigenes Risiko, da sie sich beim Zugriff auf die Festplatte nachteilig auf die Leistung anderer Anwendungen auswirkt.

Im Allgemeinen glaube ich nicht, dass irgendetwas an der synchronen Schreibleistung, die Sie sehen, schrecklich falsch ist. Synchrone E / A-Vorgänge weisen im Vergleich zu asynchronen E / A-Vorgängen im Allgemeinen eine schreckliche Leistung auf.

Als Randnotiz gab ein kurzer Blick auf activemq und synchronous io Folgendes :

Aus Leistungsgründen möchten Sie möglicherweise Nachrichten so schnell wie möglich an den Broker streamen, selbst wenn Sie persistente Nachrichten verwenden

Der cfq I / O-Scheduler neigt dazu, bei solchen Tests eine schreckliche Leistung zu erbringen. Zusätzlich zu dem früheren Ionice-Vorschlag möchten Sie möglicherweise versuchen, zum Deadline-E / A-Scheduler zu wechseln (entweder durch Booten mit elevator=deadlineoder for n in /sys/block/sd*/queue/scheduler ; do echo deadline > $n ; doneals Root).

Ein synchrones Schreiben muss eine Bestätigung zurückerhalten, dass das Schreiben festgeschrieben wurde (unabhängig davon, ob das Festschreiben ein Erfolg oder ein Fehler war), bevor es sich selbst zurückgeben kann. Dies ist beabsichtigt und führt dazu, dass synchrone Schreibvorgänge aufgrund der hohen Latenzzeiten, die mit einer sich drehenden Metallplatte verbunden sind, wesentlich langsamer werden (auf dem RAM-Cache zählt der RAM-Cache nicht).

Asynchrone Schreibvorgänge werden normalerweise in den Arbeitsspeicher geschrieben, und das Betriebssystem übernimmt die spätere Festschreibung auf die Festplatte (später normalerweise nur Sekunden oder weniger (ich glaube, ZFS ist 5x / Sekunde oder alle 5 Sekunden)). Die Platten-Suchzeiten werden in ms gemessen, während die RAM-Suchzeiten in ns gemessen werden. Das ist ein Unterschied von 1000x.

Verwenden Sie synchrone Schreibvorgänge, wenn es unbedingt erforderlich ist, dass die Daten dauerhaft gespeichert werden, bevor Sie fortfahren, und eine Verzögerung von 1 Sekunde, bei der ein Stromausfall auftreten kann, nicht akzeptabel ist.

Verwenden Sie zu allen anderen Zeiten asynchrone Schreibvorgänge.

Der wahrscheinlichste Grund für diese Leistungsstörung ist, dass Sie "-o sync" mit einem aufgezeichneten Dateisystem und aktivierten Barrieren verwenden (dies ist die Standardeinstellung für ext4).

Hier wird die Entscheidung, was zu tun ist, um es zu verbessern, sehr schwierig.

Es kommt jedoch hauptsächlich darauf an, wie sehr Sie Ihrer Hardware vertrauen.

Aus Mount (8): "Schreibbarrieren erzwingen die ordnungsgemäße Reihenfolge von Journal-Commits auf der Festplatte, wodurch die Verwendung von Schreibcaches für flüchtige Datenträger bei einigen Leistungseinbußen sicher wird. Das ext3-Dateisystem aktiviert standardmäßig keine Schreibbarrieren. Stellen Sie sicher, dass Barrieren aktiviert sind, es sei denn Ihre Festplatten sind auf die eine oder andere Weise batteriegepuffert. Andernfalls besteht die Gefahr, dass das Dateisystem bei einem Stromausfall beschädigt wird. "

Akzeptieren Sie also entweder die Tatsache, dass die Leistung von "-o sync" schlecht ist, oder kaufen Sie einen batteriegepufferten Cache für Ihren Controller und wirklich gute SAS-Festplatten, und deaktivieren Sie dann die Barrieren mit "-o sync, nobarrier".

Wenn Sie derzeit ein ordnungsgemäßes FC- oder iSCSI-Speicher-Backend der Enterprise-Klasse verwenden, können Sie dies auch sicher tun.

Alles in allem verwendet ActiveMQ 5.4 standardmäßig das KahaDB-Speicher-Backend, und dieses hat auch ein eigenes Transaktionsprotokoll. Vielleicht könnte sogar das Deaktivieren des Journaling auf Dateisystemebene für Sie funktionieren, aber stellen Sie dann unbedingt sicher, dass Sie "enableJournalDiskSyncs" verwenden. Option für das Backend, und Sie möchten es wahrscheinlich auch auf einem separaten Blockgerät ablegen, wenn Sie dies noch nicht getan haben.

( Weitere Informationen finden Sie unter http://activemq.apache.org/kahadb.html. )

Synchrone Schreibvorgänge sind langsam, deshalb puffern wir alles. Werfen Sie einen Blick auf IOPS auf Wikipedia und Sie werden sehen, dass eine typische Festplatte mit 7.200 U / min 75-100 IOPS hat. Schauen Sie sich jetzt die technischen Daten eines Macbook Pro an , das über eine Festplatte mit 5.400 U / min verfügt. Das sind bestenfalls 75% Leistung, Sie sehen also bestenfalls 50-75 IOPS für den Laptop.

Ein MQ schreibt möglicherweise ein Daten- und ein Buchhaltungsbuch, wodurch Sie zu den 20 IOPS gelangen, die Sie im ActiveMQ-Benchmark sehen.

Sie haben zwei Möglichkeiten: Testen Sie auf tmpfs , dh im In-Memory-Dateisystem, oder verwenden Sie eine SSD. Normalerweise verfügen Server mit synchronen Schreibvorgängen über ein signifikantes SAS / SCSI-RAID-Array mit Festplatten mit 15.000 U / min. Dem Array werden zusätzliche Festplatten hinzugefügt, um die Leistung zu verbessern und nicht die Kapazität zu erhöhen.

Auf einer gehosteten VM (in VirtualBox), auf der der 64-Bit-Ubuntu 11.10-Server auch mit ext4 ausgeführt wird, wurden die folgenden Ergebnisse erzielt:

Sync Writes:
 288 writes of size 4096 written in 10.034 seconds.
 28.702412 writes/second.
 0.112118796 megs/second.

Auf einem physischen Server, auf dem Redhat 5.7 64 Bit mit ext3 ausgeführt wird, wurden die folgenden Ergebnisse erzielt:

Sync Writes:
  54987 writes of size 4096 written in 10.001 seconds.
  5498.1504 writes/second.
  21.47715 megs/second.

Ich frage mich, ob das OP dies auch in einer VM ausgeführt hat oder ob es ein Problem zwischen ext3 und ext4 gibt. Ich schätze, dass es einen Unterschied zwischen gehosteten und nicht gehosteten Umgebungen geben kann, habe aber keinen so großen Unterschied erwartet.

Verwenden Sie eine größere Blockgröße. Verwechseln Sie möglicherweise Sync / Async IO mit Direct / Buffered IO?