Dies ist der Befehl erl, der beim kostenlosen Hosting-Anbieter OnWorks mit einer unserer zahlreichen kostenlosen Online-Workstations wie Ubuntu Online, Fedora Online, dem Windows-Online-Emulator oder dem MAC OS-Online-Emulator ausgeführt werden kann
PROGRAMM:
NAME/FUNKTION
erl – Der Erlang-Emulator
BESCHREIBUNG
Die erl Das Programm startet ein Erlang-Laufzeitsystem. Die genauen Angaben (zum Beispiel ob
erl ein Skript oder ein Programm ist und welche weiteren Programme es aufruft) sind systemabhängig.
Windows-Benutzer möchten wahrscheinlich das verwenden Welt stattdessen ein Programm, das in einem eigenen Fenster ausgeführt wird
mit Bildlaufleisten und unterstützt die Befehlszeilenbearbeitung. Der erl Programm unter Windows bietet keine
Zeilenbearbeitung in seiner Shell, und unter Windows 95 gibt es keine Möglichkeit, zum Text zurückzublättern, der
ist vom Bildschirm gescrollt. Der erl Das Programm muss jedoch in Pipelines verwendet werden oder wenn Sie
Sie möchten die Standardeingabe oder -ausgabe umleiten.
Hinweis:
Ab ERTS-Version 5.9 (OTP-R15B) ist das Laufzeitsystem standardmäßig aktiviert nicht binden Sie Scheduler
an logische Prozessoren. Weitere Informationen finden Sie in der Dokumentation des +sbt Systemflag.
EXPORTE
erl
Startet ein Erlang-Laufzeitsystem.
Die Argumente lassen sich unterteilen in Emulator Fahnen, Fahnen und Ebene Argumente:
* Jedes Argument, das mit dem Zeichen beginnt + wird interpretiert als ein Emulator Flagge.
Wie der Name schon sagt, steuern Emulator-Flags das Verhalten des Emulators.
* Jedes Argument, das mit dem Zeichen beginnt - (Bindestrich) wird als a interpretiert Flagge
die an den Erlang-Teil des Laufzeitsystems übergeben werden sollten, mehr
speziell auf die init Systemprozess, siehe init(3erl).
Die init Der Prozess selbst interpretiert einige dieser Flags, die init Fahnen. Außerdem
speichert alle verbleibenden Flags, die Benutzer Fahnen. Letzteres kann per abgerufen werden
Aufruf init:get_argument/1.
Es kann festgestellt werden, dass es tatsächlich eine kleine Anzahl von „-“-Flags gibt
sind Emulator-Flags, siehe Beschreibung unten.
* Einfache Argumente werden in keiner Weise interpretiert. Sie werden auch von der gespeichert
init Prozess und kann per Anruf abgerufen werden init:get_plain_arguments/0. Einfach
Argumente können vor dem ersten Flag oder nach a stehen -- Flagge. Zusätzlich,
die Flagge -extra bewirkt, dass alles, was folgt, zu einfachen Argumenten wird.
Beispiel:
% erl +W w -sname arnie +R 9 -s my_init -extra +bertie
(arnie@host)1> init:get_argument(sname).
{ok,[["arnie"]]}
(arnie@host)2> init:get_plain_arguments().
["+bertie"]
Hier +W w und +R 9 sind Emulator-Flags. -s meine_init ist ein Init-Flag, interpretiert von
init. -name Arnie ist ein Benutzerflag, gespeichert von init. Es wird vom Kernel gelesen und gelesen
dazu führen, dass das Erlang-Laufzeitsystem verteilt wird. Endlich alles danach
-extra (das ist, +bertie) gelten als einfache Argumente.
% erl -myflag 1
1>init:get_argument(meine Flagge).
{ok,[["1"]]}
2> init:get_plain_arguments().
[]
Hier die Benutzerflagge -meine Flagge 1 wird an die übergeben und von dieser gespeichert init Prozess. Es ist ein
Benutzerdefiniertes Flag, das vermutlich von einer benutzerdefinierten Anwendung verwendet wird.
FLAGGEN
In der folgenden Liste sind Init-Flags markiert (Init-Flag). Sofern nicht anders angegeben, alle
Andere Flags sind Benutzerflags, deren Werte durch Aufruf abgerufen werden können
init:get_argument/1. Beachten Sie, dass die Liste der Benutzerflags nicht vollständig ist. Möglicherweise gibt es solche
zusätzliche, anwendungsspezifische Flags, die stattdessen im entsprechenden Dokument dokumentiert sind
Bewerbungsunterlagen.
--(Init-Flag):
Alles Folgende -- bis zur nächsten Flagge (-Flagge or +Flagge) gilt als einfach
Argumente und können mit abgerufen werden init:get_plain_arguments/0.
-Anwendung von Val:
Legt den Anwendungskonfigurationsparameter fest von auf den Wert Val für die Bewerbung
Anwendungs-, Siehe App(5) und Anwendung(3erl).
-args_file FileName:
Befehlszeilenargumente werden aus der Datei gelesen FileName. Die Argumente lesen sich aus dem
Datei ersetzen Sie das '-args_file FileName'-Flag in der resultierenden Befehlszeile.
Die Datei FileName sollte eine reine Textdatei sein und kann Kommentare und Befehle enthalten
Zeilenargumente. Ein Kommentar beginnt mit einem #-Zeichen und dauert bis zum nächsten Ende
Zeilenzeichen. Als Anführungszeichen wird ein Backslash (\\) verwendet. Alle Befehlszeile
Argumente akzeptiert von erl sind erlaubt, auch die -args_file FileName Flagge. Seien Sie vorsichtig
um keine zirkulären Abhängigkeiten zwischen Dateien zu verursachen, die das enthalten -args_file Flagge,
though.
Die -extra Flagge wird besonders behandelt. Sein Gültigkeitsbereich endet am Ende der Datei. Argumente
Nachfolgend wird ein -extra Flag werden auf der Befehlszeile in die verschoben -extra Abschnitt, d.h.
das Ende der Befehlszeile, die nach einem folgt -extra Flagge.
-async_shell_start:
Die anfängliche Erlang-Shell liest Benutzereingaben erst, wenn die Systemstartprozedur erfolgt ist
abgeschlossen (Erlang 5.4 und höher). Dieses Flag deaktiviert die Startsynchronisierung
Funktion und lässt die Shell parallel zum Rest des Systems starten.
-Stiefel Reichen Sie das:
Gibt den Namen der Boot-Datei an, Datei.boot, mit dem das System gestartet wird. Sehen
init(3erl). Es sei denn Reichen Sie das Enthält einen absoluten Pfad, nach dem das System sucht Datei.boot
in der aktuellen und $ROOT/bin Verzeichnisse.
Der Standardwert ist $ROOT/bin/start.boot.
-boot_var Var Dir:
Wenn das Boot-Skript eine Pfadvariable enthält Var ausgenommen $ROOT, diese Variable ist
erweitert auf Dir. Wird verwendet, wenn Anwendungen in einem anderen Verzeichnis als installiert werden
$ROOT/lib, Siehe systools:make_script/1,2.
-code_path_cache:
Aktiviert den Codepfad-Cache des Codeservers, siehe Code(3erl).
-kompilieren Mod1 Mod2 ...:
Kompiliert die angegebenen Module und beendet sich dann (mit einem Exit-Code ungleich Null, wenn
(die Kompilierung einer Datei war nicht erfolgreich). Impliziert -keine Eingabe. Nicht empfohlen – verwenden
erlc stattdessen.
-config Config:
Gibt den Namen einer Konfigurationsdatei an, Config.config, das zur Konfiguration verwendet wird
Anwendungen. Sehen App(5) und Anwendung(3erl).
-connect_all falsch:
Wenn diese Flagge vorhanden ist, globale wird kein vollständig verbundenes Netzwerk aufrechterhalten
verteilte Erlang-Knoten, und dann kann die globale Namensregistrierung nicht verwendet werden. Sehen
globale (3erl).
-Plätzchen Cookie:
Veraltete Flagge ohne Wirkung und häufige Rechtschreibfehler für -setcookie. Benutzen -setcookie
stattdessen.
-freistehend:
Startet das Erlang-Laufzeitsystem losgelöst von der Systemkonsole. Nützlich zum Laufen
Daemons und Hintergrundprozesse. Impliziert -keine Eingabe.
-emu_args:
Nützlich zum Debuggen. Gibt die tatsächlichen Argumente aus, die an den Emulator gesendet werden.
-env Variable Wert:
Legt die Umgebungsvariable des Host-Betriebssystems fest Variable auf den Wert Wert für das Erlang
Laufzeitsystem. Beispiel:
% erl -env DISPLAY gin:0
In diesem Beispiel wird ein Erlang-Laufzeitsystem mit gestartet DISPLAY -Umgebung
Variable auf gesetzt Gin:0.
-evalu Ausdruck(Init-Flag):
Macht init Bewerten Sie den Ausdruck Ausdruck, Siehe init(3erl).
-extra(Init-Flag):
Alles Folgende -extra gilt als einfache Argumente und kann mit abgerufen werden
init:get_plain_arguments/0.
-Herz:
Startet die Herzschlagüberwachung des Erlang-Laufzeitsystems. Sehen Herz(3erl).
-versteckt:
Startet das Erlang-Laufzeitsystem als versteckten Knoten, wenn es als verteilter Knoten ausgeführt wird.
Versteckte Knoten stellen immer versteckte Verbindungen zu allen anderen Knoten her, mit Ausnahme von Knoten
in derselben globalen Gruppe. Versteckte Verbindungen werden auf keinem der beiden veröffentlicht
verbundene Knoten, d. h. keiner der verbundenen Knoten ist Teil des Ergebnisses von
Knoten/0 auf dem anderen Knoten. Siehe auch versteckte globale Gruppen, globale_Gruppe(3erl).
-Gastgeber Gastgeber:
Gibt die IP-Adressen für die Hosts an, auf denen Erlang-Bootserver ausgeführt werden, siehe
erl_boot_server(3erl). Dieses Flag ist obligatorisch, wenn die -Lader inet Flagge ist vorhanden.
Die IP-Adressen müssen in der Standardform (vier Dezimalzahlen getrennt durch) angegeben werden
Perioden zum Beispiel "150.236.20.74". Hostnamen sind nicht akzeptabel, sondern eine Übertragung
Adresse (vorzugsweise auf das lokale Netzwerk beschränkt) ist.
-id Id:
Gibt die Identität des Erlang-Laufzeitsystems an. Wenn es verteilt ausgeführt wird
Knoten, Id muss mit dem zusammen mit dem angegebenen Namen identisch sein -name or -Name
Flagge.
-init_debug:
Macht init Schreiben Sie einige Debug-Informationen, während Sie das Boot-Skript interpretieren.
-instr(Emulator-Flag):
Wählt anstelle von ein instrumentiertes Erlang-Laufzeitsystem (virtuelle Maschine) zur Ausführung aus
gewöhnlicher. Beim Ausführen eines instrumentierten Laufzeitsystems werden einige Daten zur Ressourcennutzung erfasst
können mit dem Modul erfasst und analysiert werden Instrument. Funktionell verhält es sich
genau wie ein gewöhnliches Erlang-Laufzeitsystem.
-Lader Radlader:
Gibt die von verwendete Methode an erl_prim_loader um Erlang-Module in das System zu laden.
Weitere Informationen finden Sie auch in den erl_prim_loader(3erl). Zwei Radlader Methoden werden unterstützt, E-Datei und inet. E-Datei
bedeutet, dass das lokale Dateisystem verwendet wird. Dies ist die Standardeinstellung. inet bedeutet, einen Boot-Server zu verwenden
eine andere Maschine, und die -id, -Gastgeber und -setcookie Flags müssen ebenfalls angegeben werden.
If Radlader ist etwas anderes, das der Benutzer angegeben hat Radlader Portprogramm wird gestartet.
-machen:
Lässt das Erlang-Laufzeitsystem aufrufen mache alles() im aktuellen Arbeitsverzeichnis und
dann beenden. Sehen um(3erl). Impliziert -keine Eingabe.
-Mann Modul:
Zeigt die Handbuchseite für das Erlang-Modul an Modul. Wird nur unter Unix unterstützt.
-Modus interaktive | eingebettet:
Gibt an, ob das System Code dynamisch laden soll (interaktive), oder wenn alles Code
sollte während der Systeminitialisierung geladen werden (eingebettet), sehen Code(3erl). Standardmäßig auf
interaktive.
-Name Name:
Macht das Erlang-Laufzeitsystem zu einem verteilten Knoten. Dieses Flag ruft alle Netzwerke auf
Server, die für die Verteilung eines Knotens erforderlich sind. Sehen net_kernel(3erl). Es ist auch
sichergestellt, dass epmd läuft auf dem aktuellen Host, bevor Erlang gestartet wird. Sehen epmd(1).
Der Name des Knotens lautet Name@Gastgeber, Wobei Gastgeber ist der vollständig qualifizierte Hostname von
der aktuelle Host. Für kurze Namen verwenden Sie die -name Flagge statt.
-keine Eingabe:
Stellt sicher, dass das Erlang-Laufzeitsystem niemals versucht, Eingaben zu lesen. Impliziert
-noshell.
-noshell:
Startet ein Erlang-Laufzeitsystem ohne Shell. Diese Flagge ermöglicht es, das zu haben
Erlang-Laufzeitsystem als Komponente in einer Reihe von UNIX-Pipes.
-nostick:
Deaktiviert die Sticky-Directory-Funktion des Erlang-Codeservers, siehe Code(3erl).
-oldshell:
Ruft die alte Erlang-Shell von Erlang 3.3 auf. Die alte Hülle kann weiterhin verwendet werden.
-pa Dir1 Dir2 ...:
Fügt die angegebenen Verzeichnisse am Anfang des Codepfads hinzu, ähnlich wie
code:add_pathsa/1. Sehen Code(3erl). Als Alternative zu -pa, wenn mehrere Verzeichnisse
müssen dem Codepfad vorangestellt werden und die Verzeichnisse haben ein gemeinsames übergeordnetes Verzeichnis
Verzeichnis, das übergeordnete Verzeichnis könnte im angegeben werden ERL_LIBS -Umgebung
Variable. Sehen Code(3erl).
-pz Dir1 Dir2 ...:
Fügt die angegebenen Verzeichnisse am Ende des Codepfads hinzu, ähnlich wie
code:add_pathsz/1. Sehen Code(3erl).
-Pfad Dir1 Dir2 ...:
Ersetzt den im Boot-Skript angegebenen Pfad. Sehen Skript(5).
-proto_dist Proto:
Geben Sie ein Protokoll für die Erlang-Verteilung an.
inet_tcp:
TCP über IPv4 (Standard)
inet_tls:
Verteilung über TLS/SSL
inet6_tcp:
TCP über IPv6
So starten Sie beispielsweise verteilte IPv6-Knoten:
% erl -name [E-Mail geschützt] -proto_dist inet6_tcp
-remsh Knoten:
Startet Erlang mit einer verbundenen Remote-Shell Knoten.
-rsh Programm:
Gibt eine Alternative zu an rsh zum Starten eines Slave-Knotens auf einem Remote-Host. Sehen
Sklave(3erl).
-Lauf Weg [Funk [Arg1, Arg2, ...]](Init-Flag):
Macht init Rufen Sie die angegebene Funktion auf. Func Standardmäßig ist Anfang. Wenn es keine Argumente gibt
Vorausgesetzt, dass die Funktion die Arität 0 hat. Andernfalls wird angenommen, dass sie die Arität XNUMX hat
Arität 1, Aufnahme der Liste [Arg1,Arg2,...] als Argument. Alle Argumente werden als übergeben
Saiten. Sehen init(3erl).
-s Weg [Funk [Arg1, Arg2, ...]](Init-Flag):
Macht init Rufen Sie die angegebene Funktion auf. Func Standardmäßig ist Anfang. Wenn es keine Argumente gibt
Vorausgesetzt, dass die Funktion die Arität 0 hat. Andernfalls wird angenommen, dass sie die Arität XNUMX hat
Arität 1, Aufnahme der Liste [Arg1,Arg2,...] als Argument. Alle Argumente werden als übergeben
Atome. Sehen init(3erl).
-setcookie Cookie:
Setzt das magische Cookie des Knotens auf Cookie, Siehe erlang:set_cookie/2.
-shutdown_time Uhrzeit:
Gibt an, wie lange (in Millisekunden) die init Prozess ausgeben darf
Herunterfahren des Systems. Wenn Uhrzeit ms abgelaufen sind, werden alle noch vorhandenen Prozesse gelöscht
getötet. Standardmäßig ist Unendlichkeit.
-name Name:
Verwandelt das Erlang-Laufzeitsystem in einen verteilten Knoten, ähnlich wie -Name, Aber die
Hostnamen-Teil des Knotennamens Name@Gastgeber wird der Kurzname sein, nicht vollständig
qualifiziert.
Dies ist manchmal die einzige Möglichkeit, verteiltes Erlang auszuführen, wenn der DNS (Domain Name
System) läuft nicht. Es kann keine Kommunikation zwischen Knoten stattfinden, die mit dem ausgeführt werden
-name Flagge und diejenigen, die mit der laufen -Name Flag, da Knotennamen in eindeutig sein müssen
verteilte Erlang-Systeme.
-smp [aktivieren|automatisch|deaktivieren]:
-smp ermöglichen und -smp startet das Erlang-Laufzeitsystem mit aktivierter SMP-Unterstützung. Das
kann fehlschlagen, wenn kein Laufzeitsystem mit SMP-Unterstützung verfügbar ist. -smp Auto startet die
Erlang-Laufzeitsystem mit aktivierter SMP-Unterstützung, sofern verfügbar und mehr als eine
logischer Prozessor erkannt. -smp deaktivieren startet ein Laufzeitsystem ohne SMP
unterstützen.
HINWEIS: Das Laufzeitsystem mit SMP-Unterstützung wird nicht auf allen unterstützten Geräten verfügbar sein
Plattformen. Siehe auch die +S Flagge.
-Ausführung(Emulator-Flag):
Veranlasst den Emulator, seine Versionsnummer auszudrucken. Das Gleiche wie erl +V.
EMULATOR FLAGGEN
erl ruft den Code für den Erlang-Emulator (virtuelle Maschine) auf, der das unterstützt
folgende Flaggen:
+a Größe:
Empfohlene Stapelgröße (in Kilowörtern) für Threads im Async-Thread-Pool. Gültiger Bereich
beträgt 16-8192 Kilowörter. Die standardmäßig empfohlene Stapelgröße beträgt 16 Kilowörter, also 64
Kilobyte auf 32-Bit-Architekturen. Diese kleine Standardgröße wird seit dem gewählt
Die Anzahl der asynchronen Threads kann recht groß sein. Die Standardgröße reicht für Treiber aus
Wird mit Erlang/OTP bereitgestellt, ist jedoch für andere dynamische Prozesse möglicherweise nicht groß genug
verlinkt in Treibern, die das verwenden drivers_async() Funktionalität. Beachten Sie, dass der Wert
übergeben ist nur ein Vorschlag und wird auf einigen Plattformen möglicherweise sogar ignoriert.
+A Größe:
Legt die Anzahl der Threads im asynchronen Thread-Pool fest. Der gültige Bereich liegt zwischen 0 und 1024. Wenn Thread
Support verfügbar ist, ist der Standardwert 10.
+B [c | d | i]:
Die c Option macht Strg-C Unterbrechen Sie die aktuelle Shell, anstatt den Emulator aufzurufen
Pausenhandler. Der d Option (identisch mit der Angabe +B ohne zusätzliche Option) deaktiviert
der Break-Handler. Der i Mit dieser Option ignoriert der Emulator jedes Unterbrechungssignal.
Besitzt das c Option wird verwendet mit alte Schale auf Unix, Strg-C startet den Shell-Prozess neu
anstatt es zu unterbrechen.
Beachten Sie, dass dieses Flag unter Windows nur für gilt Weltnicht erl (alte Schale). Notiz
auch dass Strg-Pause wird anstelle von Strg-C unter Windows.
+c was immer dies auch sein sollte. | falsch:
Aktivieren oder deaktivieren Zeit Korrektur:
was immer dies auch sein sollte.:
Zeitkorrektur aktivieren. Dies ist die Standardeinstellung, wenn die Zeitkorrektur unterstützt wird
spezifische Plattform.
falsch:
Zeitkorrektur deaktivieren.
Aus Gründen der Abwärtskompatibilität kann der boolesche Wert weggelassen werden. Dies wird interpretiert als
+c falsch.
+C no_time_warp | single_time_warp | multi_time_warp:
Stelle den Zeit verziehen Modus:
no_time_warp:
Nein Uhrzeit Verziehen Model (der Standard)
single_time_warp:
Einwellig Uhrzeit Verziehen Model
multi_time_warp:
Multi Uhrzeit Verziehen Model
+d:
Wenn der Emulator einen internen Fehler erkennt (oder nicht mehr genügend Speicher hat), wird er dies standardmäßig tun
Erzeugen Sie sowohl einen Crash-Dump als auch einen Core-Dump. Der Core-Dump wird allerdings nicht sehr groß sein
nützlich, da der Inhalt von Prozess-Heaps durch die Crash-Dump-Generierung zerstört wird.
Die +d Die Option weist den Emulator an, nur einen Core-Dump und keinen Crash-Dump zu erstellen, wenn
Es wurde ein interner Fehler erkannt.
maximal einfach anrufen erlang:halt/1 mit einem String-Argument erzeugt immer noch einen Absturzspeicherauszug. Unter Unix
Bei Systemen wird durch das Senden eines SIGUSR1-Signals an einen Emulatorprozess ebenfalls ein Absturzspeicherauszug erzwungen.
+e Nummer:
Legen Sie die maximale Anzahl von ETS-Tabellen fest.
+ec:
Erzwinge die Druckluft Option auf allen ETS-Tischen. Nur zum Testen und Bewerten gedacht.
+fnl:
Die VM arbeitet mit Dateinamen, als ob sie mit der ISO-Latin-1-Kodierung kodiert wären.
Unicode-Zeichen mit Codepunkten über 255 werden nicht zugelassen.
Weitere Informationen finden Sie auch in den STDLIB Benutzer Guide Weitere Informationen zu Unicode-Dateinamen finden Sie hier. Beachten Sie, dass dies
Der Wert gilt auch für Befehlszeilenparameter und Umgebungsvariablen (siehe STDLIB
Benutzer Guide).
+fnu[{w|i|e}]:
Die VM arbeitet mit Dateinamen, als ob sie mit UTF-8 (oder einem anderen System) codiert wären
spezifische Unicode-Kodierung). Dies ist die Standardeinstellung auf Betriebssystemen, die dies erzwingen
Unicode-Kodierung, also Windows und MacOS X.
Die +fnu Der Schalter kann gefolgt werden w, i, oder auch e um die Art und Weise falsch codierte Datei zu kontrollieren
Namen sind zu melden. w bedeutet, dass eine Warnung an den gesendet wird error_logger sobald
ein falsch kodierter Dateiname wird in Verzeichnislisten „übersprungen“, i bedeutet, dass diese
Falsch codierte Dateinamen werden stillschweigend ignoriert und e bedeutet, dass die API-Funktion dies tun wird
Gibt einen Fehler zurück, wenn ein falsch codierter Datei- (oder Verzeichnis-)Name gefunden wird. w
ist die Standardeinstellung. Beachten Sie, dass Datei:read_link/1 gibt immer einen Fehler zurück, wenn der Link
weist auf einen ungültigen Dateinamen hin.
Weitere Informationen finden Sie auch in den STDLIB Benutzer Guide Weitere Informationen zu Unicode-Dateinamen finden Sie hier. Beachten Sie, dass dies
Der Wert gilt auch für Befehlszeilenparameter und Umgebungsvariablen (siehe STDLIB
Benutzer Guide).
+fna[{w|i|e}]:
Auswahl zwischen +fnl und +fnu erfolgt basierend auf den aktuellen Gebietsschemaeinstellungen im
Das heißt, wenn Sie Ihr Terminal auf UTF-8-Kodierung eingestellt haben, ist das Dateisystem
Es wird erwartet, dass die gleiche Codierung für Dateinamen verwendet wird. Dies ist bei allen Betriebssystemen die Standardeinstellung
Systeme außer MacOS X und Windows.
Die +fna Der Schalter kann gefolgt werden w, i, oder auch e. Dies wirkt sich auf das Gebietsschema aus
Einstellungen verursachen das Verhalten von +fnu ausgewählt werden. Siehe die Beschreibung von +fnu zu teilen.
Wenn die Gebietsschemaeinstellungen das Verhalten von verursachen +fnl dann ausgewählt werden w, i, oder auch e werden wir
keine Wirkung haben.
Weitere Informationen finden Sie auch in den STDLIB Benutzer Guide Weitere Informationen zu Unicode-Dateinamen finden Sie hier. Beachten Sie, dass dies
Der Wert gilt auch für Befehlszeilenparameter und Umgebungsvariablen (siehe STDLIB
Benutzer Guide).
+hms Größe:
Setzt die Standard-Heap-Größe von Prozessen auf die Größe Größe.
+hmbs Größe:
Legt die Standardgröße des binären virtuellen Heapspeichers von Prozessen auf die Größe fest Größe.
+hpds Größe:
Setzt die anfängliche Prozesswörterbuchgröße von Prozessen auf die Größe Größe.
+K was immer dies auch sein sollte. | falsch:
Aktiviert oder deaktiviert die Kernel-Polling-Funktionalität, wenn der Emulator sie unterstützt. Standard
is falsch (deaktiviert). Wenn der Emulator keine Kernel-Abfrage unterstützt und die +K Flagge ist
Wird die Datei an den Emulator übergeben, wird beim Start eine Warnung ausgegeben.
+l:
Aktiviert die automatische Ladeverfolgung und zeigt Informationen beim Laden des Codes an.
+L:
Laden Sie keine Informationen über Quelldateinamen und Zeilennummern. Das wird einiges sparen
Speicher, aber Ausnahmen enthalten keine Informationen über die Dateinamen und die Zeile
Zahlen.
+MFlag Wert:
Speicherzuweisungsspezifische Flags, siehe erts_alloc(3erl) und fordern Sie weitere Informationen an.
+n Verhalten:
Steuerverhalten von Signalen an Ports.
Ab OTP-R16 werden Signale an Ports tatsächlich asynchron übermittelt. Beachten Sie, dass Signale
wurden immer als asynchron dokumentiert. Die zugrunde liegende Implementierung hat,
Allerdings werden diese Signale zuvor synchron geliefert. Korrekt geschriebenes Erlang
Programme sollten damit problemlos umgehen können. Fehler im vorhandenen Erlang
Programme, die falsche Annahmen über Signale an Ports machen, können jedoch schwierig sein
finden. Um die Vergleichbarkeit zumindest zu erleichtern, wurde dieser Schalter eingeführt
Verhaltensweisen während einer Übergangszeit. Beachten Sie, dass fehlen uns die Worte. Flagge is veraltet ab seinem
Einführung und soll in OTP-R17 entfernt werden. Verhalten sollte einer davon sein
folgende Zeichen:
d:
Der Standard. Asynchrone Signale. Ein Prozess, der ein Signal an einen Port sendet, kann
Setzen Sie die Ausführung fort, bevor das Signal an den Port übermittelt wurde.
s:
Synchrone Signale. Ein Prozess, der ein Signal an einen Port sendet, wird nicht fortgesetzt
Ausführung, bis das Signal übermittelt wurde. Sollen einzige zum Testen verwendet werden und
Debuggen.
a:
Asynchrone Signale. Standardmäßig, aber ein Prozess, der ein Signal sendet, wird dies auch tun
häufiger wird die Ausführung fortgesetzt, bevor das Signal an den Port übermittelt wurde.
Sollte einzige zum Testen und Debuggen verwendet werden.
+Stk Abdeckung:
Legt den Zeichenbereich fest, den das System in der Heuristik als druckbar betrachtet
Erkennung von Zeichenfolgen. Dies betrifft typischerweise die Shell, den Debugger und io:format
Funktionen (wenn ~tp in der Formatzeichenfolge verwendet wird).
Derzeit zwei Werte für die Abdeckung sind unterstützt:
Latein1:
Der Standard. Nur Zeichen im ISO-Latin-1-Bereich können als druckbar betrachtet werden.
Das bedeutet, dass ein Zeichen mit einem Codepunkt > 255 niemals berücksichtigt wird
druckbar sind und dass Listen, die solche Zeichen enthalten, als Listen von angezeigt werden
Ganzzahlen anstelle von Textzeichenfolgen durch Tools.
Unicode:
Bei der Bestimmung einer Liste von werden alle druckbaren Unicode-Zeichen berücksichtigt
Ganzzahlen sollen in String-Syntax angezeigt werden. Dies kann zu unerwarteten Ergebnissen führen, wenn
Beispielsweise deckt Ihre Schriftart nicht alle Unicode-Zeichen ab.
Siehe auch io:printable_range/0.
+P Nummer|Vermächtnis:
Legt die maximale Anzahl gleichzeitig vorhandener Prozesse für dieses System fest, wenn a
Nummer wird als Wert übergeben. Gültiger Bereich für Nummer is [1024-134217727]
HINWEIS: Das tatsächlich gewählte Maximum kann viel größer sein als das Nummer bestanden. Momentan
Das Laufzeitsystem wählt oft, aber nicht immer, einen Wert, der eine Potenz von 2 ist. Dies
könnte sich jedoch in Zukunft ändern. Der tatsächlich gewählte Wert kann durch überprüft werden
Aufruf erlang:system_info(process_limit).
Der Standardwert ist 262144
If Erbe wird als Wert übergeben, der Legacy-Algorithmus zur Zuweisung des Prozesses
Bezeichner werden verwendet. Mithilfe des Legacy-Algorithmus werden Bezeichner zugewiesen
streng ansteigend, bis die größtmögliche Kennung erreicht ist. Notiz
dass dieser Algorithmus unter Leistungsproblemen leidet und dies unter bestimmten Umständen kann
Umstände können extrem teuer sein. Der Legacy-Algorithmus ist veraltet und der
Erbe Die Entfernung dieser Option ist in OTP-R18 geplant.
+Q Nummer|Vermächtnis:
Legt die maximale Anzahl gleichzeitig vorhandener Ports für dieses System fest, wenn eine Zahl angegeben ist
wird als Wert übergeben. Gültiger Bereich für Nummer is [1024-134217727]
HINWEIS: Das tatsächlich gewählte Maximum kann viel größer sein als das tatsächliche Nummer bestanden.
Derzeit wählt das Laufzeitsystem häufig, aber nicht immer, einen Wert, der eine Potenz von ist
2. Dies könnte sich jedoch in Zukunft ändern. Der tatsächlich gewählte Wert kann sein
per Anruf überprüft erlang:system_info(port_limit).
Der verwendete Standardwert ist normal 65536. Allerdings, wenn das Laufzeitsystem dazu in der Lage ist
Bestimmen Sie die maximale Anzahl der Dateideskriptoren, die geöffnet werden dürfen, und diesen Wert
ist größer als 65536, wird der gewählte Wert auf einen Wert erhöht, der größer oder gleich ist
die maximale Anzahl an Dateideskriptoren, die geöffnet werden können.
Unter Windows ist der Standardwert auf eingestellt 8196 weil die normalen Betriebssystemeinschränkungen festgelegt sind
höher als die meisten Maschinen bewältigen können.
Zuvor die Umgebungsvariable ERL_MAX_PORTS wurde zur Festlegung des Maximums verwendet
Anzahl gleichzeitig vorhandener Ports. Diese Umgebungsvariable ist veraltet und
Die Entfernung ist in OTP-R17 geplant, kann aber weiterhin verwendet werden.
If Erbe wird als Wert übergeben, der Legacy-Algorithmus zur Zuweisung von Port-IDs
verwendet wird. Bei Verwendung des Legacy-Algorithmus werden Bezeichner strikt zugewiesen
zunehmende Mode, bis die größtmögliche Kennung erreicht ist. Beachten Sie, dass dies
Der Algorithmus leidet unter Leistungsproblemen und kann unter bestimmten Umständen auftreten
extrem teuer. Der Legacy-Algorithmus ist veraltet und der Erbe Option ist
Die Entfernung ist in OTP-R18 geplant.
+R ReleaseNumber:
Legt den Kompatibilitätsmodus fest.
Der Verteilungsmechanismus ist standardmäßig nicht abwärtskompatibel. Diese Flags setzen die
Emulator im Kompatibilitätsmodus mit einer früheren Erlang/OTP-Version ReleaseNumberdem „Vermischten Geschmack“. Seine
Die Release-Nummer muss im Bereich liegen <aktuell release>-2..<aktuell Veröffentlichung>. Dies
schränkt den Emulator ein und ermöglicht ihm die Kommunikation mit Erlang-Knoten (wie
sowie C- und Java-Knoten), auf denen diese frühere Version ausgeführt wird.
Hinweis: Stellen Sie sicher, dass alle Knoten (Erlang-, C- und Java-Knoten) eines verteilten Erlang-Systems vorhanden sind
stammt aus derselben Erlang/OTP-Version oder aus zwei verschiedenen Erlang/OTP-Versionen X und Y,
woher alle Y-Knoten haben den Kompatibilitätsmodus X.
+r:
Erzwingt, dass der ETS-Speicherblock bei Realloc verschoben wird.
+rg ReaderGroupsLimit:
Begrenzt die Anzahl der Lesergruppen, die von Lese-/Schreibsperren verwendet werden, die für das Lesen optimiert sind
Operationen im Erlang-Laufzeitsystem. Standardmäßig beträgt das Limit für Lesergruppen 64.
Wenn die Anzahl der Planer kleiner oder gleich dem Lesergruppenlimit ist, jeweils
Scheduler verfügt über eine eigene Lesergruppe. Wenn die Anzahl der Planer größer ist als die
Lesergruppen sind begrenzt, Planer teilen sich Lesergruppen. Gemeinsame Lesergruppen werden beeinträchtigt
Die Leistung der Lesesperre und Lesefreigabe bei einer großen Anzahl von Lesergruppen nimmt ab
Schreibsperrleistung, daher ist die Grenze ein Kompromiss zwischen der Leistung und der Leseleistung
Operationen und Leistung für Schreiboperationen. Jede Lesergruppe konsumiert derzeit
64 Byte in jeder Lese-/Schreibsperre. Beachten Sie auch, dass ein Laufzeitsystem einen gemeinsam genutzten Reader verwendet
Gruppen profitieren davon Bindung Planer zu logisch Prozessoren, da die Lesergruppen
werden besser zwischen den Planern verteilt.
+S Planer:SchedulerOnline:
Legt die Anzahl der zu erstellenden Scheduler-Threads und der online zu setzenden Scheduler-Threads fest
wenn die SMP-Unterstützung aktiviert wurde. Das Maximum für beide Werte beträgt 1024. Wenn Erlang
Das Laufzeitsystem ist in der Lage, die Anzahl der konfigurierten logischen Prozessoren zu ermitteln
logische Prozessoren verfügbar, Scheduler werden standardmäßig logische Prozessoren verwendet
konfiguriert, und PlanerOnline wird standardmäßig auf die verfügbaren logischen Prozessoren zurückgreifen;
andernfalls sind die Standardwerte 1. Scheduler kann weggelassen werden, wenn :SchedulerOnline
ist nicht und umgekehrt. Die Anzahl der Online-Scheduler kann zur Laufzeit über geändert werden
erlang:system_flag(schedulers_online, TerminplanerOnline).
If Scheduler or PlanerOnline als negative Zahl angegeben wird, ist der Wert
wird von der Standardanzahl der konfigurierten oder logischen logischen Prozessoren abgezogen
verfügbaren Prozessoren.
Angabe des Wertes 0 für Scheduler or PlanerOnline setzt die Anzahl zurück
Scheduler-Threads bzw. Scheduler-Threads online auf den Standardwert gesetzt.
Diese Option wird ignoriert, wenn der Emulator keine SMP-Unterstützung aktiviert hat (siehe -smp
Flagge).
+SP SchedulersPercentage:SchedulersOnlinePercentage:
Ähnlich +S verwendet jedoch Prozentsätze, um die Anzahl der zu erstellenden Scheduler-Threads festzulegen.
basierend auf konfigurierten logischen Prozessoren und Online-Scheduler-Threads, basierend auf
logische Prozessoren verfügbar, wenn die SMP-Unterstützung aktiviert wurde. Angegebene Werte müssen
größer als 0 sein. Zum Beispiel: +SP 50:25 Setzt die Anzahl der Scheduler-Threads auf 50 %
der konfigurierten logischen Prozessoren und die Anzahl der Online-Scheduler-Threads auf 25 %
der verfügbaren logischen Prozessoren. SchedulersPercentage kann weggelassen werden, wenn
:SchedulersOnlinePercentage ist nicht und umgekehrt. Die Anzahl der Online-Planer kann
zur Laufzeit geändert werden über erlang:system_flag(schedulers_online, TerminplanerOnline).
Diese Option interagiert mit +S Einstellungen. Zum Beispiel auf einem System mit 8 logischen Kernen
konfiguriert und 8 logische Kerne verfügbar, die Kombination der Optionen +S 4:4 +SP
50:25 (in beliebiger Reihenfolge) führt zu 2 Scheduler-Threads (50 % von 4) und 1 Scheduler
Thread online (25 % von 4).
Diese Option wird ignoriert, wenn der Emulator keine SMP-Unterstützung aktiviert hat (siehe -smp
Flagge).
+SDcpu DirtyCPUSchedulers:DirtyCPUSchedulersOnline:
Legt die Anzahl der zu erstellenden Dirty-CPU-Scheduler-Threads und den Dirty-CPU-Scheduler fest
Threads, die online gesetzt werden sollen, wenn die Threading-Unterstützung aktiviert wurde. Das Maximum für beides
Die Werte betragen 1024 und jeder Wert wird durch die Einstellungen für „Normal“ weiter eingeschränkt
Scheduler: Die Anzahl der erstellten Dirty-CPU-Scheduler-Threads darf die Anzahl nicht überschreiten
der erstellten normalen Scheduler-Threads und die Anzahl der fehlerhaften CPU-Scheduler-Threads
online darf die Anzahl normaler Scheduler-Threads online nicht überschreiten (siehe +S und +SP
Flaggen für weitere Details). Standardmäßig die Anzahl der erstellten Dirty-CPU-Scheduler-Threads
entspricht der Anzahl der erstellten normalen Scheduler-Threads und der Anzahl der fehlerhaften CPUs
Die Anzahl der Online-Scheduler-Threads entspricht der Anzahl der normalen Online-Scheduler-Threads.
DirtyCPUSchedulers kann weggelassen werden, wenn :DirtyCPUSchedulersOnline ist nicht und umgekehrt.
Die Anzahl der online verfügbaren Dirty-CPU-Scheduler kann zur Laufzeit über geändert werden
erlang:system_flag(dirty_cpu_schedulers_online, DirtyCPUSchedulersOnline).
Diese Option wird ignoriert, wenn der Emulator keine Threading-Unterstützung aktiviert hat.
Derzeit fehlen uns die Worte. zu erhalten is experimentell und wird nur unterstützt, wenn der Emulator dies war
konfiguriert und erstellt mit aktivierter Unterstützung für Dirty Scheduler (deaktiviert durch
Standard).
+SDPCpu DirtyCPUSchedulersPercentage:DirtyCPUSchedulersOnlinePercentage:
Ähnlich +SDcpu verwendet jedoch Prozentsätze, um die Anzahl der schmutzigen CPU-Scheduler festzulegen
zu erstellende Threads und Anzahl der Dirty-CPU-Scheduler-Threads, die wann online gesetzt werden sollen
Threading-Unterstützung wurde aktiviert. Angegebene Werte müssen größer als 0 sein. Für
Beispiel +SDPCpu 50:25 Setzt die Anzahl der schmutzigen CPU-Scheduler-Threads auf 50 % der
logische Prozessoren konfiguriert und die Anzahl der schmutzigen CPU-Scheduler-Threads, die online sind
25 % der verfügbaren logischen Prozessoren. DirtyCPUSchedulersPercentage kann weggelassen werden
if :DirtyCPUSchedulersOnlinePercentage ist nicht und umgekehrt. Die Anzahl der fehlerhaften CPUs
Online-Scheduler können zur Laufzeit über geändert werden
erlang:system_flag(dirty_cpu_schedulers_online, DirtyCPUSchedulersOnline).
Diese Option interagiert mit +SDcpu Einstellungen. Zum Beispiel auf einem System mit 8 logischen
Kerne konfiguriert und 8 logische Kerne verfügbar, die Kombination der Optionen +SDcpu
4:4 +SDPCpu 50:25 (in beliebiger Reihenfolge) führt zu 2 fehlerhaften CPU-Scheduler-Threads (50 % von
4) und 1 schmutziger CPU-Scheduler-Thread online (25 % von 4).
Diese Option wird ignoriert, wenn der Emulator keine Threading-Unterstützung aktiviert hat.
Derzeit fehlen uns die Worte. zu erhalten is experimentell und wird nur unterstützt, wenn der Emulator dies war
konfiguriert und erstellt mit aktivierter Unterstützung für Dirty Scheduler (deaktiviert durch
Standard).
+SDio IOSchedulers:
Legt die Anzahl der Dirty-I/O-Scheduler-Threads fest, die erstellt werden sollen, wenn Threading-Unterstützung vorhanden ist
aktiviert wurde. Der gültige Bereich liegt zwischen 0 und 1024. Standardmäßig ist die Anzahl der Dirty-I/O-Scheduler
Die Anzahl der erstellten Threads beträgt 10, was der Standardanzahl der Threads im entspricht async Faden Pool
.
Diese Option wird ignoriert, wenn der Emulator keine Threading-Unterstützung aktiviert hat.
Derzeit fehlen uns die Worte. zu erhalten is experimentell und wird nur unterstützt, wenn der Emulator dies war
konfiguriert und erstellt mit aktivierter Unterstützung für Dirty Scheduler (deaktiviert durch
Standard).
+sFlagge Wert:
Planen bestimmter Flags.
+sbt BindType:
Legen Sie den Scheduler-Bindungstyp fest.
Scheduler können auch mit dem gebunden werden +stbt Flagge. Der einzige Unterschied zwischen diesen
Mit zwei Flags werden die folgenden Fehler behandelt:
* Die Bindung von Schedulern wird auf der jeweiligen Plattform nicht unterstützt.
* Keine verfügbare CPU-Topologie. Das heißt, das Laufzeitsystem war dazu nicht in der Lage
Die CPU-Topologie wurde automatisch erkannt, und nein Benutzer definiert CPU Topologie war eingestellt.
Wenn einer dieser Fehler auftritt, wann +sbt übergeben wurde, wird das Laufzeitsystem dies tun
Geben Sie eine Fehlermeldung aus und verweigern Sie den Start. Wenn einer dieser Fehler auftritt, wann +stbt
übergeben wurde, ignoriert das Laufzeitsystem den Fehler stillschweigend und startet
Verwendung ungebundener Scheduler.
Aktuell gültig BindTypes:
u:
ungebunden - Scheduler werden nicht an logische Prozessoren gebunden, d. h. an den Betrieb
Das System entscheidet, wo die Scheduler-Threads ausgeführt werden und wann sie migriert werden. Das
ist die Vorgabe.
ns:
keine Verbreitung - Scheduler mit Closed-Scheduler-IDs werden so nah wie möglich gebunden
in Hardware möglich.
ts:
thread_spread - Thread bezieht sich auf Hardware-Threads (z. B. Intels Hyper-Threads).
Scheduler mit niedrigen Scheduler-IDs werden an die erste Hardware gebunden
Thread jedes Kerns, dann werden Scheduler mit höheren Scheduler-IDs verwendet
an den zweiten Hardware-Thread jedes Kerns gebunden usw.
ps:
Prozessor_Spread - Planer werden wie verteilt thread_spread, aber auch vorbei
physische Prozessorchips.
s:
Verbreitung - Die Terminplaner werden so weit wie möglich verteilt.
nnts:
no_node_thread_spread - Mögen thread_spread, aber wenn mehrere NUMA (Non-Uniform
Da keine Knoten mit Speicherzugriff vorhanden sind, werden die Scheduler auf jeweils einen NUMA-Knoten verteilt
Zeit, d. h. alle logischen Prozessoren eines NUMA-Knotens werden an Scheduler in gebunden
Sequenz.
nnps:
no_node_processor_spread - Mögen Prozessor_Spread, aber wenn mehrere NUMA-Knoten
Wenn vorhanden, werden die Scheduler auf jeweils einen NUMA-Knoten verteilt, d. h. alle logisch
Prozessoren eines NUMA-Knotens werden nacheinander an Scheduler gebunden.
tnnps:
thread_no_node_processor_spread - Eine Kombination aus thread_spread und
no_node_processor_spread. Scheduler werden über Hardware-Threads verteilt
NUMA-Knoten, aber Scheduler werden nur intern auf einen Prozessor verteilt
jeweils einen NUMA-Knoten.
db:
default_bind – Bindet Scheduler auf die Standardmethode. Derzeit ist die Standardeinstellung
thread_no_node_processor_spread (was sich in Zukunft ändern könnte).
Die Bindung von Schedulern wird derzeit nur auf neueren Linux-, Solaris- und FreeBSD-Versionen unterstützt.
und Windows-Systeme.
Wenn keine CPU-Topologie verfügbar ist, wenn die +sbt Flag wird verarbeitet und BindType ist eine
anderer Typ als u, wird das Laufzeitsystem nicht gestartet. CPU-Topologie kann sein
definiert mit dem +sct Flagge. Notiere dass der +sct Eventuell muss zuvor die Flagge übergeben werden
+sbt Flag in der Befehlszeile (falls keine CPU-Topologie automatisch erstellt wurde).
erkannt).
Das Laufzeitsystem wird standardmäßig ausgeführt nicht Binden Sie Scheduler an logische Prozessoren.
Anmerkungen: Wenn das Erlang-Laufzeitsystem der einzige Betriebssystemprozess ist, der bindet
Durch die Verknüpfung von Threads mit logischen Prozessoren wird die Leistung des Laufzeitsystems verbessert.
Wenn jedoch andere Betriebssystemprozesse (z. B. eine andere Erlang-Laufzeitumgebung)
System) auch Threads an logische Prozessoren binden, kann es zu einer Performance kommen
stattdessen eine Strafe. In einigen Fällen kann diese Leistungseinbuße schwerwiegend sein. Wenn das ist
In diesem Fall wird empfohlen, die Planer nicht zu binden.
Es kommt darauf an, wie Planer gebunden sind. Zum Beispiel in Situationen, in denen es weniger gibt
laufende Prozesse als Scheduler online, versucht das Laufzeitsystem zu migrieren
Prozesse an Scheduler mit niedrigen Scheduler-IDs. Je mehr die Planer sind
Je mehr Ressourcen sich über die Hardware verteilen, desto mehr Ressourcen stehen dem Laufzeitsystem zur Verfügung
in solchen Situationen.
Anmerkungen: Wenn die Bindung eines Schedulers fehlschlägt, wird dies häufig stillschweigend ignoriert. Dies seitdem
Es ist nicht immer möglich, gültige logische Prozessor-IDs zu überprüfen. Wenn ein Fehler
gemeldet wird, wird es dem gemeldet error_logger. Wenn Sie überprüfen möchten, ob die
Planer haben tatsächlich wie gewünscht gebunden, rufen Sie an
erlang:system_info(scheduler_bindings).
+sbwt keine|sehr_kurz|kurz|mittel|lang|sehr_lang:
Legen Sie den Warteschwellenwert für die Auslastung des Planers fest. Standard ist mittlere. Der Schwellenwert bestimmt, wie
Wer lange Zeitpläne hat, sollte vor dem Schlafengehen warten, wenn ihm die Arbeit ausgeht.
Anmerkungen: Diese Flagge kann jederzeit und ohne vorherige Ankündigung entfernt oder geändert werden.
+skl wahr|falsch:
Aktivieren oder deaktivieren Sie die Scheduler-Komprimierung der Last. Standardmäßig ist die Scheduler-Komprimierung von
Last ist aktiviert. Wenn die Lastverteilung aktiviert ist, wird eine Lastverteilung angestrebt
Dadurch werden möglichst viele Scheduler-Threads vollständig geladen (d. h. nicht ausgeführt).
arbeitslos). Dies wird durch die Migration von Lasten (z. B. ausführbaren Prozessen) erreicht
eine kleinere Gruppe von Planern, wenn den Planern häufig die Arbeit ausgeht. Wann
deaktiviert ist, wird die Häufigkeit, mit der den Planern die Arbeit ausgeht, nicht berücksichtigt
Konto durch die Lastausgleichslogik.
+skl falsch ähnelt +sub was immer dies auch sein sollte. mit dem Unterschied, dass +sub was immer dies auch sein sollte. wird auch
Gleichen Sie die Scheduler-Nutzung zwischen den Schedulern aus.
+sct CPUTopologie:
* = ganze Zahl(); wann 0 =< =< 65535
* = -
* = |
* = , |
* = L
* = T | t
* = C | c
* = P | p
* = N | n
* = |
* CPUTopologie = : |
Legen Sie eine benutzerdefinierte CPU-Topologie fest. Die benutzerdefinierte CPU-Topologie überschreibt alle
automatisch erkannte CPU-Topologie. Die CPU-Topologie wird verwendet, wenn Bindung
Planer zu logisch Prozessoren.
Großbuchstaben stehen für echte Identifikatoren, Kleinbuchstaben für Fälschungen
Bezeichner werden nur zur Beschreibung der Topologie verwendet. Als echt übergebene Bezeichner
Bezeichner können vom Laufzeitsystem verwendet werden, wenn versucht wird, auf bestimmte Bezeichner zuzugreifen
Hardware und wenn sie nicht korrekt sind, ist das Verhalten undefiniert. Gefälschte logische CPU
Bezeichner werden nicht akzeptiert, da es keinen Sinn macht, die CPU-Topologie zu definieren
ohne echte logische CPU-Kennungen. Thread-, Kern-, Prozessor- und Knoten-IDs
kann weggelassen werden. Wenn es weggelassen wird, wird standardmäßig die Thread-ID verwendet t0, die Kern-ID ist standardmäßig auf c0,
Die Prozessor-ID ist standardmäßig auf p0und die Knoten-ID bleiben undefiniert. Entweder jeder logisch
Der Prozessor muss zu einem und nur einem NUMA-Knoten gehören, oder es dürfen keine logischen Prozessoren vorhanden sein
gehören zu beliebigen NUMA-Knoten.
Sowohl zunehmend als auch abnehmend s sind erlaubt.
NUMA-Knotenkennungen gelten systemweit. Das heißt, jeder NUMA-Knoten im System muss dies tun
haben eine eindeutige Kennung. Prozessorkennungen gelten auch systemweit. Kern
Bezeichner gelten prozessorweit. Thread-Bezeichner gelten kernweit.
Die Reihenfolge der Bezeichnertypen impliziert die Hierarchie der CPU-Topologie. Gültig
Bestellungen sind entweder , oder auch
. Das heißt, Thread ist Teil von
Ein Kern, der Teil eines Prozessors ist, der Teil eines NUMA-Knotens oder Threads ist
eines Kerns, der Teil eines NUMA-Knotens ist, der Teil eines Prozessors ist. Eine CPU-Topologie
kann sowohl aus prozessorexternen als auch aus prozessorinternen NUMA-Knoten bestehen, solange
Jeder logische Prozessor gehört zu genau einem NUMA-Knoten. Wenn is
weggelassen wird, ist die Standardposition vorher . Das heißt, die Standardeinstellung ist
Prozessor externe NUMA-Knoten.
Wenn eine Liste von Bezeichnern in einem verwendet wird :
* muss eine Liste von Bezeichnern sein.
* Mindestens ein weiterer Bezeichnertyp außer muss auch eine haben
Liste der Identifikatoren.
* Alle Identifikatorlisten müssen die gleiche Anzahl an Identifikatoren ergeben.
Ein einfaches Beispiel. Ein einzelner Quad-Core-Prozessor kann folgendermaßen beschrieben werden:
% erl +sct L0-3c0-3
1> erlang:system_info(cpu_topology).
[{Prozessor,[{Kern,{logisch,0}},
{core,{logical,1}},
{core,{logical,2}},
{core,{logical,3}}]}]
Ein etwas komplizierteres Beispiel. Zwei Quad-Core-Prozessoren. Jeder Prozessor in seinem
eigener NUMA-Knoten. Die Reihenfolge der logischen Prozessoren ist etwas seltsam. Dies in Ordnung
Um ein besseres Beispiel für Identifikatorlisten zu geben:
% erl +sct L0-1,3-2c0-3p0N0:L7,4,6-5c0-3p1N1
1> erlang:system_info(cpu_topology).
[{Knoten,[{Prozessor,[{Kern,{logisch,0}},
{core,{logical,1}},
{core,{logical,3}},
{core,{logical,2}}]}]},
{Knoten,[{Prozessor,[{Kern,{logisch,7}},
{core,{logical,4}},
{core,{logical,6}},
{core,{logical,5}}]}]}]
Solange die echten Bezeichner korrekt sind, ist es in Ordnung, eine CPU-Topologie zu übergeben
Keine korrekte Beschreibung der CPU-Topologie. Bei sorgfältiger Verwendung kann dies tatsächlich der Fall sein
sehr nützlich sein. Dies dient dazu, den Emulator dazu zu verleiten, seine Planer an Sie zu binden
wollen. Wenn Sie beispielsweise mehrere Erlang-Laufzeitsysteme auf demselben ausführen möchten
Maschine möchten Sie die Anzahl der verwendeten Scheduler reduzieren und die CPU manipulieren
Topologie, sodass sie an verschiedene logische CPUs gebunden werden können. Ein Beispiel mit zwei Erlang
Laufzeitsysteme auf einer Quad-Core-Maschine:
% erl +sct L0-3c0-3 +sbt db +S3:2 -tached -noinput -noshell -sname one
% erl +sct L3-0c0-3 +sbt db +S3:2 -tached -noinput -noshell -sname two
In diesem Beispiel sind für jedes Laufzeitsystem zwei Scheduler online, und zwar alle
Online-Scheduler laufen auf verschiedenen Kernen. Wenn wir zu einem Online-Planer wechseln
auf einem Laufzeitsystem und drei Scheduler online, auf dem anderen alle Scheduler
online wird weiterhin auf verschiedenen Kernen laufen.
Beachten Sie, dass es sich um eine gefälschte CPU-Topologie handelt, die nicht das Aussehen der echten CPU-Topologie widerspiegelt
Dies verringert wahrscheinlich die Leistung des Laufzeitsystems.
Für weitere Informationen, siehe erlang:system_info(cpu_topology).
+secio wahr|falsch:
Aktivieren oder deaktivieren Sie die E/A-Planung für eifrige Prüfungen. Der Standardwert ist derzeit was immer dies auch sein sollte.dem „Vermischten Geschmack“. Seine
Die Standardeinstellung wurde von geändert falsch zu was immer dies auch sein sollte. ab erts-Version 7.0. Das Verhalten vorher
Diese Flagge wurde eingeführt +secio falsch.
Das Flag wirkt sich darauf aus, wann Scheduler prüfen, ob E/A-Vorgänge ausgeführt werden können.
und wann solche E/A-Vorgänge ausgeführt werden. Wie der Name des Parameters schon sagt,
Planer werden mehr darauf bedacht sein, nach E/A-Vorgängen zu suchen was immer dies auch sein sollte. ist bestanden. Dies jedoch
bedeutet auch, dass der Ausführung ausstehender E/A-Vorgänge keine Priorität eingeräumt wird
im gleichen Ausmaß wie damals falsch ist bestanden.
erlang:system_info(eager_check_io) gibt den Wert dieses Parameters zurück, der verwendet wird, wenn
Starten der VM.
+sfwi Intervall:
Legen Sie das erzwungene Weckintervall des Planers fest. Es werden jeweils alle Laufwarteschlangen gescannt Intervall
Millisekunden. Während es im System schlafende Planer gibt, wird es einen Planer geben
wird für jede gefundene nicht leere Ausführungswarteschlange geweckt. Ein Intervall von Null deaktiviert dies
Funktion, die auch die Standardeinstellung ist.
Diese Funktion wurde als vorübergehende Problemumgehung für lange native Ausführungen eingeführt
Code und nativer Code, der die Reduzierungen in OTP nicht richtig anhebt. Wenn diese Fehler
wurden behoben +sfwi Flagge wird entfernt.
+stbt BindType:
Versuchen Sie, den Scheduler-Bindungstyp festzulegen. Das gleiche wie +sbt Flagge mit Ausnahme von wie
Einige Fehler werden behandelt. Weitere Informationen finden Sie in der Dokumentation des +sbt
Flagge.
+sub wahr|falsch:
Aktivieren oder deaktivieren Scheduler Nutzung Lastausgleich. Standardmäßiger Planer
Der Auslastungsausgleich ist deaktiviert und stattdessen die Planer-Verdichtung der Last
aktiviert, die eine Lastverteilung anstrebt, die möglichst viele Scheduler verursacht
Threads so weit wie möglich vollständig laden (d. h., dass ihnen nicht die Arbeit ausgeht). Beim Planer
Wenn der Auslastungsausgleich aktiviert ist, versucht das System stattdessen, den Planer auszugleichen
Auslastung zwischen Planern. Streben Sie also nach einer gleichmäßigen Scheduler-Auslastung
alle Planer.
+sub was immer dies auch sein sollte. wird nur auf Systemen unterstützt, auf denen das Laufzeitsystem a erkennt und verwendet
monoton steigender hochauflösender Takt. Auf anderen Systemen das Laufzeitsystem
wird nicht starten.
+sub was immer dies auch sein sollte. impliziert +skl falsch. Der Unterschied zwischen +sub was immer dies auch sein sollte. und +skl falsch is
zur Verbesserung der Gesundheitsgerechtigkeit +skl falsch wird nicht versuchen, die Scheduler-Auslastung auszugleichen.
+swct sehr_eifrig|eifrig|mittel|faul|sehr_faul:
Legen Sie den Schwellenwert für die Wake-Bereinigung des Schedulers fest. Standard ist mittlere. Dieses Flag steuert, wie
Eifrige Planer sollten aufgrund bestimmter Aufräumarbeiten eine Aktivierung anfordern.
Wenn eine Lazy-Einstellung verwendet wird, können weitere ausstehende Bereinigungsvorgänge rückgängig gemacht werden
während ein Scheduler im Leerlauf ist. Wenn eine Eager-Einstellung verwendet wird, können Planer mehr tun
werden häufig aktiviert, was möglicherweise die CPU-Auslastung erhöht.
Anmerkungen: Diese Flagge kann jederzeit und ohne vorherige Ankündigung entfernt oder geändert werden.
+sws Standard|Vermächtnis:
Legen Sie die Aktivierungsstrategie für den Planer fest. Die Standardstrategie wurde in erts-5.10/OTP-R16A geändert. Das
Strategie war früher bekannt als Angebot im OTP-R15. Der Erbe Strategie verwendet wurde
standardmäßig von R13 bis einschließlich R15.
Anmerkungen: Diese Flagge kann jederzeit und ohne vorherige Ankündigung entfernt oder geändert werden.
+swt sehr_niedrig|niedrig|mittel|hoch|sehr_hoch:
Legen Sie den Aktivierungsschwellenwert für den Zeitplaner fest. Standard ist mittlere. Der Schwellenwert bestimmt, wann
Wecken Sie schlafende Planer auf, wenn mehr Arbeit zu erledigen ist, als der gerade Wache bewältigen kann
Es gibt Planer. Ein niedriger Schwellenwert führt zu einem früheren Aufwachen, ein hoher Schwellenwert
wird späteres Aufwachen verursachen. Frühes Aufwachen verteilt die Arbeit auf mehrere
Planer schneller, aber die Arbeit kann leichter zwischen den Planern hin- und herwechseln.
Anmerkungen: Diese Flagge kann jederzeit und ohne vorherige Ankündigung entfernt oder geändert werden.
+spp Bool:
Legen Sie den Standard-Scheduler-Hinweis für Port-Parallelität fest. Wenn eingestellt auf was immer dies auch sein sollte., wird die VM
Durch die Planung von Port-Aufgaben wird die Parallelität im System verbessert. Wenn eingestellt auf
falsch, versucht die VM, Portaufgaben sofort auszuführen, wodurch die Latenz verbessert wird
Kosten der Parallelität. Wenn dieses Flag nicht übergeben wurde, wird der Standard-Scheduler-Hinweis verwendet
für Portparallelität ist derzeit falsch. Der verwendete Standard kann in eingesehen werden
Laufzeit durch Aufruf erlang:system_info(port_parallelism). Der Standardwert kann sein
Wird bei der Porterstellung durch Übergabe von überschrieben Parallelität Option zu open_port/2.
+sss Größe:
Empfohlene Stapelgröße in Kilowörtern für Scheduler-Threads. Der gültige Bereich liegt zwischen 4 und 8192
Kilowörter. Die Standardstapelgröße ist vom Betriebssystem abhängig.
+t Größe:
Legen Sie die maximale Anzahl von Atomen fest, die die VM verarbeiten kann. Der Standardwert ist 1048576.
+T Niveau:
Aktiviert das modifizierte Timing und legt den modifizierten Timing-Level fest. Derzeit gültiger Bereich ist
0-9. Das Timing des Laufzeitsystems wird sich ändern. Ein hohes Niveau bedeutet normalerweise a
größere Veränderung als ein niedriges Niveau. Das Ändern des Timings kann für die Suche sehr hilfreich sein
Timing-bezogene Fehler.
Derzeit wirkt sich die geänderte Zeitplanung auf Folgendes aus:
Prozess Laichen:
Ein Prozessaufruf laichen, spawn_link, spawn_monitor, oder auch spawn_opt wird geplant
sofort nach Beendigung des Anrufs ausgeblendet. Bei höheren geänderten Timing-Stufen handelt es sich
Wird diese Option verwendet, schläft der Anrufer auch eine Weile, nachdem er ausgeplant wurde.
Kontext Ermäßigungen:
Die Menge an Reduzierungen, die ein Prozess nutzen darf, bevor er ausgeplant wird
erhöht oder verringert.
Eingang Ermäßigungen:
Die Anzahl der vor der E/A-Prüfung durchgeführten Reduzierungen wird erhöht oder verringert.
Anmerkungen: Die Leistung wird beeinträchtigt, wenn das modifizierte Timing aktiviert ist. Diese Flagge ist einzige
zum Testen und Debuggen gedacht. Beachten Sie das auch zurückkehren zu und zurück aus Spur
Bei der Verfolgung der Spawn-BIFs gehen Nachrichten verloren. Dieses Flag kann entfernt werden oder
jederzeit ohne vorherige Ankündigung geändert werden.
+V:
Veranlasst den Emulator, seine Versionsnummer auszudrucken.
+v:
Ausführlich.
+W w | i | e:
Legt die Zuordnung von Warnmeldungen fest error_logger. An den Fehler gesendete Nachrichten
Logger, der eine der Warnroutinen verwendet, kann entweder auf Fehler (+W e),
Warnungen (+W w) oder Infoberichte (+W i). Der Standardwert sind Warnungen. Die aktuelle Zuordnung
kann abgerufen werden mit error_logger:warning_map/0. Sehen error_logger(3erl) für ein
Informationen.
+zFlag Wert:
Verschiedene Flaggen.
+zdbbl Größe:
Legen Sie das Auslastungslimit für den Verteilungspuffer fest (dist_buf_busy_limit) in Kilobyte. Gültig
Der Bereich liegt zwischen 1 und 2097151. Der Standardwert ist 1024.
Durch eine größere Puffergrenze können Prozesse mehr ausgehende Nachrichten puffern
Verteilung. Wenn das Pufferlimit erreicht ist, werden die Sendevorgänge gestartet
angehalten, bis die Puffergröße kleiner geworden ist. Das Pufferlimit gilt pro Verteilung
Kanal. Ein höherer Grenzwert führt zu einer geringeren Latenz und einem höheren Durchsatz auf Kosten
einer höheren Speichernutzung.
+zdntgc Zeit:
Legen Sie die verzögerte Garbage-Collection-Zeit für die Knotentabelle fest (verzögerter_node_table_gc) in
Sekunden. Gültige Werte sind entweder Unendlichkeit oder eine Ganzzahl im Bereich [0-100000000].
Standard ist 60.
Knotentabelleneinträge, auf die nicht verwiesen wird, verbleiben mindestens für die Zeit in der Tabelle
Zeitspanne, die dieser Parameter bestimmt. Das Verweilen verhindert wiederholtes
Löschungen und Einfügungen in den Tabellen werden verhindert.
VARIABLEN
ERL_CRASH_DUMP:
Wenn der Emulator einen Absturzspeicherauszug schreiben muss, ist der Wert dieser Variablen der
Dateiname der Crash-Dump-Datei. Wenn die Variable nicht gesetzt ist, der Name des Absturzes
Dump-Datei wird sein erl_crash.dump im aktuellen Verzeichnis.
ERL_CRASH_DUMP_NICE:
Unix Systeme: Wenn der Emulator einen Absturzspeicherauszug schreiben muss, verwendet er den Wert von
Verwenden Sie diese Variable, um den Nice-Wert für den Prozess festzulegen und so seine Priorität zu senken. Der
Der zulässige Bereich liegt zwischen 1 und 39 (höhere Werte werden durch 39 ersetzt). Das höchste
Der Wert 39 gibt dem Prozess die niedrigste Priorität.
ERL_CRASH_DUMP_SECONDS:
Unix Systeme: Diese Variable gibt die Anzahl der Sekunden an, die der Emulator benötigt
erlaubt, einen Crash-Dump zu schreiben. Wenn die angegebene Anzahl an Sekunden verstrichen ist,
Der Emulator wird durch ein SIGALRM-Signal beendet.
Wenn die Umgebungsvariable ist nicht eingestellt oder auf null Sekunden eingestellt,
ERL_CRASH_DUMP_SECONDS=0, wird das Laufzeitsystem nicht einmal versuchen, den Absturz zu schreiben
Dump-Datei. Es wird einfach beendet.
Wenn die Umgebungsvariable auf einen negativen Wert gesetzt ist, z.B. ERL_CRASH_DUMP_SECONDS=-1,
Das Laufzeitsystem wartet unbegrenzt darauf, dass die Crash-Dump-Datei geschrieben wird.
Diese Umgebungsvariable wird in Verbindung mit verwendet Herz if Herz läuft:
ERL_CRASH_DUMP_SECONDS=0:
Unterdrückt das Schreiben einer Crash-Dump-Datei vollständig und führt so zu einem Neustart des Laufzeitsystems
sofort. Dies ist dasselbe, als würde man die Umgebungsvariable nicht festlegen.
ERL_CRASH_DUMP_SECONDS=-1:
Das Festlegen der Umgebungsvariablen auf einen negativen Wert führt zur Beendigung von
Das Laufzeitsystem wartet, bis die Crash-Dump-Datei vollständig geschrieben wurde.
ERL_CRASH_DUMP_SECONDS=S:
Werde warten S Sekunden, um die Crash-Dump-Datei fertigzustellen, und beenden Sie dann die
Laufzeitsystem.
ERL_AFLAGS:
Der Inhalt dieser Umgebungsvariablen wird am Anfang des Befehls hinzugefügt
Linie für erl.
Die -extra Flagge wird besonders behandelt. Sein Geltungsbereich endet am Ende der Umgebung
variabler Inhalt. Argumente nach einem -extra Flag werden auf der Befehlszeile verschoben
in die -extra Abschnitt, d. h. das Ende der Befehlszeile, die nach einem folgt -extra
Flagge.
ERL_ZFLAGS und ERL_FLAGS:
Der Inhalt dieser Umgebungsvariablen wird am Ende des Befehls hinzugefügt
Linie für erl.
Die -extra Flagge wird besonders behandelt. Sein Geltungsbereich endet am Ende der Umgebung
variabler Inhalt. Argumente nach einem -extra Flag werden auf der Befehlszeile verschoben
in die -extra Abschnitt, d. h. das Ende der Befehlszeile, die nach einem folgt -extra
Flagge.
ERL_LIBS:
Diese Umgebungsvariable enthält eine Liste zusätzlicher Bibliotheksverzeichnisse, die die
Der Codeserver sucht nach Anwendungen und fügt sie dem Codepfad hinzu. Sehen Code(3erl).
ERL_EPMD_ADDRESS:
Diese Umgebungsvariable kann auf eine durch Kommas getrennte Liste von IP-Adressen festgelegt werden
In welchem Fall die epmd Der Daemon lauscht nur auf die angegebene(n) Adresse(n) und auf die
Loopback-Adresse (die implizit zur Liste hinzugefügt wird, wenn sie nicht angegeben wurde).
ERL_EPMD_PORT:
Diese Umgebungsvariable kann die Portnummer enthalten, die bei der Kommunikation verwendet werden soll
epmd. Der Standardport funktioniert in den meisten Fällen einwandfrei. Es kann ein anderer Port angegeben werden
um die Koexistenz von Knoten unabhängiger Cluster auf demselben Host zu ermöglichen. Alle Knoten in a
Der Cluster muss dieselbe epmd-Portnummer verwenden.
CONFIGURATION
Das standardmäßige Erlang/OTP-System kann neu konfiguriert werden, um das Standardverhalten zu ändern
Anlaufen.
Die .erlang anfang Datei:
Wenn Erlang/OTP gestartet wird, sucht das System nach einer Datei mit dem Namen .erlang im
Verzeichnis, in dem Erlang/OTP gestartet wird. Wenn nicht gefunden, handelt es sich um das Home-Verzeichnis des Benutzers
nach einer .erlang-Datei gesucht.
Wenn eine .erlang-Datei gefunden wird, wird davon ausgegangen, dass sie gültige Erlang-Ausdrücke enthält. Diese
Ausdrücke werden so ausgewertet, als ob sie in die Shell eingegeben würden.
Eine typische .erlang-Datei enthält eine Reihe von Suchpfaden, zum Beispiel:
io:format("Benutzerprofil wird in HOME/.erlang\n ausgeführt",[]).
code:add_path("/home/calvin/test/ebin").
code:add_path("/home/hobbes/bigappl-1.2/ebin").
io:format(".erlang rc abgeschlossen\n",[]).
user_default und shell_default:
Bei Funktionen in der Shell, denen kein Modulname vorangestellt ist, wird davon ausgegangen, dass dies der Fall ist
funktionale Objekte (Funs), integrierte Funktionen (BIFs) oder gehören zum Modul
user_default oder shell_default.
Um private Shell-Befehle einzuschließen, definieren Sie sie in einem Modul user_default und fügen Sie das hinzu
folgendes Argument als erste Zeile in der .erlang-Datei.
code:load_abs("..../user_default").
erl:
Wenn der Inhalt von .erlang geändert wird und eine private Version von user_default vorhanden ist
definiert, ist es möglich, die Erlang/OTP-Umgebung anzupassen. Stärkere Änderungen
kann durch die Angabe von Befehlszeilenargumenten im Startskript erl erfolgen. Beziehen auf
erl(1) und init(3erl) und fordern Sie weitere Informationen an.
Nutzen Sie Erl online über die Dienste von onworks.net