9.24.0370/0372: freier RAM ohne ersichtlichen Grund gesunken

[Jirka]

Hallo,

beim 1781AW ist für mich ohne ersichtlichen Grund der freie RAM nach Neustart des Gerätes mit Firmware 9.24.0370/0372 von zuvor ca. 34,5 MB auf ca. 19,5 MB abgesunken.
Beim 1781EW, 1781A, 1781VAW oder 1781VA habe ich eine ähnliche Verschlechterung nicht feststellen können.
Aufgefallen ist es, weil 1781AW mit Content-Filter mit Speichermangel abstürzten. Der Speicherverlust/-verbrauch auf fast 0 MB freien RAM tritt kurzfristig ein.

Vielen Dank und viele Grüße,
Jirka

[Jirka]

Hallo zusammen,

Problem existiert mit der 9.24.0379 nach wie vor. Umstieg auf 10.12(-RU6) ebenso keine Alternative, da liegt genau das gleiche Problem vor (und es werden noch weitere 3 MB Arbeitsspeicher benötigt).
Möglicherweise ist das Problem ja auch schon in einer neueren Beta-Version gefixt, schließlich ist die 9.24.0379 vom 09.03.2018 - seitdem sind 3 Wochen vergangen.
Wie gesagt, es ist nur der 1781AW betroffen, da muss ja irgendwas falsch gelaufen sein.

Vielen Dank und viele Grüße,
Jirka

[Jirka]

10.12.0355 ohne Änderung

[Jirka]

Hallo,

ich erlaube mir nach 5 Monaten mal höflich nachzufragen, wieso dieses Problem anscheinend bis heute nicht angegangen wurde. Wann kann man damit rechnen, dass Geräte vom Typ 1781AW wieder über ausreichend freien RAM verfügen? Sind noch weitere Angaben als die hier bereits gemachten nötig, wenn ja welche?

Vielen Dank und viele Grüße,
Jirka

[MoinMoin]

Moin Jirka!

Hasst du das Problem mal an den Support gemeldet?

Ciao, Georg

[Jirka]

Moin Georg,

nein. Da das Problem damals ja erstmalig in einer Beta-Version auftrat und Fehler in Beta-Versionen nicht an den Support gemeldet werden sollen, habe ich es nur hier kundgetan und darauf vertraut, dass sich das dann schon mal jemand anschauen wird bzw. dass das Problem zumindest erst mal zur Kenntnis genommen wird.

Vielen Dank und viele Grüße,
Jirka

[LoUiS]

Hallo,

dabei handelt es sich nicht um einen Fehler, sondern um den Umstand, dass die Firmware weiter entwickelt wird und durch neue Features/Fixes ab dieser Build mehr RAM von der MMU reserviert wird. Dies passiert hier in 16 MByte Schritten. Ist also leider "works as designed".

Ciao
LoUiS

[Jirka]

Hallo LoUiS,

vielen Dank für die Info.

Dass das in 16-MB-Schritten passiert, ist natürlich bei einem freien RAM der eh nur noch bei knapp 35 MB liegt, echt unglücklich. Das muss ja auch irgendwann mal reingekommen sein, früher hatten die Geräte ja überhaupt nur 16 MB RAM. Aber wie Alfred seinerzeit schrieb, es ist noch gar nicht so lange her, irgendwie werden die 128 MB schon voll werden. Und 20 MB freier RAM ist ja nun auch nicht wenig, aber die Geräte stürzen mit Speichermangel ab. Ein 1722 läuft mit 2 MB freien RAM problemlos, ich weiß nicht, was damals anders programmiert wurde.

Aber so richtig verstehen tue ich es auch nicht. Was macht die MMU denn mit dem RAM, wofür ist der? Kann mir das nicht noch mal einer erklären, Alfred vielleicht? Muss ja nicht ausschweifend und tiefgründig sein. Folgendes ist mir schon immer aufgefallen und habe ich auch noch nie kapiert:

Ein 'show mem' liefert auf einem 1781AW (9.24.0413):

Code: Alles auswählen

Total: RAM: 76.2 MBytes
Status : Blocks     Big          Small        Total
----------------------------------------------------------
USED   : 59569      2.0 MBytes   96 Bytes     55.1 MBytes
FREE   : 7567       14.6 MBytes  96 Bytes     21.0 MBytes

auf einem 1781EW hingegen:

Code: Alles auswählen

Total: RAM: 92.2 MBytes
Status : Blocks     Big          Small        Total
----------------------------------------------------------
USED   : 48854      3.4 MBytes   96 Bytes     47.5 MBytes
FREE   : 569        44.3 MBytes  96 Bytes     44.6 MBytes

Wieso unterscheidet sich hier die Angabe des Total-RAMs??? Die Geräte haben doch von Haus aus erst mal gleich viel RAM, also wieso gibt der Befehl das so blöd aus? Das habe ich wie gesagt noch nie verstanden, wieso da nicht 128 MB Total-RAM steht, aber gut, man muss und kann nicht alles verstehen.
Ein 1781A sieht übrigens so aus:

Code: Alles auswählen

Total: RAM: 92.6 MBytes
Status : Blocks     Big          Small        Total
----------------------------------------------------------
USED   : 50234      3.4 MBytes   96 Bytes     35.1 MBytes
FREE   : 1060       57.0 MBytes  96 Bytes     57.5 MBytes

Der hat also 92,6 MB Total-RAM. Stimmt also auch nicht mit dem 1781EW überein.

Vielen Dank und viele Grüße,
Jirka

[alf29]

Moin,

Aber so richtig verstehen tue ich es auch nicht. Was macht die MMU denn mit dem RAM, wofür ist der? Kann mir das nicht noch mal einer erklären, Alfred vielleicht? Muss ja nicht ausschweifend und tiefgründig sein.

Nichts ausschweifendes, eine fünfseitige Abhandlung über MMUs und Speichermanagement reicht völlig aus, gelle

Also Du weißt vielleicht grob, was eine Memory Management Unit ist und das sie den physischen Speicher in Seiten gleicher Größe einteilt. Das ist auf den Freescale-CPUs in den LANCOMs genauso, nur weil wir keinen Sekundärspeicher haben, wird die MMU nicht dafür benutzt, um gerade nicht benutzte Teile auszulagern, sondern nur, um an die Seiten Attribute zu hängen. Die Seiten, in denen der Programmcode des LCOS liegt, sind darüber schreibgeschützt, d.h. bevor durch Programmierfehler versehentlich Codeteile überschrieben werden und in der Folge merkwürdige Dinge passieren, gibt's wengistens einen sauberen Absturz. Nicht daß das Dir als Kunden in der Situation helfen würde, aber uns hilft das bei Auffinden von Fehlern im LCOS...

Eine MMU muß nun bei jedem Speicherzugriff nachschauen, in welcher Seite die Adresse liegt und ob der Zugriff erlaubt ist. Diese Seitentabellen legt das Betriebssystem selber im Hauptspeicher an. Damit nicht jeder Speicherzugriff einen weiteren in diese Tabellen nach sich zieht, hat die MMU einen Cache für Tabelleneinträge, den sogenannten TLB (Translation Lookaside Buffer). Dieser Buffer kann nur eine endliche Anzahl Einträge halten, wenn ein Zugriff auf eine Seite erfolgt, dir nicht im TLB verzeichnet ist, gibt's einen "TLB Miss", und den zu behandeln ist zumindest auf diesen CPUs eine ziemlich teure Angelegenheit. Die Seitengröße ist im LCOS deswegen so gewählt, daß der TLB zum Start des LCOS nur ein einziges Mal gefüllt werden muß und es im Betrieb nie TLB-Misses gibt. Der Nachteil: je größer die Seitengröße, desto größer der Verschnitt, wenn man den LCOS-Programmcode schreibschützen will. Wächst der Code mit einem Upgrade auf 16 MByte plus ein Byte, dann muß man eben 32 MByte schreibschützen und 16 MByte minus ein Byte stehen für den Rest nicht mehr zur Verfügung.

Das so zu machen, war seinerzeit eine Designentscheidung und eine Abwägung zwischen Verschnitt und Laufzeiteffizienz. Da das Memory Management eine so grundlegende Sache ist, solltest Du Dir auch keine Hoffnung machen, daß für Deinen Einzelfall daran etwas geändert wird. Wenn Du den Speicher brauchst, mußt Du halt auf einem älteren LCOS bleiben.


Viele Grüße

Alfred

[alf29]

Moin,

Teil 2:

Wegen des unterschiedlichen Total-RAM: hier geht es nur um den Heap, d.h. den Teil, auf dem dynamisch im Betrieb Speicher allokiert wird. Bereits durch das Laden des LCOS statisch belegte Bereiche rechnen nicht dazu. Der Unterschied zwischen den 76 und den 92 MByte gibt genau eine von den erwähnten 16 MByte-Seiten, eine Firmware mit ADSL ist eben größer und man braucht für das Schützen des Programmcodes eine Seite mehr. Hinter dem Programmcode liegen noch einige vorinitialisierte, statische Datenstrukturen, die gehen auch fix vom Heap ab, sind aber read-write. Diverse Module legen direkt nach dem Start weitere Strukturen auf dem Heap an, z.B. für Paketpuffer. Das ist das, was Du direkt nach dem Start als "USED" siehst.

Zu dem Punkt, früher war doch alles besser: Nostalgie ist auch nicht mehr das, was sie einmal war. Niemand wird Dir hier irgendwelche Details über die Programmierung des LCOS gestern und heute auseinandersetzen - wenn Du das willst, bewirb Dich als Entwickler bei LANCOM Was ich aber z.B. von der Entwicklung des IPv6-Stacks (und auch der neuen Teil eim IPv4) weiß, ist daß man in gewissen Grenzen Performance gegen Speicherverbrauch tauschen kann: Der Compiler kann den erzeugten Code auf Größe oder Performance optimieren, und man kann immer wieder benötigte Werte in einem Puffer halten oder jedes Mal neu berechnen. Andere Programmiertechniken bringen vielleicht 20 % mehr Performance, auf Kosten von doppelt soviel Speicherverbrauch. Aber wenn man den Speicher hat, warum soll man ihn nicht auch nutzen? Freier Speicher ist ungenutzter ist verschwendeter Speicher...

Viele Grüße

Alfred

[Jirka]

Hallo Alfred,

erst mal vielen Dank für die meiner Ansicht nach fast zu ausführliche Darlegung.

Nichts ausschweifendes, eine fünfseitige Abhandlung über MMUs und Speichermanagement reicht völlig aus, gelle

Ach deswegen hat die Zeit beim Bier gestern nicht mehr gereicht.

Nicht daß das Dir als Kunden in der Situation helfen würde, aber uns hilft das bei Auffinden von Fehlern im LCOS...

...was mir ja dann letztlich auch hilft.

Wächst der Code mit einem Upgrade auf 16 MByte plus ein Byte, dann muß man eben 32 MByte schreibschützen und 16 MByte minus ein Byte stehen für den Rest nicht mehr zur Verfügung.

Ok, verstanden.

Da das Memory Management eine so grundlegende Sache ist, solltest Du Dir auch keine Hoffnung machen, daß für Deinen Einzelfall daran etwas geändert wird.

Bisher war ich ja von einem Bug ausgegangen, weil sich für mich unerklärlich von einer Beta(!)-Build-Nummer auf die andere derartig der freie RAM reduziert hatte ohne dass es ein neues Feature gibt, immerhin befanden wir uns schon jenseits des RU9/SU9.
Ich mache mir also keine Hoffnung und jetzt erst recht nicht mehr, sondern wollte das nur abgeklärt haben. Ich werde dem Kunden jetzt nahe legen, an den betroffenen Standorten neue Router zu kaufen. Fertig. Das betrifft ja auch nur ein Bildungswerk, die den Content-Filter einsetzen. Ich fahre jetzt noch einen letzten Versuch, indem ich die gleichzeitigen Sessions auf 500 begrenze und wenn auch das nichts bringt, dann kann ich eben auch nichts mehr tun.

Wenn Du den Speicher brauchst, mußt Du halt auf einem älteren LCOS bleiben.

Oder so. Wobei man sich in dem Fall schon genau überlegen muss, mit welchen Bugs man noch leben kann, aber im konkreten Fall sind die vermutlich nicht erheblich.

Wegen des unterschiedlichen Total-RAM: hier geht es nur um den Heap, d.h. den Teil, auf dem dynamisch im Betrieb Speicher allokiert wird. Bereits durch das Laden des LCOS statisch belegte Bereiche rechnen nicht dazu.

Ok, also RAM wird genutzt für a) statisch belegte Bereiche durch das Laden des LCOS und b) durch den Heap, also der Teil, auf dem dynamisch im Betrieb Speicher allokiert wird.
In meinem ganz konkreten Fall oben hat sich also a) um 16 MB vergrößert und damit ist der Platz für b) um 16 MB geschrumpft, folglich ist der Total-RAM im 'show mem'-Kommando um 16 MB gefallen. Der eigentliche used-RAM (im 'show mem') ist gleich gelblieben (oder fast gleich, der ändert sich ja auch dynamisch).

Der Unterschied zwischen den 76 und den 92 MByte gibt genau eine von den erwähnten 16 MByte-Seiten, eine Firmware mit ADSL ist eben größer und man braucht für das Schützen des Programmcodes eine Seite mehr.

Soweit ok. Warum hat der 1781A dann 0,4 MB mehr Total-RAM? (0,4 ungleich 16 oder ein Vielfaches davon)

Zu dem Punkt, früher war doch alles besser.

Habe ich nicht gesagt. Ein bisschen was war besser.

Niemand wird Dir hier irgendwelche Details über die Programmierung des LCOS gestern und heute auseinandersetzen - wenn Du das willst, bewirb Dich als Entwickler bei LANCOM

Das habe ich auch nicht gewollt, dass das jemand tut. Ich möchte nur verstehen, was Total-RAM eigentlich ist und wie ich den Speicherverbrauch der Geräte zu interpretieren habe. Ich monitore u. a. doch auch den freien RAM, das weißt Du. Ich mache das, um nach Abstürzen zu sehen, war das ein allmählicher Speicherverlust oder zum Beispiel ein rapider. Gibt es Speicherfresser im LCOS usw. Letztlich habe ich also den RAM in gewisser Weise im Auge. Was ich bisher nicht wusste ist, dass der freie RAM, der abfällt, wenn ich z. B. von der 9.24 auf die 10.12 umstelle, gar nicht auf Kosten des used-RAM im Heap geht, wovon ich bisher einfach ausging, z. B. hier nach dem Firmware-Update Mitte April (-32 MB).

2018-07-19 13_31_50-PRTG Network Monitor (SERVER) _ Details des Sensors.png

Und zum Entwickler: Wenn dann würde ich eher in der Qualitätssicherung rumwirbeln, aber daraus wird aus Dir bekannten Gründen nichts. Und dann ist es eben so.

Was ich aber z.B. von der Entwicklung des IPv6-Stacks (und auch der neuen Teil eim IPv4) weiß, ist daß man in gewissen Grenzen Performance gegen Speicherverbrauch tauschen kann: Der Compiler kann den erzeugten Code auf Größe oder Performance optimieren, und man kann immer wieder benötigte Werte in einem Puffer halten oder jedes Mal neu berechnen. Andere Programmiertechniken bringen vielleicht 20 % mehr Performance, auf Kosten von doppelt soviel Speicherverbrauch. Aber wenn man den Speicher hat, warum soll man ihn nicht auch nutzen? Freier Speicher ist ungenutzter ist verschwendeter Speicher...

Volle Zustimmmung.

So, nun wollen wir mal das neu erlernte Wissen anwenden. Interessant wäre aus dieser Hinschicht also auch den Used-RAM im Heap zu monitoren. Kann man aber gar nicht, der Wert ist nicht mal per SNMP abfragbar, oder habe ich was übersehen? Also bleibt nur der freie RAM, der dann aber nur innerhalb einer Build-Nummer bewertet werden kann. Sobald da auch nur ein Firmware-Update auf eine andere Build-Nummer stattgefunden hat, kann man den freien RAM nicht mehr in Relation setzen oder eben nur unter Berücksichtigung der von Dir erwähnten (und mir hier wiederholten) Fakten.

Gut, nun würde ich denn gerne noch wissen, wenn ich mir jetzt mal einen 1781EF+ anschaue, ein sehr schönes Gerät, der hoffentlich nicht so schnell wie der 1781EF keinen Support mehr bekommt, dann zeigt sich mit Firmware 10.12.0437 folgende Ausgabe des 'show mem':

Code: Alles auswählen

Total: RAM: 187.6 MBytes
Status : Blocks     Big          Small        Total
----------------------------------------------------------
USED   : 106838     3.4 MBytes   96 Bytes     61.8 MBytes
FREE   : 30902      99.7 MBytes  96 Bytes     125.8 MBytes

Mit Firmware 9.24.0413 hingegen:

Code: Alles auswählen

Total: RAM: 208.2 MBytes
Status : Blocks     Big          Small        Total
----------------------------------------------------------
USED   : 59212      13.3 MBytes  96 Bytes     61.6 MBytes
FREE   : 2203       158.0 MBytes 96 Bytes     159.8 MBytes

Total-RAM ist ein Unterschied von 20,6 MB. Also 16 MB + 4,6 MB für irgendwas anderes, was ich entweder noch nicht verstanden habe, oder was hier noch nicht erwähnt wurde.
Used-RAM ist fast gleich geblieben. (Echt erstaunlich, hätte ich gar nicht mit gerechnet.)
Aber Free-RAM ist um 34 MB gesunken, wie geht das nun? Hätte nach Adam Riese doch eher was bei 20 MB sein müssen, oder nicht?
Beim Gerät mit der 9.24.0413 ist die Summe aus Used-RAM und Free-RAM auch nicht Total-RAM, das wären 221,4 MB. Ausgewiesen sind aber 208,2 MB, also 13,2 weniger. Nimmt man diese 13,2 und addiert sie zu den 20,6 wären wir ungefähr bei den 34, aber das muss ja dann auch so sein, ne?
Aber da ist doch jetzt was faul in der 9.24, oder?

Vielen Dank und viele Grüße,
Jirka

[alf29]

Tach,

Soweit ok. Warum hat der 1781A dann 0,4 MB mehr Total-RAM? (0,4
ungleich 16 oder ein Vielfaches davon)

Das hatte ich in einem Nebensatz erwähnt, das LCOS bringt nicht nur Programmcode mit, sondern auch statische Daten, die vorinitialisiert sein können oder nicht, und die sind natürlich nicht schreibgeschützt. Ich weiß nicht ob Dir Begriffe wie "text-", "data-" oder "bss-Segment" etwas sagen. Man kann sich das Layout vereinfacht so vorstellen:

• Programmcode & konstante Daten, aufgerundet auf 16 MByte & schreibgeschützt

• Statisch (vom Compiler) angelegte Daten & Variablen, NICHT aufgerundet

• Heap (das was Du als "Total" siehst)

Ein 1781AW hat gegenüber einem 1781A zuätzlich den WLAN-Stack, da sind die ersten beiden Teile größer. Je nachdem wie's ausgeht, kostet das einmal eine komplette 16 MByte-Page plus noch eine bestimmte Menge Datenspeicher vor dem Heap.

Beim Gerät mit der 9.24.0413 ist die Summe aus Used-RAM und Free-RAM auch nicht Total-RAM, das wären 221,4 MB. Ausgewiesen sind aber 208,2 MB, also 13,2 weniger.

Dafür habe ich im Moment auch keine Erklärung. Ist auch nicht unbedingt mein Fachgebiet, das alles.