2016-04-28 3 views
0

Ich habe einen Dateideskriptor, auf den ich immer zwei Floats schreibe. Beachten Sie, dass ich immer rewind() aufruft, bevor ich etwas in die Datei schreibe, was bedeutet, dass ich immer in die erste Zeile schreibe. Betrachten Sie es als "aktuellen Zustand" in einer Datei. Ich rufe auch fflush() auf, nachdem ich darauf geschrieben habe. Ich hatte Latenzspitzen in meiner Anwendung und als ich überprüfte, fand ich, dass fflush() im Allgemeinen etwa 2-3 Mikrosekunden dauert (ja, ich habe einen bösen schnellen Server), aber zu anderen Zeiten (nach etwa 6-7 "normal schreiben -flush cycles ") Ich sehe, die Zeit ist Tausende von Male (15000+ Mikrosekunden) aufgespießtWarum benötigt fflush() eine variable Zeit, um das gleiche Stück Daten zu löschen?

Können Sie mir sagen, was ich in diesem Szenario überprüfen? Wie behebe ich dieses Problem?

+3

Nun, Sie schreiben auf Speicher irgendeiner Art, möglicherweise (Sie haben nicht gesagt) eine HDD. Die beiden lokalen persistenten Speichermechanismen, die ich mir vorstellen kann (HDDs und SSDs), haben unterschiedliche Antwortzeiten, je nachdem, was sie sonst noch tun müssen. 150000 * Mikro * Sekunden sind immer noch eine * wirklich kurze Zeitspanne *. –

+0

Würden Sie eine Memory-Mapped-Datei verwenden? – Chani

+0

@Wildling * Würden Sie eine Memory-Mapped-Datei verwenden? * Lesen Sie [diesen Beitrag] (http://marc.info/?l=linux-kernel&m=95496636207616&w=2) von Linux Torvalds. 'mmap()' ist ** NICHT ** irgendeine Magie, die alles schneller macht. –

Antwort

1

Es hängt davon ab, was sonst noch mit dem Laufwerk passiert. Der erste Engpass wäre, wenn Ihre Daten in die Warteschlange geschrieben werden, so dass es davon abhängen würde, was das Betriebssystem (oder eine andere Datenquelle) sonst mit dem Laufwerk macht. In Zusammenhang damit könnte eine Verzögerung die exklusive Kontrolle über den Datenbus bekommen. Wenn es ein magnetisches Laufwerk ist und keine SSD, dann gibt es auch die Zeit, die der physische Schreibkopf benötigt, um zur richtigen Spur und zum richtigen Sektor zu gelangen, um den Schreibvorgang auszuführen. Beachten Sie, dass dies viel länger dauert, da dies eine physische Aktion ist.

Kurz gesagt, es sei denn, Sie sind tief, tief im Betriebssystem, dann gibt es keine Garantie über genau, wenn eine angeforderte Low-Level-Aktion stattfindet.

1

fflush() spült nicht den Schreibpuffer auf die Festplatte. Es löscht den Schreibpuffer zum Betriebssystem. Das Betriebssystem kann und wahrscheinlich verwendet einen eigenen Puffer. Das Kopieren von Bytes von einem Puffer zu einem anderen ist sehr schnell (im Vergleich zur Platte). Gelegentlich, wenn der Puffer voll ist oder aus einem anderen Grund, kann das Betriebssystem seinen eigenen Puffer auf die Platte spülen. Wenn die Daten tatsächlich geschrieben auf der Festplatte sind, muss Ihr Programm viel, viel länger warten.

Dies ist eine sehr abstrakte Sicht auf das, was vor sich geht. In Wirklichkeit wird ein echtes Betriebssystem wahrscheinlich nicht von fflush() zurückkehren, bis die Daten in die journal geschrieben sind.

+0

Was sind meine Optionen hier? Wird die Verwendung einer Memory-Mapped-Datei helfen? – Chani

+1

Nun, wenn ich in dieser Situation wäre, würde ich auch die Möglichkeit in Erwägung ziehen, außerhalb der Wall Street einen anderen Job zu finden, der nicht mit banalen Problemen belastet ist, die auf Mikro- und Nanosekunden hinauslaufen. Sag es einfach. –

+0

@Wildling Kaufen Sie eine schnellere Festplatte, ssd vorzugsweise. Rufen Sie 'fflush' nicht auf oder verwenden Sie einen asynchronen Thread, sodass die Latenz keine Rolle spielt. – user2079303

Verwandte Themen