[Freifunk Franken] Suche VM fuer monitoring

mail at adrianschmutzler.de mail at adrianschmutzler.de
So Apr 1 00:42:55 CEST 2018


Hallo Tim,

> -----Original Message-----
> From: franken [mailto:franken-bounces at freifunk.net] On Behalf Of Tim
> Niemeyer
> Sent: Sonntag, 1. April 2018 00:09
> To: Freifunk Franken <franken at freifunk.net>
> Subject: Re: [Freifunk Franken] Suche VM fuer monitoring
> 
> Moin Adrian
> 
> Am Samstag, den 31.03.2018, 23:33 +0200 schrieb
> mail at adrianschmutzler.de:
> > Hallo Tim,
> >
> > > -----Original Message-----
> > > From: franken [mailto:franken-bounces at freifunk.net] On Behalf Of Tim
> > > Niemeyer
> > > Sent: Samstag, 31. März 2018 21:52
> > > To: Freifunk Franken <franken at freifunk.net>
> > > Subject: Re: [Freifunk Franken] Suche VM fuer monitoring
> > >
> > > Am Samstag, den 03.03.2018, 15:55 +0100 schrieb Tim Niemeyer:
> > > > Hi
> > > >
> > > > Wir suchen gerade eine neue VM für das Monitoring.
> > >
> > > Da sich da immer noch nichts ergeben hat.
> >
> > Läuft das jetzt noch auf der alten Maschine oder hast du migriert?
> 
> Noch auf der selben Maschine wie vorher. Aber da fast ein Monat lang nichts
> passierte, sah ich mich gezwungen der Situation einen neuen Glanz zu
> verschaffen.
> 
> > >
> > > > Anforderungen:
> > > > * min. 16 GB RAM
> > >
> > > Wir probieren das ganz mal mit 8 GB Ram...
> >
> > Ich habe jetzt den cache pool für innodb von 10 GB auf 4 GB reduziert.
> > Mal sehen, was passiert.
> 
> Ich dachte immer der stellt sich automatisch ein. Wir müssen den Verbrauch
> runter kriegen, sonst finden wir nie einen neuen Host.

Den InnoDB Cache stelle ich manuell ein:

https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool-resize.html

/etc/mysql/my.cnf

> 
> 
> > >
> > > > * min. 40 GB SSD Disk
> > > > * 4 CPU's ab Generation Sandy Bridge
> > >
> > > ... und 2 CPU's.
> > >
> > > > Wenn wer da was über hat, gern mal melden.
> > >
> > > Aktuell läuft auf der Maschine auch ein monin, welches übermäßig
> > > viel Disk
> >
> > Woran genau siehst du das?
> 
> In htop
> 
> >
> > > usage hat. Weiter verbrauchte die Datenbank mehr RAM als da war und
> > > hat bereits geswappt. Hier muss unbedingt nachjustiert werden.
> >
> > Bis jetzt waren die Swaps immer winzig.
> Winzig ist schon zu viel. Swap Nutzung wäre im Extrem-Fall (z.B. DOS) ok, um
> einen Absturz zu verhindern. Im Regelbetrieb darf der nicht beansprucht
> werden.
> 
> > Ich habe nie ganz verstanden, warum zusätzlich zu dem InnoDB cache
> > pool nochmal so viel Caching stattfindet. Ich habe auch weder im
> > Internet noch im Gespräch mit MySQL Experten hierzu Erleuchtung
> > gefunden. Mit welchen Tools könnte ich untersuchen, woraus sich der
> > (System-)Cache zusammensetzt? (Um herauszufinden, ob das von mysql
> > kommt oder von anderen Programmen)
> Caching ist für das Dateisystem. Das war nicht unser Problem, da der Cache
> automatisch verfällt, wenn der Ram anderweitig verbraucht wird.

Naja, ich wüsste schon gerne, warum hier innerhalb von Minuten mehrere GB gecacht werden. Die Frage ist v.a., ob es hier zu doppeltem Caching kommt (innodb_pool und filesystem).

> 
> > Weiterhin konnte ich vor zwei Wochen einige Performance-Probleme im
> > Code lösen, die hausgemacht waren. Seitdem lief das Monitoring sehr
> > schön stabil (mit Ausnahme der langen Ladezeiten der
> > Routerdetailseite).
> Das ist gut. Vielleicht sollten wir auch überlegen das Feature-Set zu
> reduzieren.
> 
> Was brauchen wir vom Monitoring wirklich, was kann weg und was ist nur
> Spielerei?
> 
> z.B.:
> - Muss wirklich der RAM Verbrauch der Knoten geloggt werden?
> - Muss wirklich jedes Interface dargestellt werden?
> - Was von der API kann weg?
> - etc..
> 
> Aus meiner Sicht sollte das zentrale Monitoring sich auf ein paar wesentliche
> Dinge beschränken:
> - Karte mit Knoten, deren Verbindungen und den Hoods
> - API, damit die freifunk-karte.de versorgt wird
> 
> Optional könnte folgendes sinnvoll sein:
> - Anzahl aller Knoten
> - Anzahl Knoten pro Hood
> 
> Nicht nötig sind (weil diese Dinge auch dezentral zur Verfügung gestellt
> werden könnten und sollten):
> - Statistiken pro Knoten
> - Kontakt-Daten

Das Monitoring skaliert nahezu ausschließlich mit den Routerdetailstatistiken. Alles andere ist egal.

Hier sind am relevantesten die netif-Statistiken, weil hier der Zeitstrahl mal die Anzahl an Interfaces geloggt wird.

Grüße

Adrian

> 
> Grüße
> Tim
> 
> > Grüße
> >
> > Adrian
> >
> > >
> > > Tim
> > >
> > >
> > > > Tim
> > > > _______________________________________________
> > > > franken mailing list
> > > > franken at freifunk.net
> > > > http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net
> >
> > _______________________________________________
> > franken mailing list
> > franken at freifunk.net
> > http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net




Mehr Informationen über die Mailingliste franken