2014-10-26 12 views
12

Wenn ein Prozess Daten über einen Socket an einen anderen Prozess auf demselben Computer sendet, wie wahrscheinlich ist es, dass während der Übertragung ein Lese-/Schreibzugriff auf die Festplatte erfolgt? Es scheint einen Socket-Dateityp zu geben, sind diese garantiert im Speicher, vorausgesetzt, es gibt freien Speicher?Beinhaltet Socket IO Disk IO?

+0

Können Sie bitte Ihren Entwurf und Ihre Anforderung näher ausführen? –

+0

Es gibt nicht wirklich ein bestimmtes Design. Ich versuche, die Leistung einer flachen Datei cms wie Pico gegen etwas Ähnliches zu messen, das eine alles in Gedächtnis Datenbank wie redis benutzt. Ich erinnere mich, vor Jahren in einem MSDN-Artikel über Winsock gelesen zu haben, dass eine Datei verwendet wurde, um Posix zu implementieren. Zumindest erinnere ich mich daran, dass ich eine vage Vorstellung hatte, dass auf manchen Systemen vielleicht ein Diskettenschreibvorgang auftreten könnte.Denn wenn während der IPC ein blockierender Plattenschreibvorgang auftritt, ist das Spiel für jede Datenbank in Bezug auf die Geschwindigkeit vorbei, selbst wenn das Ganze im Speicher ist. – Kaan

+0

@Kaan Ich schlage vor, Sie finden Ihre Quelle und lesen Sie es erneut. Deine Erinnerung scheint dich enttäuscht zu haben. – EJP

Antwort

7

Nicht direkt. TCP/UDP-Netzwerk-Sockets, über localhost oder ein UNIX-Domain-Socket funktionieren im Speicher. UNIX Domain Sockets sind in der Regel die schnellste Möglichkeit, außerhalb des Kernelbereichs mit einem Modul zu arbeiten.

Sockets über localhost-Pipes sind fast so einfach wie ein paar Memcpys zwischen Userspace und Kernel-Space und zurück. Im TCP-Fall haben Sie den Stack-Overhead.

Beide Dateien und Sockets teilen die Kernel-Abstraktion der Deskriptor-Tabelle, aber das bedeutet keine tatsächliche Datei.

Natürlich kann die Datenbank als Ergebnis Ihrer Transaktion einige Schreibvorgänge in ein Protokoll auslösen.

5

Im POSIX-Modell sowie in vielen anderen Kerneln befinden sich Dateien nicht nur auf Festplatten. Stattdessen wird jedes Gerät durch eine "spezielle Datei" repräsentiert. Sie leben in Verzeichnissen oder in einer Art Namespace, aber der Zugriff darauf ist kein Festplattenzugriff, selbst wenn sie in einem Verzeichnis auf der Festplatte gespeichert sind.

Wenn Sie Speicherdruck haben, können einige Ihrer Datenpuffer ausgelagert werden. Aber das hat nichts mit der "Datei" von Geräten zu tun. Es verwendet nur die Festplatte als zusätzlichen RAM.

Also "Ja, Socket-I/O ist Datei-I/O, aber nicht Datenträger Lesen/Schreiben."

3

Grabbing der "Design des 4.4BSD Betriebssystems", die beschreibt, was als die Referenzimplementierung, Abschnitte 11.2 "Implementierungsstruktur" und 11.3 "Speicherverwaltung" und in der Abwesenheit von extremen Speicherdruck, es scheint um sicherzustellen, dass bei der Übertragung keine Platten-E/A beteiligt sind.

Die übertragenen Daten werden in speziellen Strukturen, mbufs und mbuf-Clustern gespeichert, Daten werden an jedem Ende jedes Puffers direkt hinzugefügt oder entfernt. Wahrscheinlich werden die gleichen Puffer immer wieder verwendet, werden in einen bestimmten Pool freigegeben und dann von dort neu zugewiesen. Frische Puffer werden vom Kernel-malloc-Pool zugewiesen, der nicht ausgetauscht werden kann. Das Wachstum der Anzahl von Puffern wird offensichtlich nur auftreten, wenn der Verbraucher langsam und bis zu einer Grenze ist.

Einfach gesagt, was die Daten betrifft, werden diese Puffer in der Referenzimplementierung nicht durch Dateien gesichert, geschweige denn durch eine Datei im Dateisystem, in der der Inode platziert ist wenn es extrem unwahrscheinlich ist, ausgelagert zu werden.

Dies lässt nur Metadaten und Statusinformationen aus, die sich möglicherweise auf dem Inode befinden. Natürlich, Inode-Erstellung und Nachschlagen wird Festplattenzugriff verursachen. Was den Status angeht, ist alles, was ich mir vorstellen kann, ein Zeitvertreib.

Ich kann keine autorisierenden Informationen über Atime auf UNIX-Domain-Sockets finden. Aber ich habe es mit FreeBSD und Linux versucht und alle vier Dateizeiten wurden immer als Inode-Erstellungszeit beibehalten. Selbst das Einrichten einer zweiten Verbindung zu einem UNIX-Domänen-Socket scheint nicht aktualisiert zu werden.

Verwandte Themen