ltcp/bericht/bench/bench-iozone.tex

\subsection{IOzone}

Es wurden ein neu angelegtes NFS- und das vorhandene FastFS-Dateisystem vermessen.

\subsubsection{NFS}

\begin{figure}[h!]
  \centering
  \includegraphics{benchmarks/iozone-nfs-read-tmpl.pdf}
  \includegraphics{benchmarks/iozone-nfs-write-tmpl.pdf}
\end{figure}

Testaufruf:

\shellcmd{./iozone -azcR -I -U /mnt/data -f /mnt/data/testfile -b excel-nfs.xls}


\subsubsection{GlusterFS}

\begin{figure}[h!]
  \centering
  \includegraphics{benchmarks/iozone-fastfs-read-tmpl.pdf}
  \includegraphics{benchmarks/iozone-fastfs-write-tmpl.pdf}
\end{figure}

Testaufruf:

\shellcmd{./iozone -azcR -+q 1 -U /fastfs -f /fastfs/testfile -b excel-fastfs.xls}

Der Parameter \emph{-+q 1} sorgt für einen Delay zwischen den einzelnen Tests, ohne den der Benchmark fehlerhaft läuft.\\

\subsubsection{Auswertung}

Die Lesegeschwindigkeit von NFS entspricht mit als Maximalwert gemessenen 109 MiB/s in etwa der möglichen Lesegeschwindigkeit der Festplatte, die etwa 112 MiB/s beträgt und wie folgt gemessen wurde:

\shellcmd{hdparm -t /dev/sda}

Die Schreibegeschwindigkeit liegt bei maximal 62 MiB/s und sollte auch in etwa
der Leistungsfähigskeit der Festplatte entsprechen.

GlusterFS liegt in der Lesegeschwindigkeit von maximal 104 MiB/s etwa mit NFS
gleich auf. Die Schreibegeschwindigkeit hingegen erreicht lediglich 28 MiB/s und
liegt damit weit hinter NFS. Dies lässt sich im Wesentlichen darauf
zurückführen, dass GlusterFS ein FUSE-Dateisystem ist und es deshalb bei jeder
Schreibeoperation es etliche Kontextwechsel und Kopiervorgänge gibt, weil die
einzelnen Nodes miteinander kommunizieren müssen, um die Daten verteilt
schreiben zu können.  Zusätzlich stellen hier also auch die Atom-Prozessoren
durch ihre begrenze Leistungsfähigkeit einen limitierenden Faktor dar.