Artikel
Aktives GUI-Element
Statisches GUI-Element
Quelltext
WPS-Objekt
Datei/Pfad
Befehlszeile
Inhalt Eingabefeld
[Tastenkombination]
Mit Theseus die Speichernutzung in OS/2 untersuchen
Teil 2
Die meisten OS/2-Benutzer haben wohl bereits unter Speicherproblemen gelitten, auch wenn Sie sich dessen gar nicht bewußt waren. Wenn man die dabei involvierten Mechanismen ein wenig kennt, kann das reichhaltige Hilfsprogramm Theseus von IBM dabei helfen, die möglichen Übeltäter und Lösungen zu finden.
Speicherleckdiagnose
Die Funktion der Speicherleckdiagnose (Memory Leak Detection) finden Sie an zwei Stellen: Einmal unter System für die globale Diagnose von Speicherlecks und zum anderen unter Process für die detaillierte Speicherleckdiagnose eines einzelnen Prozesses.
Speicherlecks
Was ist ein Speicherleck? Hatte Firefox ein Speicherleck, als er 357 MB virtuellen Speicher allozierte und sich sogar 277 MB im RAM befanden? Oder diente die Speichernutzung einem bestimmten Zweck, wie schon beim absichtlichen Anwachsen der WPS? Wie immer, so kann man es auch hier als Fehler oder als Feature auffassen – abhängig von der Einstellung und Erwartung eines Entwicklers, dessen Vorgesetztem oder eines Endanwenders.
Wenn eine Anwendung oder ein Systemmodul neuen Speicher alloziert, sollte dieser zur Ablage von Code oder Daten verwendet werden. Üblicherweise wurden diese Bereiche von den Entwicklern auch wieder freigegeben, wenn sie nicht länger benötigt wurden.
Entwickler, die mit geringen verfügbaren Ressourcen arbeiteten, mußten nicht mehr benötigte Speicherressourcen freigeben, um Platz für anderen Code oder Daten zu schaffen. Mit dem Einzug des geschützten Modus und der nahezu unbegrenzten Verfügbarkeit an virtuellem Speicher war diese Begrenzung hinfällig. Wurde der Speicher nach Verwendung nicht freigegeben, so funktionierten die meisten Programme immer noch problemlos.
Einige Entwickler fanden nun sogar Argumente gegen das Freigeben des Speichers: Das Freigeben verlangsame die Programme und könne – wenn es falsch implementiert worden sei – sogar zum Absturz des Programms führen. Die Verlangsamung oder der Absturz wäre vom Endanwender bemerkt worden, die «Verschwendung» des privaten Speichers «im Hintergrund» allerdings nicht. Die nicht mehr verwendeten Speichersegmente würden ohnehin auf Platte ausgelagert oder könnten bei Systemen mit viel Speicher sogar im selbigen behalten werden. Der geschützte Modus motivierte Entwickler somit dazu, sich eher mit der Implementierung neuer Funktionen zu beschäftigen als mit der Analyse langweiliger Dinge im Systemhintergrund.
Die Konsequenzen aus Speicherlecks
Neue Funktionen sind immer willkommen, aber aufgrund der begrenzten Kapazität der gemeinsamen Speicherregion unter OS/2 sind Stabilitätsprobleme vorprogrammiert, wenn der Speicherbedarf in gleichen Maß wächst wie Gras in einem regenreichen Sommer.
Die offensichtliche Konsequenz aus Speicherlecks ist, daß der Speicherbedarf kontinuierlich anwächst. Sobald nur noch wenig freier physischer Speicher vorhanden ist, wird OS/2 weniger reaktionsschnell, und die SWAPPER.DAT wächst.
Aber selbst wenn ein Programm dies gerade getan hat, handelt es sich nicht um ein gravierendes Problem. Die Speicherverwaltung von OS/2 ist darauf ausgelegt, auch solche Streßsituationen handhaben zu können. Das wachsende Programm kann unter System > RAM Usage by process beobachtet werden: Wenn es geschlossen oder periodisch neu gestartet wird, läuft auch OS/2 wieder ohne Probleme.
Leider gibt es aber auch eine viel gefährlichere Variante des Speicherlecks. Dieser Typ arbeitet im Untergrund, da er Speicher anfordert, ohne ihn zu verwenden. Da OS/2 virtuellen Speicher nur verzögert zusichert, kann ein Programm durchaus einen geringen Arbeitsbedarf und nur wenig zugesicherten Speicher besitzen (wie unter RAM Usage by Process erkennbar), allerdings immer noch soviel Addressraum allozieren, um damit plötzlich den virtuellen Speicherbedarf des Presentation Managers oder der WPS zu erschöpfen.
Auf Systemen mit viel Speicher ist es daher sehr wichtig, den allozierten Speicher zu prüfen, besonders wenn der virtuelle Adreßraum zur Neige geht. Die exzessive Nutzung des unteren gemeinsamen Speicherbereichs kann mittels Process > Memory Utilization ermittelt werden. Sie kann verursacht werden durch einen großen Prozeß wie Mozilla, aber durchaus auch durch einen relativ kleinen. Wenn man nur noch 10 MB freien verfügbaren virtuellen Speicher hat, kann das kleinste Tröpfchen schon das Faß zum Überlaufen bringen.
Da OS/2-Programme den Speicher mit anderen Programmen mit durchaus unterschiedlichen APIs teilen, können die Auswirkungen eines Speicherlecks auch dann auftreten, wenn das leckende Programm bereits geschlossen wurde – speziell, wenn das Programm mittels eines «inoffiziellen» Verfahrens geschlossen wurde (z.B. durch «killen» des Programms anstelle dessen regulärer Beendigung) oder auf «unsaubere» Art wie durch Verwendung des OS/2 API in Form eines Windows-Programms unter ODIN.
Im unten abgebildeten Beispiel ist ein beschreibbarer (writeable, «W») Speicher an der
linearen Adresse hex 156F0000 erkennbar, der den sehr zutreffenden Text Virtual Memory Problems Under OS/2.
enthält. Theseus warnt hier, daß dieser gemeinsame Speicher keinen Eintrag in der Modultabelle (Module Table
Entry , «MTE») enthält, was bedeutet, daß dieser Bereich nicht mehr der originären
DLL (hier PMMERGE.DLL an Adresse 1574
0000) oder einem Programm zugeordnet ist.
Abb. 7: Beispieldarstellung von beschreibbarem Speicher mit Text aus der Zwischenablage
Der Text wurde in die PM-Zwischenablage eingestellt durch Innoteks Port von OpenOffice 1.1.4., welches im Anschluß ganz normal beendet wurde. Der Text wurde allerdings noch immer mit Odin assoziiert, wie sich durch das Handle des MTE (hmte 1479) erkennen läßt, das auf Virtual PC verweist. Nachdem VPC ebenfalls geschlossen wurde, verschwand auch das Speicherleck.
Die Erkennung und Vorbeugung von Speicherlecks ist nicht trivial. Wenn Sie mehr darüber erfahren möchten, suchen Sie mit Google nach MEMLKS.ZIP.
Funktionen zur Erkennung von Speicherlecks in Theseus
Für eine Übersicht der Nutzung des virtuellen Speichers für das gesamte System verwenden Sie Theseus > System > Memory Leak Detection. Wählen Sie zunächst Functions > Leak Detection Control > Use previous sample as base (verwende vorheriges Ergebnis als Basis). Wählen Sie dann Functions > Start Periodic Leak Detection (starte periodische Speicherleckerkennung).
Memory leak detection: Use the 'Function' pull-down to start and stop the data collection. Leak data captured. Previous sample will be used as the base. Periodic update started with interval of 0:30.
Theseus mißt die Menge an 4 KB-Speicherseiten, die alloziert (versprochen), zugesichert (benutzt) und tatsächlich im RAM sind. Ich habe mich auf Mozilla Firefox konzentriert. Ich startete den Browser mit der Google-Seite, öffnete gleichzeitig 17 URLs in neuen Tabs, schloß diese wieder und kehrte auf die Google-Startseite zurück.
-
Start von Firefox mit Google: Mehr Speicher wird alloziert als zugesichert (d.h. als benutzt).
----------Private----------- -----------Shared-----------
Allocated Committed Actual Allocated Committed Actual PID Name
+12640 +4685 +3333 +6962 +5655 007E +MOZILLA -
Schnelles Öffnen von 17 Verknüpfungen in neuen Tabs: Mehr virtueller Speicher wird alloziert, aber noch viel mehr wird im zweiten Intervall zugesichert. Das ist der "verzögert zugesicherte" Speicher aus den ersten 30 Sekunden.
----------Private----------- -----------Shared----------- Allocated Committed Actual Allocated Committed Actual PID Name +10096 +11082 +10424 +363 +469 007E MOZILLA ----------Private----------- -----------Shared----------- Allocated Committed Actual Allocated Committed Actual PID Name +576 +553 +533 +400 +78 007E MOZILLA -
Alle Tabs bis auf Google schließen: Viele Seiten weniger (-320) werden freigegeben als in den vorherigen beiden Intervallen alloziert wurden (ca. 11.000). Der gemeinsam genutzte Speicher wächst weiter.
----------Private----------- -----------Shared----------- Allocated Committed Actual Allocated Committed Actual PID Name -320 -180 -149 +200 +1 007E MOZILLA
Was hier beobachtet werden kann, ist das allgemein bekannte Verhalten Mozillas, immer mehr und mehr Speicher zu allozieren, selbst wenn man Tabs schließt. Fehler oder Feature? Ich betrachte das eher als Speicherleck, da ich im Gegenzug nicht ein Mehr an Funktionalität erhalte.
Wenn man Firefox schließt, neu startet, es in Theseus auswählt und das Experiment wiederholt, kann man mittels Process > Memory Leak Detection die involvierten DLLs ermitteln. Die Liste ist lang. Ich kann hier nur einen Teil abbilden:
Allocated Committed Actual har Address P/S Description
+0 +0 +1 1418 00B10000 Pvt DOSCALL1 allocated it
+0 +0 +1 141E 00BF0000 Pvt TCPIP32 allocated it
+0 +4512 +4536 1422 00C30000 Pvt LIBC05 allocated it
+256 +256 +5 148C +03160000 Pvt NPSWF2 allocated it
+16 +1 +1 14DA +03270000 Pvt FLASHWIN allocated it
Und in der gemeinsamen Speicherregion:
+16 +16 +16 154D +16160000 Shr PMMERGE allocated it
+128 +121 +0 1550 +16170000 Shr PMMERGE allocated it
+16 +0 +0 152C +16AF0000 Shr HELV #0009 (shared data)
Das inoffizielle FLASHWIN und PMMERGE sind oft involviert. Das aus Windows abgeleitete FLASHWIN-Plug-In kann (zum Teil) in den hohen Speicher geladen werden, aber PMMERGE.DLL alloziert immer unteren Speicher. Wenn Sie also OS/2 stabil halten möchten, sollten Sie jegliche Vertreter der Mozilla-Familie in regelmäßigen Abständen schließen.
Lineare Speichernutzung der Prozesse
Um zu ermitteln, wieviel virtueller Adressraum in der gemeinsamen Speicherregion verfügbar ist, wählen Sie einen beliebigen Prozeß aus und verwenden dann Theseus > Process > Shared Object Summary. Blättern Sie dann ans Ende (Ende-Taste) und richten Sie Ihr Augenmerk auf die Analyse der 'freien' Bereiche wie bereits früher beschrieben.
Wenn Sie allerdings wissen möchten, wieviel nutzbarer gemeinsamer Speicher übrig ist, verwenden Sie Theseus > System > Linear Usage by Process. Hier finden Sie ein Blockdiagramm, welches die Verwendung der linearen Adreßraums in den gemeinsamen und privaten Speicherregionen beschreibt.
Die privaten, gemeinsamen und System-Regionen
In Ihrer einfachsten Form – mit einem virtuellen Adreßlimit von 512 MB – sieht die Regionenabbildung wie folgt aus. Abbildung und Beschreibungen stammen aus der Theseus-Hilfedatei.
Abb. 8: Speicherregionen bei virtuellem Adreßlimit von 512 MB
Die lineare Nutzung der Prozesse zeigt nicht die Systemregionen. Hier wird nur der Speicher im geschützten Modus dargestellt, also virtueller Speicher, der durch den Kernel überwacht wird. Der Kernel selbst läuft in einem privilegierten Modus, hat Zugriff auf Terabytes an virtuellem Speicher und kann nicht prä-emptiv unterbrochen werden. Nichtsdestotrotz haben Prozesse im geschützten Modus eine Systemregion, und jeglicher Versuch, die enstprechenden Adressen zu beschreiben, wird vom Kernel abgestraft.
Mit bis zu 3 GB (maximales virtuelles Adreßlimit) virtuellen Adreßraums pro Benutzerprozeß werden die Pufferzeilen des Theseus-Fensters ziemlich schnell gefüllt. Wenn Theseus nicht in der Lage ist, den vollständigen hohen Speicherbereich (HMA) anzuzeigen, verwenden Sie Process > Private oder Shared Object Summary, um den hohen Speicherbereich eines einzelnen Prozesses zu sehen.
Die private Region
Das erste, was Sie sehen werden, ist die (private) lineare Speicherbelegungsabbildung des laufenden Prozesses. Die Prozeßnamen werden dabei aufsteigend sortiert und unter Address usage... können Sie ermitteln, wieviel und welchen privaten virtuellen Speicher die Prozesse belegen.
Die Virtual DOS Machine (VDM) beginnt bei der hexadezimalen Adresse 0000 0000. OS/2-Programme im geschützten Modus beginnen bei 00001000. Hier befindet sich ihr erstes (#0) virtuelles Speicherobjekt. Wenn es sich um ein großes Objekt handelt, wird die Nummer mehrfach angezeigt. Aufeinanderfolgende Speicherobjekte werden durch entsprechende Nummern dargestellt. Jede Zeile steht für einen 64 KB Block. Eine Erläuterung erhalten Sie unter Help > Explanation of this Window.
Hin und wieder werden Sie Punkte sehen, die für unbenutzten virtuellen Adreßraum zwischen den allozierten Speicherobjekten stehen. Dies ist ein Indikator für externe Speicherfragmentierung in den virtuellen Adreßräumen der Prozesse.
Es gibt allerdings auch eine Art interne Speicherfragmentierung, die daraus resultiert, daß Speicherobjekte in 4-KB-Blöcken alloziert werden. Daraus ergibt sich ein durchschnittlicher Schwund von 2 KB pro Speicherobjekt. Das kann man mit dem unsichtbaren «Verschnitt» von Dateisystemen vergleichen.
Der größte Prozeß der privaten Region bestimmt die Größe der gemeinsamen Region.
Hätte ich beispielsweise 30 Benutzerprogramme, von denen jedes nur 100 MB an privatem und ein Minimum an gemeinsamen Speicher belegte, könnte das die Größe der virtuellen Maschine auf mehr als 3 GB treiben. Dieses System könnte aber sogar mit OS/2 Warp 3 und 1 GB RAM laufen. Durch das verzögerte Auslagern von OS/2 könnte es mit der maximalen Größe der SWAPPER.DAT von 2 GB (HPFS-Limit) arbeiten. Die 30 Programme im geschützten Modus würden sich gegenseitig nur behindern, wenn sie einen großen Arbeitsbedarf hätten, der nicht in 1 GB RAM paßt.
Ein einziger Prozeß jedoch, der 300 MB privaten Speicher belegt, könnte die gemeinsame Region auf 200 MB quetschen und damit verhindern, daß andere Prozesse geladen werden können, die gemeinsamen Speicher benötigen.
Verwenden Sie also SET JAVA_HIGH_MEMORY=1 in Ihrer CONFIG.SYS, wenn Sie
Java benutzen, damit der Großteil des Java-Speichers in den hohen Speicherbereich geladen werden kann.
Die gemeinsame Region
Abb. 9: Vergleich der Speicherregionen für alte bzw. neue Kernel mit Unterstützung des hohen Speichers
Die untere Grenze der gemeinsamen Region wird bestimmt durch den größten Prozeß der privaten Region. Bei frisch gestarteten Systemen gibt es noch einen freien Speicherbereich zwischen der privaten und der gemeinsamen Region.
Dieser wird allerdings verschwinden, sobald Sie mehrere DLLs laden und entladen, was zu einer fragmentierten gemeinsamen Region führt. Die obere Grenze der niedrigen gemeinsamen Region ist 1FFF FFFF (512 MB).
Das periodische Beenden und Neustarten der speicherhungrigsten Prozesse könnte für Abhilfe sorgen, sobald der virtuelle Speicher knapp wird. Das Neustarten von Programmen in speicherrestriktiven Umgebungen könnte die Programme dazu zwingen, DLLs verstärkt in die hohen Speicherbereiche zu laden.
Selbiges trifft auf jede Art von Programm (EXE, DLL) zu, das viel gemeinsamen Speicher alloziert. Hier sind die Effekte kumulativ: Je mehr Sie davon schließen, desto mehr Adreßraum wird in den gemeinsamen Regionen freigegeben.
Die hohe Speicherregion
Bei den Kerneln von Warp Server for eBusiness und modernen eCS- und OS/2-Systemen beginnt die hohe Speicherregion an der linearen Adresse hex 2000 0000 mit der hohen privaten Speicherregion. Weiter werden Sie dann einen Bereich freier Speicheradressen finden. Oberhalb davon wiederum befindet sich die hohe gemeinsame Region, die dort endet, wo sich das virtuelle Adreßlimit befindet, das in der CONFIG.SYS angegeben wird (standardmäßig bei 1024 MB, im Diagramm bei 2048 MB).
Die Bedeutung des Bereichs mit freiem Speicher
Die Grenzen zwischen den freien, privaten und gemeinsamen Speicherregionen sind nicht fest. Sie ändern sich vielmehr kontinuierlich, besonders in der oft verwendeten niedrigen Speicherregion. Wenn ein Prozeß Speicher freigibt, treten Löcher im virtuellen Adressraum auf, die wiederum mit anderen virtuellen Speicherobjekten gefüllt werden können, wenn diese größenmäßig passen. Wenn allerdings IBMs OS/2-Speicheranalyseprogramm Theseus folgendes meldet...
There is 0.000M between the private and shared arenas. Shared arena starts at 0B670000, which is 182.438M. Free memory from 0B670000 for 128.000M, which is equivalent to 2048 64K spaces.
Abb. 10: Fehler beim Laden von OpenOffice aufgrund von Speicherfragmentierung
haben Sie wahrscheinlich ein Problem; selbst wenn es noch 128 MB freien virtuellen Adreßraum gibt für neue
oder die konstant wachsenden Programme (WPS, Mozilla). Hier besteht die Gefahr, daß der OS/2-Systemlader keinen
entsprechenden freien virtuellen Adressraum für die DLLs neuer oder wachsender Programme (hier OOWIN.DLL) mehr finden kann. Die freien Speicherobjekte sind unter Umständen alle zu klein (wie
das 640K Objekt an 0B670000) um das Laden einer DLL zu erlauben. Und dann werden Sie die Fehlermeldung nicht
genügend freier Speicher
erhalten, auch wenn Sie noch 1 GB freien RAM haben. Bedenken Sie, daß es nur
ihr virtueller Speicher ist, den Programme im geschützten Modus adressieren können.
Um die kritischen Bereiche in der linearen Speicherzuordnungstabelle zu finden, verwenden Sie Theseus'
Suchfunktion: Mark > Find ([Strg-F]) und suchen Sie nach arena
.
Verwenden Sie [Strg-A], um nach weiteren Stellen zu suchen, an denen das Suchwort arena
noch
enthalten ist.
Wenn die Dynamic Link Libraries (DLLs) in der gemeinsamen Region effizient gemeinsam genutzt werden, können Programme sehr gut dokumentierten und nach Jahren der OS/2-Entwicklung fast schon kugelsicheren Code (wieder)verwenden mit minimalen Systemressourcen. Diese DLLs wurden für die gemeinsame Nutzung entworfen. Das Laden einer zweiten Instanz von CMD.EXE verbraucht weniger Speicher als die erste Instanz.
Und selbst wenn Speichermangel heutzutage kein Problem mehr ist, wird Ihr schneller Level1-Cache und Prozessor von schlankem Code profitieren, da der Level1 (oder -2) Cache der primäre (verfügbare) Speicher heutiger schneller Prozessoren ist. Ein Programm, dessen Arbeitsbedarf in den Cache-Speicher des Prozessors paßt, wäre unglaublich schnell.
Andererseits: Wenn ein Programm oder ein PM-Treiber beispielsweise 100 MB Speicher für unnötigen oder schlecht dokumentierten «aufgeblähten» Code allozieren und mit anderen OS/2-Programmen teilen würde, hätten alle übrigen OS/2-Programme 100 MB weniger adressierbaren virtuellen Speicher zur Verfügung. Denn die Daten und der Code in der gemeinsamen Region sind Bestandteil des virtuellen Adreßraums eines jeden Programms. Somit wäre das Allozieren von 300 MB niedrigen, privaten Speichers fast schon ein Straftatbestand, da hierdurch die gemeinsame Region auf weniger als 200 MB schrumpft.
Wenn Sie in der PM-Version eine automatische, periodische Aktualisierung einschalten, werden Sie sehen, daß die Nutzung virtuellen Speichers von Prozessen wie der zweiten pmshell.exe (die Workplace Shell) und mozilla.exe zunehmen, je mehr und länger Sie diese jeweils benutzen. An einem bestimmten Punkt jedoch werden Probleme in der gemeinsamen Region auftreten, selbst wenn Sie noch 1 GB freien Speichers haben. Und dann treten diese Fehlermeldungen zu unzureichendem freien Speicher auf.
In diesen Situationen wird selbst Theseus nicht mehr starten (DLLs können nicht gefunden werden), allerdings sind im Lieferumfang von Theseus auch einige CLI (Befehlszeilen- bzw. Textmodus-) Hilfsprogramme enthalten, die selbst in speicherproblematischen Situationen noch funktionieren. Wenn Sie also feststecken und wissen wollen, ob dies in einem Zusammenhang mit der Nutzung des virtuellen Speichers steht, drücken Sie [Strg-Alt-Entf] (wenn Sie den CAD-Handler verwenden) und rufen Sie dann eine Befehlszeile auf. Dort starten Sie eine Stapelverarbeitungsdatei, die ungefähr wie folgt aussieht:
rem Theseus_snapshot.cmd cd \. cd<>Theseus getram.exe 1 0 file %TEMP%\theseus.txt type c:\config.sys >> %TEMP%\theseus.txt call getlinmp.cmd >> %TEMP%\theseus.txt start fte %TEMP%\theseus.txt exit
Der Vorteil von FTE (PM) im Gegensatz zu (A)E.EXE ist, daß die Zeilennummern angezeigt werden, was bei der Identifizierung der Prozesse in der CLI-Version von " Get Linear Memory by Process" (lineare Speichernutzung der Prozesse) hilfreich ist.
Freier, inaktiver und gesperrter Speicher
Physischer Speicher wird unterteilt in Seitenblöcke zu je 4 KB. Wenn virtueller Speicher zugesichert wird, wird seine lineare Adresse mit der physischen Adresse der Speicherseite verknüpft. Im Falle gemeinsamen Speichers verweisen die Seitentabellen-Adressen unterschiedlicher Prozesse auf dieselbe physische Adresse.
Sobald der virtuelle Speicher freigegeben wurde, werden die dazugehörigen Speicherseiten als frei markiert. Der eigentliche Speicherinhalt wird nicht gelöscht, so daß hier noch immer der Inhalt des vorherigen Nutzers vorliegt. Freie Seiten können wieder mit Speicherobjekten verknüpft werden – in diesem Fall wird der Speicher alloziert aber noch nicht zugesichert.
Speicherseiten, die nicht kürzlich verwendet wurden, bezeichnet man als inaktiv («idle»). Sobald es nur noch einen kleinen Bereich freien Speichers gibt, werden diese am wenigsten benutzten (Least Recently Used, «LRU») Seiten abgetrennt und an andere virtuelle Seiten abgegeben. Wenn allerdings die Inhalte der inaktiven Seiten im Vergleich zu deren initialem Zustand verändert wurden («dirty idle»), muß der Auslagerungsdienst diese zuerst auf Platte sichern.
Der Großteil an physischem Speicher kann auf Festplatte ausgelagert werden («swappable memory», auslagerungsfähiger Speicher). Allerdings funktionieren Gerätetreiber und VPC nicht korrekt, wenn deren Puffer auf Platte ausgelagert werden. Diese Prozesse sperren daher ihren Speicher kurz- oder langfristig («locked memory», gesperrter Speicher). Und natürlich besitzt auch das Betriebssystem Komponenten, die grundsätzlich im RAM vorliegen müssen («resident memory», residenter Speicher).
Swapper
System > Swapper zeigt Theseus' Analyse der Auslagerungsdatei SWAPPER.DAT an. Obwohl das 32-bit OS/2 Seiten zu je 4 KB auslagert anstelle von 64 KB-Segmenten, wurde der OS/2 16 Bit-Dateiname SWAPPER.DAT beibehalten.
Analysis of the SWAPPER.DAT file: There are 32000 disk frames in SWAPPER.DAT (each is 4K bytes). There are 535 frames used. (2140K => 2.090M) There are 31465 frames free. (125860K => 122.910M) There are 32000 frames total. (128000K => 125.000M) There are 220 frames compressed. (880K => 0.859M) (Compressed frames are not in SWAPPER.DAT.)
Die MEMMAN-Einstellung war hierbei SWAP, PROTECT. Die SWAPPER.DAT war 125 MB groß. Komprimierte Speicherseiten werden im Kernel gehalten.
Allgemeine Systemdaten («General System»)
Unter System > General System finden Sie nützlichere Informationen.
-
General System Information zeigt die aktuellen Kernel-Parameter an, von denen einige mittels CONFIG.SYS eingestellt werden.
-
Device Drivers zeigt die via CONFIG.SYS geladenen Treiber und damit assoziierten Gerätenamen an.
-
GDT zeigt Informationen zur globalen Deskriptorentabelle («Global Descriptor Table») an.
-
Modules listet die geladenen Programme (EXE and DLL) sowie Treiber (SYS, DLL) auf.
-
Das System Anchor Segment (SAS) ist der gemeinsame Anker für viele Systemkontrollblöcke und Kontrollblock-Ketten gemäß des
OS/2 Debugging
-Handbuchs. -
Global Info Seg beinhaltet alle Arten von Informationen zu Zeit und Zeitsteuerung.
-
Open Files zeigt die offenen Dateien der Systemdateitabelle an. Das kann nützlich sein, wenn Sie ermitteln wollen, welche DLL verwendet wurde.
-
Process List zeigt die aktiven Prozesse an, die zugehörigen Speicherressourcen (Per Task Data Area, PTDA), die Anzahl der Threads sowie Prozess-ID und -Name.
Abb. 10: Theseus Anzeige der allgemeinen Systeminformationen und Memsize-Anzeige
Theseus > General System > General System Information ist mein Favorit. Besonders die Ausgabe von DosQuerySysInfo ist interessant. Man kann sie aktualisieren mittels Misc > Contents update. Es sagt Ihnen einiges über die Einschränkungen des OS/2-Kernels in Ihrem aktuellen System – und das ist es, was OS/2-Poweruser interessiert.
Following are the values from DosQuerySysInfo: 1. QSV_MAX_PATH_LENGTH = 260 23. QSV_MAX_COMP_LENGTH = 255.
Ein vollständiger Pfad kann bis zu 260 Bytes lang sein (1) und die einzelnen Bestandteile davon bis zu 255 Bytes (23).
2. QSV_MAX_TEXT_SESSIONS = 16. 3. QSV_MAX_PM_SESSIONS = 16. 4. QSV_MAX_VDM_SESSIONS = 256.
OS/2 unterstützt 16 Vollbildschirm-Textanwendungen, 16 grafische Presentation Manager Sitzungen (PM/WPS, XFree86-Server, Battle of Wesnoth) und 256 virtuelle DOS-Maschinen. Sitzungen im hier definierten Sinn haben unabhängigen Zugriff auf Maus, Tastatur und den Bildschirm im Gegensatz zu PM-Fensteranwendungen, welche beispielsweise die Maus in einer einzelnen PM Sitzung untereinander teilen.
11. QSV_VERSION_MAJOR = 20. 12. QSV_VERSION_MINOR = 45. 13. QSV_VERSION_REVISION = 0.
Ich verwende also eine Variante des 32-Bit OS/2 2.0 namens OS/2 4.5 (eCS 1.2).
17. QSV_TOTPHYSMEM = 2146762752 (2096448K -> 2047.313M). 18. QSV_TOTRESMEM = 1056301056 (1031544K -> 1007.367M). 19. QSV_TOTAVAILMEM = 745558016 (728084K -> 711.020M).
Die absolute Größe des physischen Speichers (Eintrag 17) ist 2047,313 MB (2 GB DRAM). Der Anteil an nicht auslagerungsfähigem residenten Systemspeicher (Eintrag 18) beläuft sich auf 1007,367 MB. Das meiste davon ist JFS-Cachespeicher.
Die Menge an virtuellem Speicher, der von allen Prozessen im geschützten Modus alloziert werden kann (Eintrag 19), ist 711,020 MB. Da die SWAPPER.DAT allerdings bis auf 2 GB anwachsen kann (virtuelle Speicherressourcen), erhöht sich dieser Wert bei Bedarf.
Die folgenden Werte sind schon eher von Wichtigkeit. Sie haben mit dem beschränkten virtuellen Adreßraum in der niedrigen Speicherregion zu tun.
20. QSV_MAXPRMEM = 264044544 (257856K -> 251.813M). 21. QSV_MAXSHMEM = 129695744 (126656K -> 123.688M).
Die maximale Menge an Speicher, die ein Prozeß in der niedrigen, privaten Region (20) allozieren kann,
beträgt 251,813 MB. Theseus sagt: Dieser Wert ist ein Ratschlag und nicht garantiert, da die
Systembedingungen permanenter Veränderung unterliegen.
Dasselbe trifft zu auf die Menge an Speicher, die
ein Prozeß in der unteren, gemeinsamen Speicherregion allozieren kann (21). Die gemeinsame Region ist lediglich
123,688 MB groß, da PM, die WPS, das Netzwerk und andere geladene Anwendungen bereits (512 - 251,831 -
123,688) = 136,481 MB davon in Beschlag nehmen.
Der freie virtuelle Adreßraum in der niedrigen, gemeinsamen Region wird fragmentiert sein. Daher kann es sein, daß Sie bereits «kein freier Speicher» mehr haben werden, wenn große, gemeinsam genutzte DLLs dorthin laden wollen.
27. QSV_MAXHPRMEM = 469762048 (458752K -> 448.000M). 28. QSV_MAXHSHMEM = 325189632 (317568K -> 310.125M).
QSV_MAXHPRMEM ist die maximale Menge an Speicher, die ein Prozeß in der hohen, privaten Region allozieren kann. Und QSV_MAXHSHMEM ist die maximale Menge an Speicher, die ein Prozeß in der hohen, gemeinsamen Region allokieren kann. Auch hier handelt es sich um vorgeschlagene und nicht garantierte Werte, da sich die Systembedingungen permanent ändern. Diese hohe Speicherregion (high memory area, «HMA») kann allerdings zusätzlichen virtuellen Speicher für Programme zur Verfügung stellen, die dafür entsprechend kompiliert wurden.
29. QSV_MAXPROCESSES = 256. 30. QSV_VIRTUALADDRESSLIMIT = 40000000 QSV_MAXPROCESSES) will use kernel defaults when not explicitly set (PROCESSES=).
QSV_MAXPROCESSES ist die Anzahl an Prozessen, die konkurrierend auf einem SMP-System laufen können. Die Vorgabe war 810 auf meinem nicht-SMP
System mit 2 GB, aber da ich nie mehr als ein paar hundert Prozesse verwendete, habe ich die Kernel-Obergrenze
für Benutzerprozesse auf 256 verringert mittels CONFIG.SYS-Eintrag
PROCESSES=256. Und ich glaube, das hat mein System stabiler gemacht, da es weniger Systemressourcen
benötigt. Gleiches gilt für das Reduzieren der maximalen Anzahl möglicher (in Praxis aber nie
erreichter) THREADS=520 oder VIRTULALADRESLIMIT=1024.
Der Wert QSV_VIRTUALADDRESSLIMIT=40000000 ist in hexadezimaler Notation angegeben. Das dezimale VIRTUALADDRESSLIMIT in meiner CONFIG.SYS war 1024 MB.
Schlußfolgerungen
Durch das Allozieren von immer mehr und mehr virtuellem Speicher durch speicherhungrige Programme wie jene der
Mozilla-Familie schrumpft der Bereich an freiem Speicher zwischen den privaten und gemeinsamen Regionen. An einem
bestimmten Punkt wird Ihnen Theseus > System > Linear Usage by Process
mitteilen:
Es gibt 0.000 MB freien Speicher zwischen den gemeinsamen und privaten Regionen (There is 0.000M between the
private and shared arenas).
There is 0.000M between the private and shared arenas. Shared arena starts at 08C90000, which is 140.563M. Free memory from 08C90000 for 229.063M, which is equivalent to 3665 64K spaces.
Und hier beginnen die Probleme des virtuellen Speichers. In der gemeinsamen Region von 08C9 0000 bis 1FFF FFFF mag noch genügend freier Speicher sein, und sogar noch mehr frei machbarer Speicher, wenn man einige Programme beendet. Der freigemachte Speicher kann in der gemeinsamen Region allerdings nur relativ kleine Speicherobjekte aufnehmen. Der OS/2-Lader kann nur kleine DLLs in den freigemachten Speicher stellen – eine große DLL, die mehr Code und Daten beinhaltet (wie beispielsweise einen Puffer- oder Zwischenspeicherbereich) und dafür 30 MB virtuellen Speicher «am Stück» benötigt, allerdings nicht.
Dank Theseus fand ich heraus, daß die Fragmentierung von Speicherobjekten in der gemeinsamen Region unausweichlich auftritt, wenn der OS/2-Lader gemeinsam genutzte DLLs lädt und wieder entlädt. Fragmentierung im virtuellen Speicher destabilisiert alle OS/2-Programme des geschützten Modus, die neue Speicherobjekte allozieren, die nicht in den fragmentierten freien Speicher passen.
Unter den Programmen des geschützten Modus, die darunter litten, waren die Befehlsumgebung des geschützten Modus («protshell») – der Presentation Manager – und die Workplace Shell. Somit leiden also in erster Linie die Aushängeschilder von OS/2 (nicht der Kernel) unter Instabilität bei Mangel an virtuellem Speicher. In diesem Fall können Sie nur noch auf residente Notfall-Befehlsumgebungen wie Watchcat und den CAD-Handler vertrauen. Programme, die ihren benötigten und erwarteten Speicher nicht allozieren können, werden instabil werden und vielleicht noch nicht mal mehr auf harte Abbruch-Anforderungen reagieren. Wenn das passiert, bleibt einem oft nichts anderes übrig, als seine Daten zu sichern und einen Neustart durchzuführen.
Als OS/2 3.0 erschien, waren 16 MB RAM noch für Hochleistungssysteme bestimmt. Die OS/2 2.0-Entwickler erwarteten einen freien Speicherbereich zwischen der privaten und gemeinsamen Region. Sie konnten damals nicht voraussehen, daß es einmal (für die damaligen Verhältnisse) gigantische Programme wie die aktuellen Mozilla oder OpenOffice geben würde, die fast im Alleingang die privaten, freien und gemeinsamen Regionen belegen würden. Wenn das passiert, können DLLs wie PMMERGE.DLL eventuell nicht mehr in der Lage sein, das OS/2 PM und WPS GUI stabil zu halten.
Glücklicherweise können Programme, die eine große Menge an virtuellem Speicher mißbrauchen, leicht identifiziert werden durch Theseus > System > RAM usage by process. Wenn Sie die nicht unmittelbar benötigen, schließen Sie sie besser, bevor das System (PM, WPS) feststeckt. Im Falle der Mozilla-Familie schafft das Schließen und Neustarten wieder freien Speicher in den privaten und gemeinsamen Regionen. Dadurch steht anderen Anwendungen fragmentierter (virtueller Speicher-) Platz zur Verfügung. Damit können Sie sich dann wieder einige Zeit über Wasser halten. Und das tun Sie am besten auch, bevor OpenOffice (PM) oder die WPS nicht mehr auf Mausaktionen reagieren (wie ich beim Schreiben dieses Artikel bemerken durfte).
Falls Theseus > System > Linear Usage by Process schon beim Start erschöpfte Speicherressourcen findet (beispielsweise < 200 MB freier linearer Speicher), sollten Sie überlegen, ob Sie nicht Systemhilfsprogramme aus CONFIG.SYS, dem Ordner Systemstart und der STARTUP.CMD entfernen sollen. Achten Sie auch auf große Speicherobjekte in der WPS mittels Linear Usage by Process. Vielleicht entdecken Sie WPS-DLLs, die nicht länger benötigt werden. Dann wäre es in der Tat besser, diese zu deregistrieren.
Hinsichtlich der Watchcat-Erweiterung WNICE(.DLL) behauptete Theseus: Objektgröße 32,000 MB.
Damit erforderte es in etwa soviel virtuellen Speicher wie die WPS. Und den benötigt es in jedem OS/2-Prozeß.
Sogar, obwohl es nur ein paar Kilobyte an privatem Speicher benutzte. Ich mochte Watchcats WNICE Plug-In eigentlich
immer sehr gerne (man kann damit im laufenden Betrieb Thread-Prioritäten ändern), aber nachdem ich nun
erkennen mußte, welchen Preis im Sinne von virtuellem Speicher ich dafür zahlen mußte, habe ich es
entfernt.
Beachten Sie auch, daß die Druckertreiber – die in jedem Prozeß verfügbar sind – relativ groß sind. Deinstallieren Sie also besser die Druckertreiber in den Objekten, die Sie nicht mehr benötigen.
Und zu guter Letzt: Verpassen Sie OS/2 doch ein Korsett, indem Sie ein paar Einstellungen in der CONFIG.SYS ändern. Damit umschiffen Sie die eine oder andere Klippe in Situationen mit erschöpftem gemeinsamen Speicher.
Ich denke dabei an die folgenden Kernel-bezogenen CONFIG.SYS-Einstellungen:
REM [4] KERNEL DIRECTIVE STATEMENTS DLLBASING=OFF MEMMAN=SWAP,PROTECT rem MEMMAN=SWAP,PROTECT,COMMIT SWAPPATH=I:\ 30000 1024 THREADS=512 PROCESSES=192 PRIORITY=DYNAMIC IOPL=YES MAXWAIT=1 rem When you do not need DOS or WIN/OS2 rem PROTECTONLY=NO VIRTUALADDRESSLIMIT=1024 SET JAVA_HIGH_MEMORY=1
Damit endet dieser Artikel über Theseus. Nächsten Monat werden wir uns die Techniken zum virtuellen Speicher etwas mehr im Detail anschauen.