La sincronizzazione scrive molto lentamente. Ubuntu 10.10, 32 bit, ext4

Sto eseguendo ActiveMQ sul mio Macbook Pro che esegue Ubuntu 10.10, 32 bit con una partizione ext4.

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

Se abilito la persistenza in ActiveMQ, le prestazioni calano terribilmente. Ho provato la stessa cosa su altre macchine e la differenza è di 2 ordini di grandezza.

Esiste uno strumento con activeMQ per testare l'HD, ecco i risultati:

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.

Le prestazioni per Sync Writes sono s ** t. Deve esserci qualcosa di non configurato correttamente, ma questa è l'unica app in cui ho notato un problema di performance HD.

hdparm genera i valori previsti:

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

Il principale fattore limitante per l'IO sincrono non è il throughput del tuo hard disk, ma piuttosto il tempo che impiega quando viene emessa la scrittura e viene impegnata su disco. La metrica di prestazione più rilevante per un hard disk in questo senso sarebbe il tempo di ricerca dell'hard disk e non il suo rendimento in circostanze ideali.

Oltre all'hardware che funziona contro di te, così come il kernel, immagino che potresti vedere un piccolo miglioramento (anche se, probabilmente, in nessun posto vicino a quello che otterrai dal fare un IO asincrono) se puoi ionizzare il benchmark (applicazione) a eseguito sotto la classe di pianificazione IO in tempo reale. Per impostazione predefinita, le applicazioni verranno pianificate nella classe di sforzo migliore, che probabilmente aumenterà anche il tempo di attesa delle tue scritture. Utilizzare la classe di pianificazione in tempo reale a proprio rischio, poiché avrà effetti negativi sulle prestazioni di altre applicazioni quando si accede al disco.

In generale, non penso davvero che ci sia qualcosa di orribilmente sbagliato nelle prestazioni di scrittura sincrona che stai vedendo. L'IO sincrono in genere funzionerà in modo orribile rispetto all'IO asincrono.

Come nota a margine, un rapido google di activemq e io sincrono ha dato quanto segue :

Per motivi di prestazioni, potresti voler trasmettere i messaggi al broker il più velocemente possibile, anche se stai usando messaggi persistenti

Lo scheduler I / O di cfq tende a funzionare in modo orribile in questo tipo di test. Oltre al suggerimento di ionice in precedenza, potresti provare a passare allo scheduler I / O di scadenza ( elevator=deadlineeseguendo l' avvio o eseguendo for n in /sys/block/sd*/queue/scheduler ; do echo deadline > $n ; doneil root come root).

Una scrittura sincrona deve ricevere una conferma del fatto che la scrittura è stata commessa (se il commit è stato un esito positivo o un errore) prima di poter restituire se stesso. Questo è di progettazione, e intrinsecamente rende le scritture sincrone molto più lente a causa dei tempi di latenza elevati associati a un disco di metallo rotante (sulla cache di ram del disco non conta).

Le scritture asincrone di solito vengono scritte nella RAM e il sistema operativo si occupa di eseguirne il commit su disco in un secondo momento (in seguito di solito solo pochi secondi o meno (credo che ZFS sia 5x / secondo o ogni 5 secondi)). I tempi di ricerca del disco sono misurati in ms mentre i tempi di ricerca della RAM sono misurati in ns. Questa è una differenza di 1000x.

Utilizzare le scritture sincrone quando è assolutamente fondamentale che i dati vengano archiviati in modo permanente prima di continuare e un ritardo di 1 secondo in cui potrebbe verificarsi una perdita di alimentazione è inaccettabile.

Usa le scritture asincrone in tutte le altre volte.

Il motivo più probabile che stai riscontrando questa interruzione delle prestazioni è perché stai usando "-o sync" con un filesystem journaled e le barriere attivate (che è l'impostazione predefinita per ext4).

È qui che la decisione su cosa fare per migliorarla diventa molto difficile.

Si riduce principalmente a quanto ti fidi del tuo hardware.

Da mount (8): "Le barriere di scrittura impongono un corretto ordinamento su disco dei commit dei journal, rendendo sicure le cache di scrittura su disco volatile da usare, con una certa penalità di prestazione. Il filesystem ext3 non abilita le barriere di scrittura di default. Assicurati di abilitare le barriere a meno che i dischi sono alimentati a batteria in un modo o nell'altro. Altrimenti si rischia la corruzione del filesystem in caso di interruzione dell'alimentazione. "

Quindi, o accetta il fatto che le prestazioni di "-o sync" siano tristi, oppure acquista cache con batteria tampone per il tuo controller e dischi SAS davvero buoni, quindi disattiva le barriere usando "-o sync, nobarrier".

Se quello che stai attualmente utilizzando è un back-end di archiviazione FC o iSCSI di classe enterprise, suppongo che anche tu sia sicuro.

Tutto sommato, ActiveMQ 5.4 utilizza il back-end di archiviazione KahaDB per impostazione predefinita e anche quello ha il proprio registro delle transazioni, quindi forse anche la disattivazione del journaling a livello di filesystem potrebbe funzionare per te, ma poi assicurati assolutamente di utilizzare "enableJournalDiskSyncs" opzione per il backend e probabilmente vorrai metterlo anche su un dispositivo a blocchi separato se non l'hai ancora fatto.

(vedi http://activemq.apache.org/kahadb.html per ulteriori informazioni)

Le scritture sincrone sono lente, è per questo che bufferiamo tutto. Dai un'occhiata a IOPS su Wikipedia e vedrai un tipico HDD da 7.200 rpm con 75-100 IOPS. Ora dai un'occhiata alle specifiche tecniche di un Macbook Pro e ha un HDD da 5.400 rpm. È il 75% delle prestazioni al massimo, quindi stai cercando 50-75 IOPS al meglio per il laptop.

Un MQ potrebbe scrivere un libro mastro di dati e un libro mastro di contabilità, che ti porta ai 20 IOPS che vedi nel benchmark ActiveMQ.

Hai due opzioni, prova su tmpfs , cioè file system in memoria, o usa un SSD. Normalmente i server che usano scritture sincrone avranno un array RAID SAS / SCSI significativo con dischi da 15.000 rpm. I dischi extra vengono aggiunti all'array per migliorare le prestazioni, non per aumentare la capacità.

Su una VM ospitata (in VirtualBox) che esegue Ubuntu 11.10 server a 64 bit anche usando ext4 abbiamo ottenuto i seguenti risultati:

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

Su un server fisico che esegue Redhat 5.7 64 bit usando ext3 sono stati ottenuti i seguenti risultati:

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

Mi chiedo se l'OP lo stesse eseguendo anche in una VM o se c'è un problema tra ext3 ed ext4. Apprezzo che ci potrebbe essere una differenza tra ambienti ospitati e non ospitati, tuttavia non mi aspettavo una differenza così grande.

Utilizzare una dimensione del blocco più grande. Stai forse confondendo IO sincronizzato / asincrono con IO diretto / con buffer?