VM-Regionen werden häufig als gemeinsam nutzbare Adressräume in VOS-Anwendungen verwendet. Dies ist ein sehr effizienter Weg, um mehreren Prozessen den Zugriff auf denselben Satz von Adressen zu ermöglichen. Der Hauptnachteil besteht darin, dass der Speicherplatz aufgrund der Grenzen des virtuellen Speichers von VOS auf deutlich unter 2 GB beschränkt ist und dass diese Nutzung die für andere Zwecke verfügbare VM einschränkt.
Der Adressraum kann auch über das Dateisystem gemeinsam genutzt werden, indem Adressen auf eine Binärdatei abgebildet werden und der Zugriff auf diese Adressen über Datei-I/O-Operationen erfolgt. Auf diese Weise werden die Größenbeschränkungen für VM-Regionen aufgehoben und ansonsten dedizierte VM freigegeben. Es ermöglicht auch die Koordinierung über Regionssperren, ist aber weitaus kostspieliger als der direkte Zugriff auf gemeinsam genutzte VM, insbesondere wenn tatsächliche Festplatten-E/A beteiligt sind.
Posix-Anwendungen verwenden zu diesem Zweck manchmal Streamdateien im Binärmodus, indem sie die gewünschte Größe des Adressraums mittels ftruncate (das wegen seiner Fähigkeit, die Position von EOF zu erweitern, verwendet wird) festlegen und dann Bereiche innerhalb der Datei positionieren, aus denen Daten gelesen oder geschrieben werden. Auf diese Weise dient die Datei als Sicherungsspeicher für den Adressraum und Prozesse teilen sich den Raum über dateiorientierte Schnittstellen wie fseek/fread/fwrite.
Vor der Einführung von 64-Bit-Stromdateien (in Release 17.2) konnte dies unter VOS sehr teuer werden, da gewöhnliche Stromdateien 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 der gewünschte Adressraum beispielsweise 2 GB beträgt, dann 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 könnte. Mit 64-Bit-Streamdateien können diese Art von Anwendungen nun effizient unter VOS laufen und benötigen nur so viel Speicherplatz, wie tatsächlich benötigt wird. Posix-Anwendungen erhalten automatisch die Vorteile von 64-Bit-Stream-Dateien, wenn sie für große Dateien gebaut werden; Sie sollten dies tun, um diese Leistungsvorteile zu erhalten, selbst wenn die Dateien voraussichtlich nicht größer als 2 GB werden. (Siehe OpenVOS POSIX.1 Referenzhandbuch, R502, "Portierung bestehender Anwendungen auf die 64-bit Stream File Umgebung" für weitere Informationen).
Eine ähnliche Verwendung von dateigestütztem gemeinsamem 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 stark reduzieren können, so dass die CPU-Nutzung im Wesentlichen die Hauptkosten darstellt. Die Einführung von spärlichen 64-Bit-Stream-Dateien in Release 17.2 macht diesen Ansatz für gemeinsam genutzten Adressraum noch attraktiver.
Residenter Speicher und RAM-Dateien
Eine speicherresidente Datei wird mit dem Befehl set_open_options identifiziert. Ein einstellbarer Teil des Festplatten-Cache ist für speicherresidente Dateien reserviert. Je nach dem verfügbaren physischen Speicher und der sonstigen Verwendung des Cache kann dieser Anteil bis zu 9-10 GB betragen. Blöcke von speicherresidenten Dateien, die sich einmal im Cache befinden, werden nicht mehr von der Festplatte gelesen, solange die Gesamtzahl diesen Teil des Cache nicht übersteigt. Ist dies der Fall, so behalten die zuletzt referenzierten Blöcke diesen Vorteil.
RAM-Dateien sind Dateien, die nicht-persistente Daten enthalten. Sie sind nützlich, wenn die Datei Daten enthält, die nicht auf die Festplatte übertragen werden müssen, wenn die Anwendung sie nicht mehr benötigt. Sie können den Befehl set_ram_file verwenden, aber jede Datei, für die s$delete_file_on_close aufgerufen wird, wird von diesem Zeitpunkt an automatisch als RAM-Datei behandelt.
Während speicherresidente Dateien keine nachfolgenden Lesevorgänge auf der Festplatte verursachen, werden dennoch in regelmäßigen Abständen Blöcke geschrieben, und die Anzahl der im Cache zulässigen geänderten Blöcke ist wie bei jeder anderen Datei begrenzt. Durch die Begrenzung der Anzahl geänderter Blöcke wird verhindert, dass Millionen von Blöcken geschrieben werden müssen, wenn die Datei geschlossen oder geleert wird - 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 nie auf die Festplatte geschrieben werden müssen, selbst wenn die Datei deaktiviert ist.
Die Verwendung von speicherresidenten RAM-Dateien sorgt für einen Adressraum im Cache-Speicher, der die meisten Festplatten-E/A vermeidet, einen Adressraum, der nur durch die Cache-Größe begrenzt ist, die wiederum auf dem verfügbaren physischen Speicher und nicht auf dem virtuellen Speicher basiert (der Cache-Manager nutzt VM-Adressen für den Zugriff auf den physischen Speicher). Hinweis: Ein einzelner dateibasierter Adressraum kann bis zu 512 GB groß werden, aber wenn er größer ist als der speicherresidente Teil des Cache, verliert er seine E/A-Vorteile, zumindest für die Blöcke, auf die nicht kürzlich verwiesen wurde.
Beispiel
Auf den Inhalt einer Stream-Datei kann mit s$seq_position mit byteorientierten Opcodes zugegriffen werden und dann mit s$read_raw/s$write_raw untersucht oder verändert werden. 64-Bit-Streamdateien können bis zu 512 GB groß sein, ohne nennenswerten Plattenplatz zu beanspruchen, mit Ausnahme der Bereiche in der Datei, die verwendet werden, d. h. die nicht auf Null gesetzt sind.
Zum Beispiel,
create_file scratch -organization stream64 -extent_size 256
Dadurch wird eine DAE-256-Datei mit dem Namen "scratch" erstellt.
set_ram_file Kratzer
Dadurch kann diese Datei unbegrenzt auf den Cache zugreifen, ohne dass die Anzahl der geänderten Blöcke gedrosselt wird, und es werden Schreibvorgänge auf die Festplatte ganz vermieden, außer im Hintergrund oder wenn der Cache erschöpft ist und für andere Zwecke benötigt wird. Dies kann auch programmatisch über s$set_ram_file erfolgen. Wenn der letzte Öffner die Datei schließt, werden die Daten im Cache verworfen und es werden keine Schreibvorgänge auf die Festplatte durchgeführt. 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 ist ein Faktor der Cache-Größe und des Prozentsatzes der Speicherresidenz, der mit dem Befehl set_tuning_parameters festgelegt wurde.
Die folgende Sequenz zeigt ein Beispiel für die programmatische Verwendung (illustriert mit 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 zur Verfügung:
tsc: extend_stream_file p 549235720192 (s$control EXTEND_STREAM_FILE)
und verwenden sie zum Speichern von Daten:
tsc: s$seq_position_x p bwd_by_bytes 3 (aktuelle Position nach extend 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 zur Positionierung auf absolute Byte-Offsets.
Das Ergebnis sieht so aus, dass die Datei nur zwei Datenblöcke auf der Festplatte belegt:
..dump_file scratch -brief
%swsle#Raid4>otto>d-3>new>scratch 15-02-25 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 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 normalerweise nicht auf die Festplatte geschrieben, obwohl für sie Speicherplatz auf der Festplatte reserviert ist, falls sie bei überlasteten Cache-Ressourcen benötigt werden. Der obige dump_file-Befehl sieht die gecachten Blöcke und liest nicht von der Festplatte.
Wenn eine RAM-Datei deaktiviert wird (d.h. nicht mehr in einem Prozess geöffnet ist), schneidet VOS die Datei ab (ohne geänderte Blöcke auf die Festplatte zu schreiben) und gibt den gesamten Speicherplatz frei. Unter normalen Umständen würde die oben beschriebene Sequenz zu keinerlei E/A auf der Festplatte führen, außer zum Schreiben der beiden Dateimap-Blö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>new>scratch 15-02-25 16:07:12 est