|
Site Index - Feedback - Impressum |
| |||||||||
|
![[Forum]](../../../images.os2.org/de/forum.gif){kind=small} |
|
![[Forum]](../../../images.os2.org/de/forum2.gif){kind=small} |
| ( Archiv ) | ( Neues Thema ) |
| ( Zeige die Threadübersicht ) | ( Zur Startübersicht ) |
| 08.08.2013 |
| Memory Analyse und Systemtuning: Wrapper für ABOVE512 (von Frank Wochatz, 08:47:16) | ^ |
| Jemand hatte hier den Tipp zu dem Tool above512 (Hobbes) gegeben (besten Dank!). Ich hab dafür mal ein kleines Tool in Rexx geschrieben, dass die Ausgabe etwas übersichtlicher formatiert, und sich auf den Speicher beschränkt (private memory und shared memory, jeweils unter und über 512), und alle Sekunde den Speicher abfragt und das Ergebnis ausgibt, und damit Veränderungen sofort transparent macht.
Das ist ganz schön um mal zu sehen, welche Programme Speicher ziehen, und ob der nach Programmende auch wieder korrekt freigegeben wird, oder auch zum System-Tuning. Das Script im Verzeichnis von above512 abspeichern, und starten. Beendet wird es mit CONTROL+C. Ich weiß nicht, ob above512 in jedem Fall immer korrekte Werte zurück gibt, da das Tool 10 Jahre alt ist. Müßte man ggf. überprüfen. Hier geht es erstmal soweit, zumindest sieht man in jeden Fall relative Veränderungen. Was das Teil macht, wenn der Shared Memory absäuft, konnte ich bislang nicht beoabachten (Mangels SM Problem). Die Ausgabe in einer Datei loggen geht natürlich auch: memmon.cmd >logfile.txt - - - schnipp /* memmon.cmd - memory monitor */ /* a wrapper for above512 to monitor memory usage */ /* use control+c to stop monitoring */ /* pm = private memory */ /* sm = shared memory */ /* left entries display memory below 512 */ /* right entries display memory above 512 */ out = 0 curline = "" first_string = "" call rxFuncAdd "SysLoadFuncs", "REXXUTIL", "SysLoadFuncs" call SysLoadFuncs SIGNAL ON HALT /* termine program with CONTROL+C */ do forever '@ABOVE512 2>nul | rxqueue 2>NUL 1>&2' call SysSleep 1 do while queued() <> 0 curLine = lineIN( "QUEUE:" ) if out = 0 then do parse var curLine first_string . if first_string = "current" then out = 1 else out = 0 end else do parse var curline val.1 . val.2 . . . val.3 . val.4 . say "pm:" val.1 "sm:" val.2 " <---512---> pm:" val.3 "sm:" val.4 out = 0 end end end exit HALT: exit - - - schnapp [ Leser: 353 ] |
| 09.08.2013 |
| Re: Memory Analyse und Systemtuning: Wrapper für ABOVE512 (von Wilfried, 12:11:39) | |
| Hallo Frank,
DANKE! Wilfried PS: Kann man das nicht auch mit THESEUS beobachten? Habs aber noch nicht gefunden. |
| Re: Memory Analyse und Systemtuning: Wrapper für ABOVE512 (von Andi B., 15:18:27) | |
| Für shared mem, was ja das hauptsächliche Problem bei uns ist, gibt's auch die GUI freesharedmem.exe o.ä. Müßte irgendwo im bugtracker verlinked sein. |
| Re: Memory Analyse und Systemtuning: Wrapper für ABOVE512 (von Holger, 17:06:34) | |
| In THESEUS unter System->Linear Usage By Process. Dort sieht man auch, welche dll wohin geladen wird (über oder unter die 512 MB-Grenze). Aber Achtung: Alle bisherigen Kernel von IBM haben einen Bug, der einen TRAP E verursachen kann, wenn eine dll aus dem Shared Memory über 512 MB entfernt wird - wenn z.B. das Programm, das die dll benutzt beendet wird. Ich habe das nochmal bei Mensys moniert, als die Version 2.2 rauskam. Dort sagte man mir, man hätte keine Zeit das zu fixen, das Problem wäre bekannt.
Da ich das Feature für sehr wichtig halte - nur so kann man größere SW-Pakete überhaupt noch unter ECS laufen lassen ohne den Shared Mem zu überlasten - habe ich mich eben selber hingesetzt. Der Fix ist bei Mensys, die wollten ihn austesten - gerade im Zusammenhang mit Open Office. Müsste mal nachfragen, was bei denen rausgekommen ist - bei mir funktioniert's (aber das heisst ja nicht viel). Meine Empfehlung, bis es soweit ist: MEMMAN=SWAP,NOPROTECT,NOPACK DLLBASING=OFF in die config.sys eintragen. Das hilft zumindest ein bischen. |
| Re: Memory Analyse und Systemtuning: Wrapper für ABOVE512 (von Lothar S., 19:43:33) | |
| und wichtig: dllbasing=off gehört an den obersten Rand der config.sys, sonst wirkt es nicht. auch kein "set" davorsetzen. |
| Re: Memory Analyse und Systemtuning: Wrapper für ABOVE512 (von Frank Wochatz, 22:20:02) | |
| >habe ich mich eben selber hingesetzt
Sauber. :) Du bist ev. auch einer der wenigen, die das überhaupt können. Danke für die Tipps soweit. |
| 10.08.2013 |
| FreeSharedMem.exe (von Andreas Schnellbacher, 11:45:46) | |
| http://svn.ecomstation.nl/flash10/raw-attachment/ticket/66/freeSharedMem.exe |
| Re: FreeSharedMem.exe (von Frank Wochatz, 13:31:22) | |
| Lustigerweise stimmen die Ausgaben der beiden Programme nicht überein. Oder kann mir das jemand stimmig an einem Beispiel vorrechnen?
|
| 3 Tools - 3 Werte (von Frank Wochatz, 14:01:35) | |
| Theseus zeigt nochmal einen anderen Wert an.
Wir sehen also mit drei verschiedenen Tools drei unterschiedliche Werte... Da gibt es wohl Interpretationspsielraum beim ermittel des freien SM. :/ |
| 11.08.2013 |
| Re: 3 Tools - 3 Werte (von Andreas Schnellbacher, 11:46:37) | |
| Bei mir nicht. Ich hab sogar noch ein viertes gefunden: ShMemCnt/ShMem von Jan van Wijk:
1) FreeSharedMem: 58327040 bytes ~~~~~~~ (Das entspricht 56960 kB und 55,625 MB.) 2) Theseus: There is 0.000M between the private and shared arenas. Shared arena starts at 08F60000, which is 143.375M. Free memory from 08F60000 for 55.625M, which is equivalent to 890 64K spaces. ~~~~~~ 3) Above512: current free virtual address space in kB (private / shared): 203200 / 56960 below 512MB line, 917504 / 392148 above 512MB line ~~~~~ 4) ShMemCnt: RC 8 CNT 58 ~~ |
| Re: 3 Tools - 3 Werte (von Holger, 12:33:42) | |
| Nun, das fängt schon mit dem Test an:
Jeder Programmstart verändert den SM durch das Laden von DLL's oder weil die PMMERGE.DLL Speicher für die Fenster reserviert. Zum Thema Interpretation: Dass XX MB frei sind bedeutet noch nicht, dass sie am Stück frei sind (das aber ist Voraussetzung, wenn ich große DLL's mit mehreren MB laden möchte). Und weniger angezeigter SharedMem kann in Wirklichkeit sogar mehr freien Platz bedeuten, nämlich dann wenn zwischen Shared und Private Arena noch Platz ist und nicht wie im Beispiel von Andreas 0MB. Dann kann der Kernel bei Bedarf die jeweilige Arena noch erweitern, wenn sie sich "getroffen" haben ist Schluß und es gibt nur noch den freien Speicher innerhalb der Arena. Desswegen auch meine Empfehlung, das DLLBASING abzuschalten - es sorgt nämlich dafür, dass einige System-Dll's (wie z.B. die PMMERGE.DLL) an bestimmte fixe Adressen geladen werden. Das hat den Vorteil, dass der Loader keine Fixups berechnen muss (bei den heutigen CPU-Geschwindigkeiten merkt das aber keiner mehr), erkauft mit dem Nachteil, dass die Shared Arena schon nach dem Systemstart durchlöchert ist wie ein Sieb - die Shared Arena grenzt an die Private Arena, dazwischen gibt es Löcher freien Speichers und wenn etwas so Groß ist, dass es in kein Loch mehr hineinpasst dann war's das. Mit Theseus kann man das sehr schön sehen, was wohin plaziert wird. |
| Re: 3 Tools - 3 Werte (von Frank Wochatz, 16:01:29) | |
| >Jeder Programmstart verändert den SM durch das Laden von DLL's oder weil die PMMERGE.DLL Speicher für die Fenster reserviert.
Das ist klar, ich hab dazu alle drei Programme parallel laufen lassen. Die Werte waren völlig abweichend. DLLBASING habe ich nun mal abgschaltet (wobei ich wie gesagt nur extrem selten Probleme mit SM habe, da ich OpenOffice o.ä. nicht einsetze). Ich werde das mal weiter beobachten. Above512 hatte ich mir ausgesucht, weil auch der private Speicher angezeigt wird, und ich mein System mal generell optimieren möchte. Theseus ist dafür natürlich noch besser, und FSM natürlich fürs reine Shared Memory beobachten das einfachste. Naja, hatte den Wrapper auch schon für was anderes rumliegen, war jetzt nicht der Wahnsinnsaufwand... und werde es mal weiter zum loggen verwenden. Soweit erstmal. |
| 12.08.2013 |
| Re: 3 Tools - 3 Werte (von Frank Wochatz, 07:04:45) | |
| Ok Andreas, also FreeSharedMem zeigt nur den Shared Memory unter der 512er Grenze an, ich hatte den gesamten SM aus Above512 addiert, und kam dann natürlich auf einen ganz anderen Wert. Theseus habe ich schon wieder deinstalliert, da das Ding einen Treiber braucht und damit zusätzlicher Ballast ist. |
| Re: 3 Tools - 3 Werte (von ., 12:14:08) | |
| > Theseus habe ich schon wieder deinstalliert, da das Ding einen Treiber braucht und damit zusätzlicher Ballast ist.
Wenn Dein Kernel nicht *sehr* alt ist, dann enthält er die von Theseus4 benötigte Schnittstelle bereits. Der Treiber ist dann nicht nötig. |
| Re: 3 Tools - 3 Werte (von Andreas Schnellbacher, 21:44:41) | |
| Ja, der Bereich bis 512 MB ist der, der immer knapp wird. Sieh Dir die
(mit Absicht provozierten) dramatischen Werte an, die ich als Beispiel beschrieben hab. Ich hatte nur meine uralte SeaMonkey-Version (noch nicht viel abgesurft) und danach OOo 3.2 geöffnet. Ich hab anschließend noch versucht, das System auf diesem Weg zum Absturz zu bringen, aber ich bin bis auf ca. 30 KB herangekommen, danach hatte ich keinen Bock mehr: Java-Apps, die immer fantastisch viel unteren Shared Mem brauchen, laufen hier derzeit nicht mehr und zum Kompilieren mit VAC hattte ich dann hkeinen Bock mehr. Interessant war, dass der Shared-Mem-Bereich anscheinend nach Reservierung nicht mehr freigegeben wurde, auch wenn die Anwendungen geschlossen wurden. Ich versteh davon zu wenig - merkwürdig! |
| 13.08.2013 |
| Re: 3 Tools - 3 Werte (von Andi B., 11:02:03) | |
| > Interessant war, dass der Shared-Mem-Bereich anscheinend nach Reservierung nicht mehr freigegeben wurde, auch wenn die Anwendungen geschlossen wurden.
Kann es sein, daß die .dlls noch nicht entladen wurden? AFAIK entscheidet der kernel ob und wann er eine dll aus dem Speicher wirft was nicht unbedingt beim Beenden der entsprechenden Anwendung sein muß. |
| Re: 3 Tools - 3 Werte (von Holger, 18:17:16) | |
| Der Kernel verwaltet einen Zähler - wenn alle Programme die dll nicht mehr benötigen, wird sie aus dem Shared Mem entfernt. Es gibt aber auch andere "Arten" von Speicherbelegung in diesem Bereich: Speicher, der zwischen Anwendungen zum Datenaustausch benutzt wird, Speicher, den eine dll anfordert um für Programme Daten zu speichern (z.B. Fensterpuffer usw.). Natürlich kann es auch sein, dass ein Programm den Speicher nicht sauber freigibt und er dann belegt bleibt - sollte aber eher die Ausnahme sein.
Die 512 MB Grenze wurde von IBM erfunden, um alte 16-Bit Programme und dll's weiter verwenden zu können, die für OS/2 Version 1 (für 286-er) entwickelt wurden. Man war sich schon früh im Klaren darüber, dass das irgendwann wohl zum Problem würde, man hat aber erst mit dem WSEB-Kernel damit begonnen, diese Grenze zu sprengen. Zuerst nur für Programmdaten, Scott Garfincle hat dann in einer späteren Kernelversion die Möglichkeit eingebaut, auch dll's in einen oberen Shared Memory zu laden - solange es reine 32-bit dll's sind. Leider haben alle Kernel den oben erwähnten Bug, der jetzt hoffentlich bald der Vergangenheit angehört. Dann kann man die ganzen dll's hochladen und entlastet damit den unteren SharedMem. |
| ( Zeige die Threadübersicht ) | [ Version zum Drucken ] | ( Zur Startübersicht ) |
| |||
| Mit * markierte Felder müssen ausgefüllt werden ! |
|
