From: Marek Lindner <lindner_marek@yahoo.de>
To: b.a.t.m.a.n@open-mesh.net
Subject: Re: [B.A.T.M.A.N.] IP Aggregation
Date: Tue, 9 Jan 2007 15:15:42 +0100 (MET) [thread overview]
Message-ID: <200701091453.27005.lindner_marek@yahoo.de> (raw)
In-Reply-To: <45A27A1A.3030608@gmx.net>
Hi,
> Ich würde vorschlagen alle notwendigen Schritte zu machen, so dass der
> Code tendenziell die bestmöglichen Entscheidungen beim Routing trifft.
> Wenn Uns Linkstate-Komponenten dabei helfen (ETX-Werte zu
> Single-Hop-Nachbarn) können wir gerne darauf zurückgreifen. Bislang sehe
> Ich die Notwendigkeit jedoch nicht. Wenn der Code dann beim Routing sein
> Bestes gibt können wir schauen wie wir ihn in Richtung Skalierbarkeit
> optimieren.
schön. Wollte das nicht sofort einbauen, aber solche Ideen brauchen ein
bisschen Zeit. ;-)
> Was die Abstürze angeht kann Ich die Aussage von Lui nur bestätigen -
> wir haben ein Memory-Leak. Der Speicherverbrauch stieg auf der Zwingli
> mit etwa 0.2% des Gesamtspeichers pro Stunde. Ich habe den Daemon
> daraufhin wieder abgeschaltet, da Ich ungern die Zwingli lahmlegen
> möchte - ein Neustart geht leider nicht remote. Auf dem WRT in der
> Wagenburg läuft der Daemon seit Tagen durch - der Speicherverbauch
> beträgt konstant 2,7 %.
> Ziemlich ominös das Ganze...
In der Tat eigenartig. Gibt es irgendwelche bekannten Unterschiede wie:
Startparameter, Nachbarkonstellation, etc ?
Um den Memory Leaks auf die Schliche zu kommen habe ich unseren internen
MemoryChecker so umgebaut, dass er nun etwas brauchbares Auspuckt. An den
Problemorten einfach mit Debuglevel > 0 starten, eine Weile laufen lassen und
den Speicherverbrauch beobachten. Wenn dieser ansteigt, muss batman beendet
werden und dann sollte ein solcher Output erscheinen:
Memory leak detected, malloc tag = 7
Memory leak detected, malloc tag = 7
Memory leak detected, malloc tag = 7
Memory leak detected, malloc tag = 7
Memory leak detected, malloc tag = 6
Memory leak detected, malloc tag = 2
Memory leak detected, malloc tag = 1
Schickt mir den dann einfach.
Es ist durchaus denkbar, dass ihr diesen Output *nicht* seht. Der
MemoryChecker kann nur "richtige" MemoryLeaks finden (benutzer Speicher, der
nicht freigegeben wurde). Möglicherweise handelt es sich aber um "logische"
MemoryLeaks (es wird immer mehr und mehr Speicher angefordet, beim Beenden
aber alles wieder freigegeben). Letzteres wäre im Output natürlich nicht
sichtbar.
Gruß,
Marek
prev parent reply other threads:[~2007-01-09 14:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-08 13:15 [B.A.T.M.A.N.] IP Aggregation Marek Lindner
2007-01-08 17:06 ` elektra
2007-01-09 14:15 ` Marek Lindner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200701091453.27005.lindner_marek@yahoo.de \
--to=lindner_marek@yahoo.de \
--cc=b.a.t.m.a.n@open-mesh.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox