Methoden zur Optimierung von Oracle-Datenbanken mit großen Speicherseiten unter Linux

Vorwort

PC Server hat sich bis heute weiterentwickelt und große Fortschritte hinsichtlich der Leistung gemacht. 64-Bit-CPUs sind seit einigen Jahren in normalen Heim-PCs verfügbar, von höherwertigen PC-Servern ganz zu schweigen. Dank der Bemühungen der beiden Prozessorgiganten Intel und AMD wurde die Verarbeitungsleistung von x86-CPUs kontinuierlich verbessert. Gleichzeitig wird mit der Entwicklung der Fertigungstechnologie auch die Speicherkapazität, die in PC-Server eingebaut werden kann, immer größer. Mittlerweile sieht man überall PC-Server mit mehreren zehn GB Speicher. Durch die Entwicklung der Hardware wird die Verarbeitungsleistung von PC-Servern immer leistungsfähiger und die Performance immer höher. Auch in puncto Stabilität kann die Kombination aus PCServer und Linux-Betriebssystem die Stabilitäts- und Zuverlässigkeitsanforderungen wichtiger Geschäftssysteme erfüllen. Was die Kosten angeht, möchte ich einen Internetnutzer zitieren, der für einen Hersteller von Industriesoftware arbeitet: „Wenn wir keine PC-Server, sondern Minicomputer verwenden, wie können wir dann Geld verdienen?“ Ob in der Anschaffung, im Energieverbrauch während des Betriebs oder bei den Wartungskosten: PC-Server sind deutlich günstiger als Minicomputer mit gleicher Rechenleistung. Unter dem Einfluss dieser beiden wichtigen Faktoren – Leistung und Kosten – laufen immer mehr Datenbanken auf PC-Servern. Einige meiner Kunden virtualisieren sogar High-End-PC-Server auf mehreren Maschinen und führen auf jeder virtuellen Maschine eine Oracle-Datenbank aus. Viele dieser Datenbanken enthalten wichtige Produktionssysteme.

Es besteht kein Zweifel, dass Linux das am besten geeignete Betriebssystem zum Ausführen einer Oracle-Datenbank auf einem PC-Server ist. Als UNIX sehr ähnliches Betriebssystem weist es hinsichtlich Stabilität, Zuverlässigkeit und Leistung die gleiche hervorragende Leistung wie UNIX auf. Im Vergleich zu AIX, HP-UX und anderen Betriebssystemen weist Linux jedoch einen offensichtlichen Defekt in seinem Speicher-Paging-Verarbeitungsmechanismus auf. Dieser Defekt ist besonders bei Oracle-Datenbanken offensichtlich, die einen größeren SGA verwenden. In schwerwiegenden Fällen hat er erhebliche negative Auswirkungen auf die Datenbankleistung und kann sogar dazu führen, dass die Datenbank überhaupt nicht mehr reagiert. In diesem Artikel wird dieser Defekt anhand eines Falles ausführlich erläutert und der Einsatz großer Speicherseiten unter Linux zur Lösung dieses Problems erläutert.

1. Einführung von Fallstudien

Auf einem der Systeme eines Kunden traten schwerwiegende Leistungsprobleme auf. Wenn das Problem auftritt, ist das System grundsätzlich unbrauchbar und alle Geschäftsvorgänge der Anwendung reagieren überhaupt nicht mehr. Die Systemdatenbank ist eine Oracle 10.2.0.4 Oracle-Datenbank, die unter RHEL 5.2 (Red Hat Enterprise Linux Server Release 5 (Tikanga)) läuft. Die CPU besteht aus 4 4-Core-Xeon-Prozessoren (Intel(R)Xeon(R) CPU E7430 @ 2,13 GHz), das heißt, es gibt 16 logische CPUs und der Speicher beträgt 32 GB. Während der Störung war die CPU des Datenbankservers über längere Zeit bei 100% ausgelastet. Selbst nachdem alle WebLogic-Server der Anwendung heruntergefahren wurden, bleibt die CPU-Auslastung des Datenbankservers mehrere Minuten lang bei 100 % und nimmt dann allmählich ab. Es dauert etwa 20 Minuten, bis der Server wieder in den normalen Leerlaufzustand zurückkehrt. Da zu diesem Zeitpunkt alle Anwendungen heruntergefahren sind, ist nur eine sehr geringe CPU-Auslastung ein normaler Zustand. Laut dem Datenbankwartungspersonal dieses Systems ist diese Situation schon oft aufgetreten. Selbst nach einem Neustart der Datenbank tritt ein solcher Fehler innerhalb von ein oder zwei Tagen erneut auf. Gleichzeitig hat es an diesem System in letzter Zeit keine größeren Änderungen gegeben.

Nach Erhalt des Fehlerberichts stellte der Autor fest, dass die Verbindung zur Datenbank über SSH sehr langsam war und das Herstellen der Verbindung fast 1 Minute dauerte. Werfen wir zunächst einen kurzen Blick auf die Leistung des Servers. Die Entwicklungs-IO ist extrem niedrig, es ist noch viel Restspeicher vorhanden, mindestens 1 GB oder mehr, und es gibt kein Page-In/Page-Out. Das auffälligste Phänomen ist, dass die CPU-Auslastung ziemlich hoch ist und immer bei 100 % gehalten wird. Gleichzeitig liegt der SYS-Teil der CPU-Auslastung über 95 %. Die Ausführungswarteschlange des Betriebssystems lag immer über 200. Die Serverspeichernutzung ist wie folgt:

$cat /proc/meminfo

SpeicherGesamt: 32999792 kB

MemFree: 1438672 kB

Puffer: 112304 kB

Zwischengespeichert: 23471680 kB

SwapCached: 1296 kB

Aktiv: 19571024 kB

Inaktiv: 6085396 kB

HochGesamt: 0 kB

HochFrei: 0 kB

NiedrigGesamt: 32999792 kB

NiedrigFrei: 1438672 kB

SwapGesamt: 38371320 kB

SwapFree: 38260796 kB

Schmutzig: 280 kB

Rückschreiben: 0kB

AnonSeiten: 2071192 kB

Kartiert: 12455324 kB

Platte: 340140 kB

Seitentabellen: 4749076 kB

NFS_Unstable: 0 kB

Absprung: 0 kB

CommitLimit: 54871216kB

Committed_AS: 17226744 kB

VmallocGesamt:34359738367 kB

VmallocVerwendet: 22016 kB

VmallocChunk:34359716303 kB

Aus Sicht des Phänomens ist eine hohe SYS-CPU ein wichtiger Hinweis zur Analyse des Problems.

Nachdem Sie sich schnellstmöglich mit der Leistung des Betriebssystems vertraut gemacht haben, stellen Sie sofort über Sqlplus eine Verbindung zur Datenbank her, um die Leistungsinformationen in der Datenbank anzuzeigen:

(Hinweis: Folgende Daten wurden hinsichtlich SQL, Servername, Datenbankname etc. verarbeitet.)

SQL> wähle sid, Seriennummer, Programm, Maschine, SQL-ID, Ereignis aus v$session, wobei Typ = „BENUTZER“ und Status = „AKTIV“ ist;

SID SERIENNUMMER PROGRAMM MASCHINE SQL_ID EREIGNIS

-------------------- ------------------------------ ---------- ----------

519 4304 xxx_app1 0gc4uvt2pqvpu Latch: Cache-Pufferketten

459 12806 xxx_app1 0gc4uvt2pqvpu Latch: Cache-Pufferketten

454 5518 xxx_app1 15hq76k17h4ta Latch: Cache-Pufferketten

529 7708 xxx_app1 0gc4uvt2pqvpu Latch: Cache-Pufferketten

420 40948 xxx_app1 0gc4uvt2pqvpu Latch: Cache-Pufferketten

353 56222 xxx_app1 f7fxxczffp5rx Latch: Cache-Pufferketten

243 42611 xxx_app1 2zqg4sbrq7zay Latch: Cache-Pufferketten

458 63221 xxxTimer.exe APPSERVER 9t1ujakwt6fnf lokales Schreiben warten

...Einige Inhalte wurden aus Platzgründen weggelassen...

409 4951 xxx_app1 7d4c6m3ytcx87 von anderer Sitzung gelesen

239 51959 xxx_app1 7d4c6m3ytcx87 von anderer Sitzung gelesen

525 3815 xxxTimer.exe APPSERVER 0ftnnr7pfw7r6 enq: RO -fast Objekt reu

518 7845 xxx_app1 Protokolldateisynchronisierung

473 1972 xxxTimer.exe APPSERVER 5017jsr7kdk3b Protokolldatei-Synchronisierung

197 37462 xxx_app1 cbvbzbfdxn2w7 db-Datei sequentiell lesen

319 4939 xxxTimer.exe APPSERVER 6vmk5uzu1p45m db-Datei sequentielles Lesen

434 2939 xxx_app1 gw921z764rmkc Latch: gemeinsam genutzter Pool

220 50017 xxx_app1 2zqg4sbrq7zay Latch: Bibliothekscache

301 36418 xxx_app1 02dw161xqmrgf Latch: Bibliothekscache

193 25003 oracle@xxx_db1 (J001) xxx_db1 Jobq-Slave wartet

368 64846 oracle@xxx_db1 (J000) xxx_db1 jobq Slave warten

218 13307 sqlplus@xxx_db1 (TNS V1-V3) xxx_db1 5rby2rfcgs6b7 SQL*Net-Nachricht an den Client

435 1883 xxx_app1 fd7369jwkuvty SQL*Net-Nachricht vom Client

448 3001 xxxTimer.exe APPSERVER bsk0kpawwztnwSQL*Net-Nachricht von dblink


SQL>@waitevent

SID-Ereignis: Sekunden im Wartezustand

------------------------------------ --------------- -------------------

556 Latch: Cache-Pufferketten 35 BEKANNTE WARTEZEIT

464 Latch:Cache-Pufferketten 2 WARTEN

427 Latch:Cache-Pufferketten 34 KURZE ZEIT GEWARTET

458 localwrite warte 63 WARTEN

403 writecomplete wartet 40 WARTEN

502 Schreibabschluß wartet 41 WARTEN

525 enq:RO - schnelle Objektwiederverwendung 40 WARTEN

368 enq:RO - schnelle Objektrückgabe 23 WAITING

282 db Datei sequentiell lesen 0 WARTEN

501 dbfile sequentielles Lesen 2 KURZE ZEIT GEWARTET

478 db Datei sequentiell lesen 0 WARTEN

281 DB-Datei, sequentielles Lesen, 6 Wartezeit, bekannte Zeit

195 db Datei sequentiell lesen 4 GEWARTET BEKANNTE ZEIT

450 db Datei sequentielles Lesen 2 WARTEZEIT BEKANNTE

529 db Datei sequentiell lesen 1 WARTEN

310 dbfile sequentielles Lesen 0 WARTEZEIT BEKANN

316 db Dateisequentielles Lesen 89 KURZE ZEIT GEWARTET

370 db Datei sequentiell lesen 1 WARTEN

380 db Datei sequentiell lesen 1 KURZE ZEIT GEWARTET

326 Jobq Sklave warten 122 WARTEN

378 jobq Sklave warten 2 WARTEN

425 Jobq Sklave warten 108 WARTEN

208 SQL*Net mehr Daten von db 11 WARTETE KURZE ZEIT link

537 Streams AQ: Warten auf t 7042 WARTEN Zeitmanagement oder Bereinigungsaufgaben

549 Streams AQ: qmn-Koordination 1585854 WARTEN oder Leerlauf warten

507 Streams AQ: qmn Slave Idl 1585854 WARTEND e warten

430 Riegel frei 2 GEWARTET BEKANNTE ZEIT

565 Latch:Cache-Puffer lru 136 KURZE ZEIT GEWARTET Kette

Gemessen an den Aktivitäten in der Datenbank und den Warteereignissen gibt es nichts Ungewöhnliches. Es ist zu beachten, dass bei einer längeren CPU-Auslastung des Datenbankservers von 100 % oder einer Erschöpfung des physischen Speichers und einem damit einhergehenden Ein- und Auslagern einer großen Menge an Swap-Speicher eine sorgfältige Diagnose der Leistungsphänomene in der Datenbank erforderlich ist. Beispielsweise muss geprüft werden, ob eine bestimmte Art von Warteereignis das Ergebnis unzureichender CPU- oder Speicherauslastung ist oder ob bestimmte Aktivitäten in der Datenbank die Grundursache für eine übermäßige CPU- oder Speicherauslastung sind.

Den obigen Daten zufolge gibt es nicht viele aktive Sitzungen, weniger als 50. Dazu kommt die Anzahl der Hintergrundprozesse, die sich deutlich von den 200 unterscheidet, die im Betriebssystem laufen. Es gibt drei Haupttypen von Nicht-Leerlauf-Warteereignissen in der Datenbank: E/A-bezogene Warteereignisse, wie z. B. das sequenzielle Lesen von Datenbankdateien, mit der Datenbankverknüpfung verbundene SQL*Net-Daten (mehr von DBLink) und Latch-bezogene Warteereignisse. Von diesen drei Kategorien führen normalerweise nur Warteereignisse wie Latches zu einer erhöhten CPU-Auslastung.

Durch Analysieren und Vergleichen der AWR-Berichte ist kein besonders offensichtlicher Unterschied in der Datenbankaktivität während des Fehlerzeitraums und des Normalzeitraums erkennbar. Aber in Bezug auf die Systemstatistiken gibt es große Unterschiede:

Statistikname 1. 2. Wert

------------------------------------------------- -------------- ------------------------

BUSY_TIME 3.475.776 1.611.753

IDLE_TIME 2.266.224 4.065.506

IOWAIT_TIME 520.453 886.345

LAST -67 -3

SCHÖNE ZEIT 0 0

Anzahl CPU-Sockel 0 0

PHYSISCHE_SPEICHER_BYTES 0 0

RSRC_MGR_CPU_WAIT_TIME 0 0

SYS_TIME 1.802.025 205.644

BENUTZERZEIT 1.645.837 1.381.719

Bei den obigen Daten handelt es sich um Vergleichsdaten von AWR für 1 Stunde (1.) einschließlich der Fehlerperiode und 1 Stunde (2.) während der Normalperiode. Bei der Fehleranalyse, insbesondere wenn die Fehlerdauer kurz ist, gibt ein 1-stündiger AWR-Bericht die Leistung während des Fehlerzeitraums nicht genau wieder. Bei der Fehlerbehebung müssen wir jedoch zunächst die Richtung anhand verschiedener Daten bestimmen. Wie bereits erwähnt, ist eine hohe CPU-Auslastung im SYS-Bereich ein wichtiger Hinweis. Wenn andere Leistungsdaten innerhalb der Datenbank nicht viel anders sind, können Sie mit der CPU beginnen.

2. Analyse der CPU-Auslastung im Betriebssystem

Was also stellen die beiden unterschiedlichen Verwendungen von SYS und USER im Betriebssystem dar? Oder was ist der Unterschied zwischen den beiden?

Einfach ausgedrückt bezieht sich der SYS-Teil der CPU-Auslastung auf den CPU-Teil, der vom Betriebssystemkernel (Kernel) verwendet wird, d. h. die CPU, die vom im Kernelstatus ausgeführten Code verbraucht wird. Am häufigsten wird die CPU während Systemaufrufen (SYS CALL) verbraucht. Der USER-Teil ist der CPU-Teil, der vom eigenen Code der Anwendungssoftware verwendet wird, d. h. die CPU, die vom im Benutzermodus ausgeführten Code verbraucht wird. Wenn Oracle beispielsweise SQL ausführt, muss es einen Leseaufruf initiieren, um Daten von der Festplatte in den DB-Puffercache zu lesen. Dieser Leseaufruf wird hauptsächlich vom Betriebssystemkernel einschließlich des Gerätetreibercodes ausgeführt, sodass der CPU-Verbrauch im SYS-Teil berechnet wird. Wenn Oracle die von der Festplatte gelesenen Daten analysiert, wird nur Oracles eigener Code ausgeführt, sodass der CPU-Verbrauch im USER-Teil berechnet wird.

Welche Vorgänge oder Systemaufrufe werden also die CPU im SYS-Teil generieren?

1. E/A-Vorgänge wie Lesen und Schreiben von Dateien, Zugriff auf Peripheriegeräte und Übertragen von Daten über das Netzwerk. Dieser Teil des Vorgangs verbraucht im Allgemeinen nicht zu viel CPU, da die Hauptzeit auf dem Gerät für E/A-Vorgänge aufgewendet wird. Wenn Sie beispielsweise eine Datei von der Festplatte lesen, wird die meiste Zeit für Vorgänge innerhalb der Festplatte aufgewendet, und die benötigte CPU-Zeit macht nur einen kleinen Teil der Reaktionszeit der E/A-Vorgänge aus. Die SYS-CPU-Auslastung kann nur dann ansteigen, wenn die gleichzeitige E/A zu hoch ist.

2. Speicherverwaltung, wie z. B. der Anwendungsvorgang, der Speicher vom Betriebssystem anfordert, das Betriebssystem, das den verfügbaren Speicher des Systems verwaltet, das Auslagern von Speicherseiten usw. Tatsächlich ist es ähnlich wie bei Oracle: Je größer der Speicher und je häufiger die Speicherverwaltungsvorgänge sind, desto höher ist die CPU-Auslastung.

3. Prozessplanung. Die Auslastung dieses Teils der CPU hängt von der Länge der Ausführungswarteschlange im Betriebssystem ab. Je länger die Ausführungswarteschlange, desto mehr Prozesse müssen geplant werden und desto höher ist die Belastung des Kernels.

4. Sonstiges, einschließlich Interprozesskommunikation, Semaphorverarbeitung, einige Aktivitäten innerhalb des Gerätetreibers usw.

Gemessen an den Leistungsdaten bei Systemausfällen können die hohe SYS-CPU-Auslastung möglicherweise auf die Speicherverwaltung und die Prozessplanung zurückzuführen sein. Wenn die Ausführungswarteschlange jedoch 200 oder mehr Punkte umfasst, liegt dies höchstwahrscheinlich an einer hohen CPU-Auslastung und nicht daran, dass die hohe Ausführungswarteschlange eine hohe CPU-Auslastung verursacht. Aus der Datenbank geht hervor, dass die Anzahl aktiver Sitzungen nicht besonders hoch ist. Dann müssen wir darauf achten, ob die hohe CPU-Auslastung durch Probleme mit der Systemspeicherverwaltung verursacht wird.

Wenn wir auf die Systemspeicherdaten zurückblicken, die zu Beginn dieses Artikels in /proc/meminfo gesammelt wurden, können wir wichtige Daten finden:

Seitentabellen: 4749076 kB

Aus den Daten können wir ersehen, dass der PageTables-Speicher 4637 MB erreicht hat. PageTables bedeutet wörtlich „Seitentabelle“. Einfach ausgedrückt handelt es sich dabei um eine Tabelle, die vom Betriebssystemkernel verwendet wird, um die Entsprechung zwischen der linearen virtuellen Prozessadresse und der tatsächlichen physischen Speicheradresse aufrechtzuerhalten.

Moderne Computer verwalten und ordnen physischen Speicher normalerweise in Seiteneinheiten (Page Frames) zu. Bei der x86-Prozessorarchitektur beträgt die Seitengröße 4 KB. Der Adressraum, auf den ein auf einem Betriebssystem laufender Prozess zugreifen kann, wird als virtueller Adressraum bezeichnet und hängt mit der Anzahl der Bits im Prozessor zusammen. Bei 32-Bit-x86-Prozessoren beträgt der für einen Prozess zugängliche Adressraum 4 GB. Jeder im Betriebssystem ausgeführte Prozess verfügt über einen eigenen unabhängigen virtuellen Adressraum oder linearen Adressraum, und dieser Adressraum wird ebenfalls seitenweise verwaltet. Unter Linux beträgt die Seitengröße normalerweise 4 KB. Wenn ein Prozess auf den Speicher zugreift, arbeiten Betriebssystem und Hardware zusammen, um die virtuelle Adresse des Prozesses in eine physische Adresse umzuwandeln. Dieselbe virtuelle lineare Adresse zweier verschiedener Prozesse kann auf denselben physischen Speicher verweisen, z. B. auf den gemeinsam genutzten Speicher. Sie kann aber auch auf unterschiedliche Speicher verweisen, z. B. auf den privaten Speicher des Prozesses.

Die folgende Abbildung zeigt eine schematische Darstellung der Entsprechung zwischen virtuellen Adressen und physischem Speicher:

Angenommen, es gibt zwei Prozesse A und B, von denen jeder einen Speicherzeiger hat, der auf die Adresse 0x12345 zeigt (0x steht für eine Hexadezimalzahl). Wenn beispielsweise ein Prozess einen anderen Prozess verzweigt oder klont, dann haben die beiden Prozesse Zeiger, die auf dieselbe Speicheradresse zeigen. Wenn ein Prozess auf den Speicher zugreift, auf den die Adresse 0x12345 zeigt, konvertiert das Betriebssystem diese Adresse in eine physikalische Adresse. Beispielsweise ist Prozess A 0x23456 und Prozess B 0x34567. Die beiden beeinflussen sich nicht gegenseitig. Wann wurde diese physische Adresse erhalten? Bei prozessprivatem Speicher (was in den meisten Fällen der Fall ist) wird er abgerufen, wenn der Prozess eine Speicherzuweisung vom Betriebssystem anfordert. Wenn ein Prozess vom Betriebssystem eine Speicherzuweisung anfordert, weist das Betriebssystem dem Prozess freien physischen Speicher in Seiteneinheiten zu, generiert eine virtuelle Thread-Adresse für den Prozess, stellt eine Zuordnungsbeziehung zwischen der virtuellen Adresse und der physischen Speicheradresse her und gibt diese virtuelle Adresse als Ergebnis an den Prozess zurück.

Eine Seitentabelle ist eine Datenstruktur, die vom Betriebssystem verwendet wird, um die Entsprechung zwischen der virtuellen Prozessadresse und dem physischen Speicher aufrechtzuerhalten. Die folgende Abbildung ist eine schematische Darstellung der Seitentabelle in einem relativ einfachen Fall:

Nachfolgend finden Sie eine kurze Beschreibung, wie das Betriebssystem zwischen der virtuellen Adresse und der tatsächlichen physischen Adresse eines Prozesses in einem 32-Bit-System konvertiert, wenn die Seitengröße 4 KB beträgt.

1. Die Verzeichnistabelle ist eine Datenstruktur, die zum Indizieren der Seitentabelle verwendet wird. Jeder Verzeichniseintrag belegt 32 Bit oder 4 Byte und speichert den Speicherort einer Seitentabelle. Die Verzeichnistabelle nimmt genau 1 Speicherseite oder 4 KB ein und kann 1024 Verzeichniseinträge speichern, was bedeutet, dass sie 1024 Seitentabellenspeicherorte speichern kann.

2. Die Größe eines Seitentabelleneintrags beträgt 4 Bytes und speichert die Startadresse einer physischen Speicherseite. Jede Seitentabelle belegt außerdem 4 KB Speicher und kann die Startadressen von 1024 physischen Speicherseiten speichern. Da die Startadresse der physischen Speicherseite in Einheiten von 4 KB ausgerichtet ist, werden nur 20 Bits von 32 Bits benötigt, um die Adresse darzustellen, und die anderen 12 Bits werden für andere Zwecke verwendet, beispielsweise um anzuzeigen, ob die Speicherseite schreibgeschützt oder beschreibbar ist usw.

3. 1024 Seitentabellen, jede Seitentabelle hat 1024 physische Speicherseitenstartadressen, insgesamt 1 Million Adressen. Die Größe der physischen Speicherseite, auf die jede Adresse zeigt, beträgt 4 KB, insgesamt 4 GB.

4. Wenn das Betriebssystem und die Hardware die virtuelle Adresse einer physischen Adresse zuordnen, werden die 10 Bits 31-22 der virtuellen Adresse verwendet, um vom Verzeichniseintrag zu einer der 1024 Seitentabellen zu indizieren; die 10 Bits 12-21 der virtuellen Adresse werden verwendet, um von der Seitentabelle zu einem der 1024 Seitentabelleneinträge zu indizieren. Die Startadresse der physischen Speicherseite wird aus dem indizierten Seitentabelleneintrag abgerufen, und dann werden die 12 Bits 0-11 der virtuellen Adresse als Offset in der 4-KB-Speicherseite verwendet. Dann ist die Startadresse der physischen Speicherseite plus der Offset die Adresse des physischen Speichers, auf den der Prozess zugreifen muss.

Schauen wir uns an, wie viel Platz die beiden Datenstrukturen, Verzeichnistabelle und Seitentabelle, einnehmen. Die Verzeichnistabelle ist auf 4 KB festgelegt. Und was ist mit der Seitentabelle? Da es höchstens 1024 Seitentabellen gibt und jede Seitentabelle 4 KB belegt, belegt die Seitentabelle höchstens 4 MB Speicher.

In der Praxis haben Prozesse in 32-Bit-Linux normalerweise keine so großen Seitentabellen. Es ist unmöglich, dass ein Prozess den gesamten 4-GB-Adressraum nutzt, und dem Kernel ist sogar 1 GB des virtuellen Adressraums zugewiesen. Gleichzeitig erstellt Linux nicht auf einmal eine so große Seitentabelle für einen Prozess. Erst wenn der Prozess Speicher zuweist und darauf zugreift, erstellt das Betriebssystem eine Zuordnung der entsprechenden Adresse für den Prozess.

Hier wird nur der einfachste Fall der Paging-Zuordnung beschrieben. Tatsächlich gibt es zusammen mit der Seitentabelle vier Ebenen von Seitentabellenverzeichnissen. Gleichzeitig ist die Seitentabellenstruktur komplizierter als im obigen Diagramm, wenn PAE in einem 32-Bit- oder 64-Bit-System aktiviert ist. Aber egal was passiert, die Struktur der letzten Ebene, der Seitentabelle, ist konsistent.

In einem 64-Bit-System erhöht sich die Größe der Seitentabelleneinträge in der Seitentabelle von 32 Bit auf 64 Bit im Vergleich zu 32 Bit. Wie groß werden die Auswirkungen sein? Wenn ein Prozess auf 1 GB physischen Speicher zugreift, also 262144 Speicherseiten, benötigt die Seitentabelle in einem 32-Bit-System 262144 * 4/1024/1024 = 1 MB, während in einem 64-Bit-System der von der Seitentabelle belegte Speicherplatz um das 1-fache, also 2 MB, zunimmt.

Sehen wir uns nun an, wie die Situation für Oracle-Datenbanken ist, die auf Linux-Systemen laufen. In diesem Fall beträgt die SGA-Größe der Datenbank 12 GB. Wenn ein OracleProcess auf den gesamten SGA-Speicher zugreift, beträgt die Seitentabellengröße 24 MB, was eine erstaunliche Zahl ist. PGA wird hier ignoriert, da der PGA jedes Prozesses im Durchschnitt 2 M nicht überschreitet, was im Vergleich zu SGA zu klein ist. Laut dem AWR-Bericht gibt es etwa 300 Sitzungen, sodass die Seitentabelle dieser 300 Verbindungen 7200 MB erreicht, aber nicht jeder Prozess auf den gesamten Speicher im SGA zugreift. Die Seitentabellengröße beträgt laut Meminfo 4637 MB. Ein so großer Seitentabellenspeicherplatz ist das Ergebnis von 300 Sitzungen und einer SGA-Größe von 12 GB.

Offensichtlich ist die Seitentabelle nicht die einzige Datenstruktur zur Speicherverwaltung im System. Es gibt auch andere Datenstrukturen, die zur Speicherverwaltung verwendet werden. Diese übermäßig großen Speicherverwaltungsstrukturen erhöhen zweifellos die Belastung des Betriebssystemkernels und den CPU-Verbrauch erheblich. Wenn sich jedoch die Last ändert oder aus anderen Gründen der Speicherbedarf erheblich ändert (z. B. wenn mehrere Prozesse gleichzeitig eine große Speichermenge beanspruchen), kann die CPU in kurzer Zeit ihre Spitzenlast erreichen und dadurch Probleme verursachen.

3. Verwenden Sie große Speicherseiten, um das Problem zu lösen

Obwohl es keine eindeutigen Beweise gab und nicht genug Zeit blieb, um ausreichend Beweise dafür zu sammeln, dass das Problem durch eine zu große Seitentabelle verursacht wurde, hätte man sich mit mehreren Systemausfällen von über einer halben Stunde auseinandersetzen müssen. Doch gerade hier liegt aus heutiger Sicht der größte Verdachtspunkt. Daher wurde entschieden, zunächst große Speicherseiten zu verwenden, um die Speichernutzung des Systems zu optimieren.

Große Speicherseite ist ein allgemeiner Begriff. In früheren Linux-Versionen wird sie als „Large Page“ bezeichnet, in aktuellen Mainstream-Linux-Versionen als „Huge Page“. Im Folgenden werden am Beispiel von Huge Page die Vorteile und Einsatzmöglichkeiten von Huge Page veranschaulicht.

Welche Vorteile bietet die Verwendung großer Speicherseiten:

1. Reduzieren Sie die Größe der Seitentabelle. Jede Huge Page entspricht 2 MB kontinuierlichem physischen Speicher, sodass 12 GB physischer Speicher nur eine 48 KB große Seitentabelle erfordern, was viel weniger ist als die ursprünglichen 24 MB.

2. Riesiger Seitenspeicher kann nur im physischen Speicher gesperrt und nicht in den Swap-Bereich ausgelagert werden. Dadurch werden Leistungseinbußen durch Swapping vermieden.

3. Durch die Reduzierung der Anzahl der Seitentabellen wird die Trefferquote des TLB in der CPU (die als CACHE der CPU für Seitentabellen verstanden werden kann) erheblich verbessert.

4. Die Seitentabelle für Huge Page kann zwischen Prozessen gemeinsam genutzt werden, wodurch auch die Größe der Seitentabelle reduziert wird. Tatsächlich spiegelt dies die Mängel im Paging-Verarbeitungsmechanismus von Linux wider. Andere Betriebssysteme wie etwa AIX nutzen für den Speicher die gleiche Seitentabelle, etwa gemeinsam genutzte Speichersegmente, wodurch dieses Problem in Linux vermieden wird. Beispielsweise beträgt die Anzahl der Verbindungen in einem vom Autor verwalteten System normalerweise mehr als 5.000 und die SGA der Instanz beträgt etwa 60 GB. Wenn die Linux-Paging-Methode verwendet wird, wird der größte Teil des Speichers im System von der Seitentabelle belegt.

Wie aktivieren Sie also große Seiten für Oracle? Hier sind die Schritte zur Implementierung. Da die in dem Fall involvierte Datenbank den SGA nach einer gewissen Zeit auf 18G anpasste, wird 18G hier als Beispiel verwendet:

1. Überprüfen Sie /proc/meminfo, um zu bestätigen, dass das System HugePage unterstützt:

HugePages_Total: 0

HugePages_Free: 0

HugePages_Rsvd: 0

Riesige Seitengröße: 2048 kB

„HugePages Total“ gibt die Anzahl der im System konfigurierten großen Speicherseiten an. HugePages Free gibt die Anzahl der großen Speicherseiten an, auf die nicht zugegriffen wurde. Das Wort „frei“ ist hier irreführend, was später erklärt wird. HugePages Rsvd gibt die Anzahl der Seiten an, die zugewiesen, aber noch nicht verwendet wurden. Hugepagesize gibt die Größe der großen Speicherseite an, die hier 2 MB beträgt. Beachten Sie, dass sie in einigen Kernelkonfigurationen 4 MB betragen kann.

Wenn beispielsweise HugePages insgesamt 11 GB groß ist, beträgt SGA_MAX_SIZE 10 GB und SGA_TARGET 8 GB. Nach dem Start der Datenbank wird der HugePage-Speicher gemäß SGA_MAX_SIZE zugewiesen, was hier 10 GB beträgt. Der tatsächliche freie HugePage-Speicher beträgt 11-10 = 1 G. SGA_TARGET ist jedoch nur 8 GB groß, sodass auf 2 GB nicht zugegriffen wird, und HugePage_Free ist 2+1=3 GB und der HugePage_Rsvd-Speicher hat 2 GB. Tatsächlich kann nur 1 GB von anderen Instanzen verwendet werden, was bedeutet, dass nur 1 GB wirklich frei ist.

2. Planen Sie die Anzahl der einzustellenden Speicherseiten. Bisher waren riesige Seiten nur für wenige Speichertypen verfügbar, beispielsweise für gemeinsam genutzte Speichersegmente. Sobald der physische Speicher in Form von großen Seiten verwendet wird, kann er nicht mehr für andere Zwecke, beispielsweise als privater Speicher eines Prozesses, genutzt werden. Daher kann nicht zu viel Speicher als große Speicherseiten festgelegt werden. Wir verwenden normalerweise große Speicherseiten als SGA der Oracle-Datenbank, daher beträgt die Anzahl der großen Speicherseiten:

HugePages_Total = Decke(SGA_MAX_SIZE/Hugepagesize)+N

Wenn beispielsweise SGA_MAX_SIZE für die Datenbank auf 18 GB festgelegt ist, kann die Seitenanzahl ceil(18*1024/2)+2=9218 betragen.

Das Hinzufügen von N bedeutet hier, dass der HugePage-Speicherplatz etwas größer als SGA_MAX_SIZE eingestellt werden muss, normalerweise 1-2. Wir verwenden den Befehl ipcs -m, um die Größe des gemeinsam genutzten Speichersegments zu überprüfen, und können sehen, dass die Größe des gemeinsam genutzten Speichersegments tatsächlich größer als SGA_MAX_SIZE ist. Wenn sich auf dem Server mehrere Oracle-Instanzen befinden, müssen Sie den zusätzlichen Teil des gemeinsam genutzten Speichersegments für jede Instanz berücksichtigen, d. h., je größer der N-Wert ist. Darüber hinaus verwenden Oracle-Datenbanken entweder alle oder überhaupt keine großen Speicherseiten, sodass ein unangemessener Wert für „HugePages_Total“ zu einer Speicherverschwendung führt.

Zusätzlich zur Verwendung von SGA_MAX_SIZE für die Berechnung können Sie auch einen genaueren HugePages_Total berechnen, indem Sie die durch ipcs -m ermittelte Größe des gemeinsam genutzten Speichersegments verwenden.

HugePages_Total = Summe(Decke(Share-Segmentgröße/Hugepagesize))

3. Ändern Sie die Datei /etc/sysctl.conf und fügen Sie die folgende Zeile hinzu:

vm.nr_hugepages=9218

Führen Sie dann den Befehl sysctl –p aus, damit die Konfiguration wirksam wird.

Hier ist der Parameterwert von vm.nr_hugepages die Anzahl der großen Speicherseiten, die in Schritt 2 berechnet wurde. Überprüfen Sie dann /proc/meminfo. Wenn HugePages_Total kleiner als die festgelegte Zahl ist, bedeutet dies, dass nicht genügend kontinuierlicher physischer Speicher für diese großen Speicherseiten vorhanden ist und der Server neu gestartet werden muss.

4. Fügen Sie der Datei /etc/security/limits.conf die folgende Zeile hinzu:

Oracle-Soft-Memlock 18878464

Oracle Hard Memlock 18878464

Legen Sie hier die Speichergröße in KB fest, die der Oracle-Benutzer sperren kann.

Stellen Sie dann als Oracle-Benutzer erneut eine Verbindung zum Datenbankserver her und verwenden Sie den Befehl ulimit -a, um Folgendes anzuzeigen:

maximaler gesperrter Speicher (KB, -l) 18878464

Es ist hier auch möglich, Memlock auf unbegrenzt zu konfigurieren.

5. Wenn die Datenbank die MANUAL-Methode zum Verwalten des SGA verwendet, müssen Sie sie auf die AUTO-Methode ändern, d. h. SGA_TARGET_SIZE auf einen Wert größer als 0 setzen. Da HugePage für 11g nur für gemeinsam genutzten Speicher und nicht für PGA verwendet werden kann, kann AMM nicht verwendet werden, d. h. MEMORY_TARGET kann nicht größer als 0 gesetzt werden. SGA und PGA können nur separat gesetzt werden und SGA kann nur im AUTO-Modus verwaltet werden.

6. Starten Sie abschließend die Datenbank und überprüfen Sie /proc/meminfo, um zu sehen, ob HugePages_Free gesunken ist. Wenn der Wert gesunken ist, weist dies darauf hin, dass HugePage-Speicher verwendet wurde.

Beim Überprüfen von /proc/meminfo auf dem ausgefallenen Datenbankserver wurde jedoch festgestellt, dass keine HugePage-bezogenen Informationen vorhanden waren. Sysctl -a überprüfte alle Systemparameter und fand den Parameter vm.nr_hugepages nicht. Dies liegt daran, dass die HugePage-Funktion nicht in den Linux-Kernel kompiliert ist. Wir müssen einen anderen Kernel verwenden, um HugePage zu aktivieren.

Überprüfen Sie /boot/grub/grub.conf:

# grub.confgeneriert von Anaconda

# Beachten Sie, dass Sie grub nicht erneut ausführen müssen, nachdem Sie Änderungen an dieser Datei vorgenommen haben

#HINWEIS: Sie haben eine /boot-Partition. Das bedeutet, dass

# alle Kernel- und Initrd-Pfade sind relativ zu /boot/, zB.

# Wurzel(hd0,0)

# kernel/vmlinuz-version ro root=/dev/VolGroup00/LogVol00

# initrd/initrd-version.img

#boot=/dev/cciss/c0d0

Standardwert = 0

Zeitüberschreitung = 5

splashimage=(hd0,0)/grub/splash.xpm.gz

verstecktes Menü

Titel Red Hat Enterprise Linux Server (2.6.18-8.el5xen) mit RDAC

Wurzel (hd0,0)

kernel/xen.gz-2.6.18-8.el5

Modul /vmlinuz-2.6.18-8.el5xen roroot=/dev/VolGroup00/LogVol00 rhgb ruhig

module/mpp-2.6.18-8.el5xen.img

Titel Red Hat Enterprise Linux Server (2.6.18-8.el5xen)

Wurzel (hd0,0)

kernel/xen.gz-2.6.18-8.el5

Modul /vmlinuz-2.6.18-8.el5xen roroot=/dev/VolGroup00/LogVol00 rhgb ruhig

module/initrd-2.6.18-8.el5xen.img

Titel Red HatEnterprise Linux Server-Basis (2.6.18-8.el5)

Wurzel (hd0,0)

Kernel /vmlinuz-2.6.18-8.el5 roroot=/dev/VolGroup00/LogVol00 rhgb ruhig

module/initrd-2.6.18-8.el5.img

Wir haben festgestellt, dass der von diesem System verwendete Kernel das Wort „xen“ enthält. Wir haben diese Datei geändert, default=0 in default=2 geändert oder die ersten beiden Kernel mit einem #-Zeichen blockiert und dann den Datenbankserver neu gestartet. Wir haben festgestellt, dass der neue Kernel bereits HugePage unterstützt.

Nachdem die Datenbank große Speicherseiten aktiviert hatte, traten die in diesem Artikel beschriebenen Leistungsprobleme auch bei einer Vergrößerung des SGA nicht mehr auf. Bei Betrachtung der /proc/meminfo-Daten ist der von PageTables belegte Speicher unter 120 MB geblieben, eine Verringerung um 4500 MB gegenüber dem Original. Es wurde beobachtet, dass die CPU-Auslastung im Vergleich zur Zeit vor der Verwendung von HugePages ebenfalls gesunken ist und der Systembetrieb auch ziemlich stabil ist. Zumindest treten durch die Verwendung von HugePages keine Fehler auf.

Tests zeigen, dass bei OLTP-Systemen die Aktivierung von HugePage unter Linux mit einer Oracle-Datenbank die Datenbankverarbeitungsleistung und die Reaktionszeit in unterschiedlichem Maße verbessern kann, wobei die höchste Verbesserung bei über 10 % liegt.

IV. Zusammenfassung

Dieser Artikel stellt anhand einer Fallstudie die Rolle großer Speicherseiten bei der Leistungssteigerung im Linux-Betriebssystem vor und zeigt, wie die entsprechenden Parameter zum Aktivieren großer Speicherseiten festgelegt werden. Am Ende dieses Artikels empfiehlt der Autor, beim Ausführen der Oracle-Datenbank im Linux-Betriebssystem große Speicherseiten zu aktivieren, um die in diesem Fall auftretenden Leistungsprobleme zu vermeiden oder die Systemleistung weiter zu verbessern. Man kann sagen, dass HugePage eine der wenigen Funktionen ist, die die Leistung ohne zusätzliche Kosten verbessern können. Erwähnenswert ist auch, dass die neue Version des Linux-Kernels Transparent Huge Pages bereitstellt, sodass unter Linux laufende Anwendungen große Speicherseiten umfassender und bequemer nutzen können und nicht nur den gemeinsam genutzten Speicher. Warten wir ab, welche Änderungen diese Funktion mit sich bringt.

Quelle: "Oracle DBA Notes 3" Linux Large Memory Page Oracle-Datenbankoptimierung Autor: Xiong Jun

Bildquelle: http://2.bp.blogspot.com/-o1ihxahkl0o/VQFhFj2lHwI/AAAAAAAAAV4/egUhLwaYtmc/s1600/oracle_linux.png

Zusammenfassen

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Lernwert für Ihr Studium oder Ihre Arbeit hat. Wenn Sie Fragen haben, können Sie eine Nachricht hinterlassen. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM.