Datei-I/O beschleunigen: mmap() vs. read()

Ich habe eine Linux-Anwendung, die 150-200 Dateien (4-10 GB) parallel liest. Jede Datei wird der Reihe nach in kleinen Blöcken unterschiedlicher Größe gelesen, typischerweise jeweils weniger als 2K.

Ich muss derzeit eine Lesegeschwindigkeit von über 200 MB/s, kombiniert aus dem Satz von Dateien, aufrechterhalten. Die Festplatten kommen damit gut zurecht. Es gibt eine prognostizierte Anforderung von über 1 GB/s (was derzeit außerhalb der Reichweite der Festplatte liegt).

Wir haben zwei verschiedene Lesesysteme implementiert, die beide stark genutzt werden posix_advise: zuerst ist ein mmaped read, in dem wir den gesamten Datensatz abbilden und bei Bedarf lesen. Der zweite ist ein read()/seek() basierte System.

Beide funktionieren gut, aber nur für die moderaten Fälle, die read() -Methode verwaltet unseren gesamten Dateicache viel besser und kann gut mit 100 GB an Dateien umgehen, ist aber stark ratenbegrenzt, mmap ist in der Lage, Daten vorab zwischenzuspeichern, wodurch die dauerhafte Datenrate von über 200 MB/s einfach aufrechtzuerhalten ist, kann jedoch nicht mit großen Gesamtdatenmengen umgehen.

Daher kommt meine Frage dazu:

Eine Kanne read() type file i/o darüber hinaus weiter optimiert werden posix_advise Anrufe unter Linux, oder nachdem wir den Festplattenplaner, VMM und posix_advise-Aufrufe optimiert haben, ist das so gut, wie wir erwarten können?

B: Gibt es systematische Möglichkeiten für mmap, mit sehr großen gemappten Daten besser umzugehen?

Mmap-vs-reading-blocks ist ein ähnliches Problem wie das, an dem ich arbeite, und bot zusammen mit den Diskussionen in mmap-vs-read einen guten Ausgangspunkt für dieses Problem.

Liest zurück auf was? Was ist der endgültige Bestimmungsort dieser Daten?

Da es so klingt, als wären Sie vollständig IO-gebunden, mmap und read sollte keinen unterschied machen. Der interessante Teil ist, wie Sie die Daten zu Ihrem Empfänger bekommen.

Angenommen, Sie geben diese Daten in eine Pipe, empfehle ich Ihnen, einfach den Inhalt jeder Datei vollständig in die Pipe zu kopieren. Um dies mit Zero-Copy zu tun, versuchen Sie die splice Systemaufruf. Sie können auch versuchen, die Datei manuell zu kopieren oder eine Instanz von zu forken cat oder ein anderes Tool, das mit der aktuellen Datei als stdin und der Pipe als stdout stark puffern kann.

if (pid = fork()) {
    waitpid(pid, ...);
} else {
    dup2(dest, 1);
    dup2(source, 0);
    execlp("cat", "cat");
}

Update0

Wenn Ihre Verarbeitung dateiunabhängig ist und keinen wahlfreien Zugriff erfordert, möchten Sie eine Pipeline mit den oben beschriebenen Optionen erstellen. Ihr Verarbeitungsschritt sollte Daten von stdin oder einer Pipe akzeptieren.

Um deine konkreteren Fragen zu beantworten:

A: Kann die Datei-I/O vom Typ read() über die posix_advise-Aufrufe unter Linux hinaus optimiert werden, oder ist das Optimieren des Disk-Schedulers, des VMM und der posix_advise-Aufrufe so gut, wie wir erwarten können?

Das ist das Beste, wenn es darum geht, dem Kernel zu sagen, was er vom Userspace aus tun soll. Der Rest liegt bei Ihnen: Puffern, Threading usw., aber es ist gefährlich und wahrscheinlich unproduktiv. Ich würde einfach die Dateien in eine Pipe spleißen.

B: Gibt es systematische Möglichkeiten für mmap, mit sehr großen gemappten Daten besser umzugehen?

Ja. Das folgenden Optionen kann Ihnen großartige Leistungsvorteile bringen (und kann es wert machen, mmap über das Lesen zu verwenden, mit Tests):

• MAP_HUGETLB

  Ordnen Sie das Mapping mit “riesigen Seiten” zu.

  Dadurch wird der Paging-Overhead im Kernel reduziert, was großartig ist, wenn Sie Gigabyte-große Dateien zuordnen.

• MAP_NORESERVE

  Reservieren Sie keinen Auslagerungsbereich für diese Zuordnung. Wenn Auslagerungsspeicher reserviert ist, hat man die Garantie, dass es möglich ist, das Mapping zu modifizieren. Wenn der Auslagerungsspeicher nicht reserviert ist, kann es beim Schreiben zu SIGSEGV kommen, wenn kein physischer Speicher verfügbar ist.

  Dadurch wird verhindert, dass Ihnen der Arbeitsspeicher ausgeht, während Ihre Implementierung einfach bleibt, wenn Sie tatsächlich nicht über genügend physischen Arbeitsspeicher + Swap für das gesamte Mapping verfügen.**

• MAP_POPULATE

  Füllen Sie (voreingestellte) Seitentabellen für ein Mapping. Bei einer Dateizuordnung bewirkt dies ein Vorauslesen der Datei. Spätere Zugriffe auf das Mapping werden nicht durch Seitenfehler blockiert.

  Dies kann Ihnen bei ausreichenden Hardwareressourcen und bei bestelltem Prefetching und Faulheit Geschwindigkeitssteigerungen bringen. Ich vermute, dass dieses Flag redundant ist, das VFS macht das wahrscheinlich standardmäßig besser.

Vielleicht mit der lesen Sie weiter Systemaufruf könnte helfen, wenn Ihr Programm die Dateifragmente, die es lesen möchte, im Voraus vorhersagen kann (aber das ist nur eine Vermutung, ich könnte mich irren).

Und ich denke, Sie sollten Ihre Anwendung und vielleicht sogar Ihre Algorithmen darauf abstimmen, Daten in Blöcken zu lesen, die viel größer als ein paar Kilobyte sind. Kann es nicht stattdessen ein halbes Megabyte sein?

Das Problem scheint hier nicht zu sein, welche API verwendet wird. Es spielt keine Rolle, ob Sie mmap() oder read() verwenden, die Disc muss immer noch zum angegebenen Punkt suchen und die Daten lesen (obwohl das Betriebssystem hilft, den Zugriff zu optimieren).

mmap() hat Vorteile gegenüber read(), wenn Sie sehr kleine Chunks (ein paar Bytes) lesen, weil Sie das Betriebssystem nicht für jeden Chunk aufrufen müssen, was sehr langsam wird.

Ich würde auch raten, wie Basile, mehr als 2 KB hintereinander zu lesen, damit die Disc nicht so oft suchen muss.