Lassen Sie uns über die potenziellen Blockierungspunkte von AOF in Redis sprechen (Zusammenfassung)

Was sind die potenziellen Blockierungspunkte von AOF? Der folgende Artikel fasst einige potenzielle Blockierungspunkte von AOF in Redis zusammen. Ich hoffe, er wird Ihnen hilfreich sein!

Was sind die potenziellen Blockierpunkte von AOF?

Fork-Unterprozess: Der Moment der Verzweigung blockiert definitiv den Hauptthread (beachten Sie, dass während der Verzweigung nicht alle Speicherdaten auf einmal in den untergeordneten Prozess kopiert werden).

Fork verwendet den vom Betriebssystem bereitgestellten Copy-On-Write-Mechanismus um ein einmaliges Kopieren zu vermeiden. Das Kopieren einer großen Menge an Speicherdaten führt zu langfristigen Blockierungsproblemen für untergeordnete Prozesse. [Verwandte Empfehlung: Redis-Video-Tutorial]Der untergeordnete Fork-Prozess muss jedoch die erforderlichen Datenstrukturen des Prozesses kopieren. Eine davon ist das Kopieren der Speicherseitentabelle (die Zuordnungsindextabelle des virtuellen Speichers und des physischen Speichers). ). Dieser Kopiervorgang verbraucht viele CPU-Ressourcen. Der gesamte Vorgang wird blockiert, bevor der Kopiervorgang abgeschlossen ist. Je größer die Instanz, desto größer die Speicherseitentabelle , und desto länger wird die Fork-Blockierungszeit sein.

Nachdem das Kopieren der Speicherseitentabelle abgeschlossen ist, verweisen der untergeordnete Prozess und der übergeordnete Prozess auf denselben Speicheradressraum. Das heißt, obwohl der untergeordnete Prozess zu diesem Zeitpunkt generiert wird, gilt dies nicht für denselben Speichergröße wie der übergeordnete Prozess.

Wann wird also die Erinnerung an die Prozesse von Vater und Sohn wirklich getrennt sein? Wie der Name schon sagt, bedeutet „realistisches Kopieren“, dass beim Schreiben tatsächlich die realen Daten im Speicher kopiert werden. Während dieses Vorgangs besteht möglicherweise auch die Gefahr einer Blockierung, was dem unten beschriebenen Szenario entspricht.

2), Der übergeordnete Prozess schreibt während des AOF-Umschreibens

Der untergeordnete Fork-Prozess zeigt auf denselben Speicheradressraum wie der übergeordnete Prozess. Zu diesem Zeitpunkt kann der untergeordnete Prozess das AOF-Umschreiben durchführen und den Speicher ändern Alle Die eingegebenen Daten werden in die AOF-Datei geschrieben.

Aber der übergeordnete Prozess wird zu diesem Zeitpunkt immer noch Datenverkehr schreiben. Wenn der übergeordnete Prozess einen vorhandenen Schlüssel betreibt, kopiert der übergeordnete Prozess zu diesem Zeitpunkt tatsächlich die dem Schlüssel entsprechenden Speicherdaten und beantragt darin neuen Speicherplatz Auf diese Weise beginnen sich die Speicherdaten der Vater- und Sohnprozesse allmählich zu trennen, und die Vater- und Sohnprozesse verfügen nach und nach über unabhängige Speicherräume. Da die Speicherzuweisung in Seiteneinheiten erfolgt, beträgt der Standardwert 4 KB. Wenn der übergeordnete Prozess zu diesem Zeitpunkt einen Bigkey ausführt, dauert es länger, einen großen Speicherblock erneut zu beantragen, was zu einer Blockierungsgefahr führen kann.

Wenn das Betriebssystem außerdem den

Huge-Page-Mechanismus (Seitengröße 2 MB) aktiviert, erhöht sich die Wahrscheinlichkeit, dass der übergeordnete Prozess beim Anfordern von Speicher blockiert wird, erheblich, sodass der Huge-Page-Mechanismus aktiviert werden muss auf der Redis-Maschine ausgeschaltet. Jedes Mal, wenn der Redis-Fork zum Generieren von RDB oder AOF-Rewrite abgeschlossen ist, können Sie im Redis-Protokoll sehen, wie viel Speicherplatz der übergeordnete Prozess erneut beantragt hat.

3) Warum verwendet AOF beim Umschreiben nicht die eigenen Protokolle von AOF wieder? Beim AOF-Umschreiben werden die eigenen Protokolle von AOF nicht wiederverwendet:

Ein Grund dafür ist, dass das Schreiben derselben Datei zwischen übergeordneten und untergeordneten Prozessen unweigerlich zu Konkurrenz führt Probleme zu kontrollieren bedeutet, die Leistung des übergeordneten Prozesses zu beeinflussen.

Zweitens: Wenn der AOF-Umschreibvorgang fehlschlägt, ist die ursprüngliche AOF-Datei gleichbedeutend mit einer Kontamination und kann nicht wiederhergestellt und verwendet werden. Daher schreibt Redis AOF eine neue Datei neu. Wenn das Umschreiben fehlschlägt, löschen Sie die Datei einfach direkt. Dies hat keine Auswirkungen auf die ursprüngliche AOF-Datei. Nachdem das Umschreiben abgeschlossen ist, ersetzen Sie einfach die alte Datei.

Weitere Programmierkenntnisse finden Sie unter: Programmiervideo

! !

Das obige ist der detaillierte Inhalt vonLassen Sie uns über die potenziellen Blockierungspunkte von AOF in Redis sprechen (Zusammenfassung). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!