VM-Regionen werden häufig als gemeinsam nutzbare Adressräume in VOS-Anwendungen verwendet. Dies ist eine sehr effiziente Methode, um mehreren Prozessen den Zugriff auf denselben Adressbereich zu ermöglichen. Der größte Nachteil besteht darin, dass der Speicherplatz aufgrund der Beschränkungen des virtuellen Speichers von VOS auf deutlich unter 2 GB begrenzt ist und diese Nutzung den für andere Zwecke verfügbaren VM-Speicherplatz einschränkt.
Der Adressraum kann auch über das Dateisystem gemeinsam genutzt werden, indem Adressen auf eine Binärdatei abgebildet und über Datei-E/A-Operationen auf diese Adressen zugegriffen wird. Dadurch entfallen Beschränkungen hinsichtlich der Größe des VM-Bereichs und es werden ansonsten dedizierte VMs freigegeben. Dies ermöglicht auch die Koordination über Bereichssperren, ist jedoch weitaus kostspieliger als der direkte Zugriff auf gemeinsam genutzte VMs, insbesondere wenn tatsächliche Festplatten-E/A-Operationen erforderlich sind.
Posix-Anwendungen verwenden zu diesem Zweck manchmal Stream-Dateien im Binärmodus, wobei sie die gewünschte Größe des Adressraums über ftruncate (das aufgrund seiner Fähigkeit, die Position von EOF zu erweitern, verwendet wird) festlegen und dann zu Bereichen innerhalb der Datei positionieren, aus denen Daten gelesen oder geschrieben werden. Auf diese Weise dient die Datei als Backing Store für den Adressraum, und Prozesse teilen sich den Raum über dateiorientierte Schnittstellen wie fseek/fread/fwrite.
Vor der Einführung von 64-Bit-Stream-Dateien (in Release 17.2) konnte dies auf VOS sehr kostspielig sein, da gewöhnliche Stream-Dateien nicht spärlich sein können und die Erweiterung von EOF die explizite Zuweisung und das Schreiben von Blöcken mit binären Nullen erfordert. Wenn beispielsweise der gewünschte Adressraum 2 GB betragen würde, würde VOS 524.288 Blöcke Festplattenspeicher benötigen, obwohl nur ein kleiner Teil dieses Speichers jemals andere Werte als binäre Nullen enthalten würde. Mit 64-Bit-Stream-Dateien können solche Anwendungen nun effizient auf VOS ausgeführt werden und benötigen nur so viel Festplattenspeicher, wie tatsächlich benötigt wird. Posix-Anwendungen profitieren automatisch von den Vorteilen von 64-Bit-Stream-Dateien, wenn sie für die Verarbeitung großer Dateien ausgelegt sind. Sie sollten dies tun, um diese Leistungsvorteile zu nutzen, auch wenn nicht zu erwarten ist, dass die Dateien größer als 2 GB werden. (Weitere Informationen finden Sie im OpenVOS POSIX.1-Referenzhandbuch, R502, „Portierung bestehender Anwendungen in die 64-Bit-Stream-Dateiumgebung”.
Eine ähnliche Verwendung von dateibasiertem gemeinsam genutztem Adressraum ist in nativen VOS-Anwendungen möglich, d. h. in solchen, die s$-Schnittstellen verwenden. VOS bietet eine Reihe von Funktionen, die die Festplatten-E/A bei Verwendung dieser Technik erheblich reduzieren können, sodass im Wesentlichen die CPU-Auslastung zum Hauptkostenfaktor wird. Die Einführung von spärlichen 64-Bit-Stream-Dateien in Release 17.2 macht diesen Ansatz für gemeinsam genutzten Adressraum noch attraktiver.
Speicherresidente und RAM-Dateien
Eine speicherresidente Datei wird mit dem Befehl „set_open_options“ identifiziert. Ein konfigurierbarer Teil des Festplatten-Caches wird für speicherresidente Dateien reserviert. Je nach verfügbarem physischem Speicher und anderen Verwendungszwecken des Caches kann dies bis zu 9–10 GB betragen. Blöcke speicherresidenter Dateien, die sich einmal im Cache befinden, verursachen keine nachfolgenden Festplattenlesevorgänge, solange die Gesamtzahl diesen Teil des Caches nicht überschreitet. Ist dies der Fall, behalten die zuletzt referenzierten Blöcke diesen Vorteil.
RAM-Dateien sind Dateien, die nicht persistente Daten enthalten und nützlich sind, wenn die Datei Daten enthält, die nicht auf die Festplatte geschrieben werden müssen, wenn die Anwendung sie nicht mehr verwendet. Sie können den Befehl „set_ram_file“ verwenden, aber jede Datei, für die „s$delete_file_on_close“ aufgerufen wird, wird ab diesem Zeitpunkt automatisch als RAM-Datei behandelt.
Obwohl speicherresidente Dateien keine nachfolgenden Festplattenlesevorgänge verursachen, werden Blöcke dennoch in regelmäßigen Abständen geschrieben, und die Anzahl der im Cache zulässigen geänderten Blöcke ist wie bei jeder anderen Datei begrenzt. Durch die Begrenzung der geänderten Blöcke wird verhindert, dass beim Schließen oder Leeren der Datei Millionen von Blöcken geschrieben werden müssen – eine 4-GB-Datei belegt eine Million Blöcke. Diese Begrenzung kann eine Anwendung verlangsamen, die Daten schneller ändert, als sie geschrieben werden können. RAM-Dateien vermeiden diese Art der Drosselung, da ihre Daten niemals auf die Festplatte geschrieben werden müssen, selbst wenn die Datei deaktiviert ist.
Die Verwendung von speicherresidenten RAM-Dateien bietet einen Adressraum im Cache-Speicher, wodurch die meisten Festplatten-E/A vermieden werden. Dieser Adressraum ist nur durch die Cache-Größe begrenzt, die wiederum auf dem verfügbaren physischen Speicher basiert, nicht auf dem virtuellen Speicher (der Cache-Manager teilt VM-Adressen, um auf den physischen Speicher zuzugreifen). Hinweis: Ein einzelner dateibasierter Adressraum kann bis zu 512 GB groß werden, aber wenn er größer ist als der speicherresidente Teil des Caches, verliert er seine E/A-Vorteile, zumindest für diejenigen Blöcke, auf die in letzter Zeit nicht zugegriffen wurde.
Beispiel
Auf den Inhalt einer Stream-Datei kann mit s$seq_position mit byteorientierten Opcodes zugegriffen und dann mit s$read_raw/s$write_raw überprüft oder geändert werden. 64-Bit-Stream-Dateien können bis zu 512 GB groß sein, ohne dass dafür nennenswerter Speicherplatz erforderlich ist, außer für die Bereiche in der Datei, die verwendet werden, d. h. auf einen Wert ungleich Null gesetzt sind.
Zum Beispiel
create_file scratch -organisation stream64 -extent_size 256
Dadurch wird eine DAE-256-Datei mit dem Namen „scratch“ erstellt.
set_ram_file scratch
Dadurch erhält diese Datei uneingeschränkten Zugriff auf den Cache, wodurch eine Drosselung aufgrund der Anzahl der geänderten Blöcke vermieden wird und Schreibvorgänge auf die Festplatte vollständig entfallen, außer im Hintergrund oder wenn der Cache erschöpft ist und für andere Zwecke benötigt wird. Dies kann auch programmgesteuert über s$set_ram_file erfolgen. Wenn der letzte Öffner die Datei schließt, werden die Daten im Cache verworfen und es sind keine Schreibvorgänge auf die Festplatte erforderlich. Die Datei muss leer sein, wenn dieser Befehl verwendet wird.
set_open_options scratch -cache_mode memory_resident
Dadurch werden so viele Blöcke dieser Datei wie möglich auf unbestimmte Zeit im Cache gespeichert. Die tatsächliche Anzahl hängt von der Cache-Größe und dem Prozentsatz der Speicherbelegung ab, wie im Befehl set_tuning_parameters festgelegt.
Die folgende Sequenz zeigt ein Beispiel für die programmatische Verwendung (illustriert anhand von test_system_calls):
tsc: s$attach_port p scratch
tsc: s$open p -io_type update
Stellen Sie nun einen Adressraum von etwa 512 GB bereit:
tsc: extend_stream_file p 549235720192 (s$control EXTEND_STREAM_FILE)
und verwenden Sie es zum Speichern von Daten:
tsc: s$seq_position_x p bwd_by_bytes 3 (aktuelle Position nach Erweiterung ist EOF)
tsc: s$write_raw p END
tsc: s$seq_position_x p bof
tsc: s$write_raw p START
tsc: s$seq_position_x p fwd_by_bytes 2000
tsc: s$write_raw p 2000
Hinweis: s$seq_position unterstützt auch Opcodes zum Positionieren auf absolute Byte-Offsets.
Das Ergebnis sieht wie folgt aus, wobei die Datei nur zwei Datenblöcke auf der Festplatte belegt:
..dump_file scratch -kurz
%swsle#Raid4>otto>d-3>neu>Entwurf 25.02.15 16:04:17 EST
Block Nummer 1
000 53544152 54000000 00000000 00000000 |START………..|
010 00000000 00000000 00000000 00000000 |…………….|
=
7D0 00000000 00323030 30000000 00000000 |…..2000…….|
7E0 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 |…………….|
Blocknummer 131870736
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00454E44 |………….END|
Hinweis: Die Blöcke 1 und 131870736 befinden sich im Cache und werden in der Regel nicht auf die Festplatte geschrieben, obwohl für sie Speicherplatz reserviert ist, falls dies aufgrund einer Überlastung der Cache-Ressourcen erforderlich sein sollte. Der oben genannte Befehl „dump_file“ sieht die zwischengespeicherten Blöcke und liest nicht von der Festplatte.
Wenn eine RAM-Datei deaktiviert wird (in keinem Prozess mehr geöffnet ist), kürzt VOS die Datei (wodurch das Schreiben geänderter Blöcke auf die Festplatte vermieden wird) und gibt den gesamten Festplattenspeicher frei. Unter normalen Umständen würde die oben beschriebene Abfolge zu keinerlei Festplatten-E/A führen, mit Ausnahme des Schreibens der beiden Dateizuordnungsblöcke, die schließlich verworfen werden.
tsc: s$close p
Jetzt ist die Datei leer und belegt keinen Speicherplatz mehr:
tsc: ..dump_file scratch
%swsle#Raid4>otto>d-3>neu>Entwurf 25.02.15 16:07:12 EST