Moin,
tun wir uns so einen großen Gefallen, wenn wir srv01 weiter verwenden? Mit netmon wieder darauf dürfte das nicht besser werden.
/dev/vda: Timing cached reads: 17912 MB in 2.00 seconds = 8965.49 MB/sec Timing buffered disk reads: 22 MB in 9.30 seconds = 2.37 MB/sec
Und selbst manches ls im Homedir von root dauert schon 10-15sec.
vg
Die last ist grade nicht sehr groß, aber srv01 lähmt. https://status.nordwest.freifunk.net/munin/ffnw.de/srv01.ffnw.de/index.html Wir sollten ihm nicht mehr last geben, eher die last besser verteilen. Was haben wir auf ihm was ihn so belastet? Sollten wir noch mal den srv auf Herz und Nieren über prüfen?!
Welche alternativen haben wir?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hi,
ich Frage mich gerade warum die Kiste immer noch konstant 30 Disk IOs pro Sekunde hat. Da läuft doch aktuell nichts IO intensives drauf. Irgendwas vergessen abzuschalten oder so?
LG Clemens
Am 18. Juli 2015 00:58:36 MESZ, schrieb picard picard@fr32k.de:
Die last ist grade nicht sehr groß, aber srv01 lähmt. https://status.nordwest.freifunk.net/munin/ffnw.de/srv01.ffnw.de/index.html Wir sollten ihm nicht mehr last geben, eher die last besser verteilen. Was haben wir auf ihm was ihn so belastet? Sollten wir noch mal den srv auf Herz und Nieren über prüfen?!
Welche alternativen haben wir? _______________________________________________ Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
Am Samstag, den 18.07.2015, 09:30 +0200 schrieb Clemens John:
Hi,
ich Frage mich gerade warum die Kiste immer noch konstant 30 Disk IOs pro Sekunde hat. Da läuft doch aktuell nichts IO intensives drauf. Irgendwas vergessen abzuschalten oder so?
munin-update rödelt da rum.
Am 18.07.2015 um 10:25 schrieb Bjoern Franke:
Am Samstag, den 18.07.2015, 09:30 +0200 schrieb Clemens John:
ich Frage mich gerade warum die Kiste immer noch konstant 30 Disk IOs pro Sekunde hat. Da läuft doch aktuell nichts IO intensives drauf. Irgendwas vergessen abzuschalten oder so?
munin-update rödelt da rum.
ich bin das we am munin dran! entferne nicht gebrauchte plugins und schau mir die last an, nötigen falls entferne ich unwichtige, last lästige plugins z.b multiping, httpload und sowas.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hi,
wenn Munin so krass IO zieht dann ist Plugins entfernen ist nur ein Tropfen auf den heißen Stein. Wenn wir das ganze auf den monitoring Server umziehen sollten wir da was mit tmpfs (o.Ä.) machen und die updates im RAM halten: https://deadlockprocess.wordpress.com/2012/03/09/how-to-configure-a-virtuali...
Gut dass uns das auffällt bevor wir die monitoring kiste vorbereitet haben :D Hätte nicht gedacht dass munin so krass io zieht.
LG Clemens
Am 18. Juli 2015 10:49:23 MESZ, schrieb picard freifunk@fr32k.de:
Am 18.07.2015 um 10:25 schrieb Bjoern Franke:
Am Samstag, den 18.07.2015, 09:30 +0200 schrieb Clemens John:
ich Frage mich gerade warum die Kiste immer noch konstant 30 Disk
IOs
pro Sekunde hat. Da läuft doch aktuell nichts IO intensives drauf. Irgendwas vergessen abzuschalten oder so?
munin-update rödelt da rum.
ich bin das we am munin dran! entferne nicht gebrauchte plugins und schau mir die last an, nötigen falls entferne ich unwichtige, last lästige plugins z.b multiping, httpload und sowas.
Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
Hi,
wenn Munin so krass IO zieht dann ist Plugins entfernen ist nur ein Tropfen auf den heißen Stein. Wenn wir das ganze auf den monitoring Server umziehen sollten wir da was mit tmpfs (o.Ä.) machen und die updates im RAM halten: https://deadlockprocess.wordpress.com/2012/03/09/how-to-configure-a-virtuali...
Gut dass uns das auffällt bevor wir die monitoring kiste vorbereitet haben :D
Jap :D
vg Tarek
Am 18.07.2015 um 11:11 schrieb Clemens John:
wenn Munin so krass IO zieht dann ist Plugins entfernen ist nur ein Tropfen auf den heißen Stein. Wenn wir das ganze auf den monitoring Server umziehen sollten wir da was mit tmpfs (o.Ä.) machen und die updates im RAM halten: https://deadlockprocess.wordpress.com/2012/03/09/how-to-configure-a-virtuali...
Gut dass uns das auffällt bevor wir die monitoring kiste vorbereitet haben :D Hätte nicht gedacht dass munin so krass io zieht.
ja das sollten wir machen ein ramdisk erstellen dafür!
rrdcached und ramdisk parallel?
Am 18.07.2015 um 10:49 schrieb picard:
ich bin das we am munin dran! entferne nicht gebrauchte plugins und schau mir die last an,
besserung konnte ich erreichen... https://status.nordwest.freifunk.net/munin/static/dynazoom.html?plugin_name=...
jetzt möchte ich rrdcached probieren!
Am 18.07.2015 um 10:25 schrieb Bjoern Franke:
munin-update rödelt da rum.
# RRD updates are per default, performed directly on the rrd files. # To reduce IO and enable the use of the rrdcached, uncomment it and set it to # the location of the socket that rrdcached uses. # #rrdcached_socket /var/run/rrdcached.sock
sollten wir rrdcached nutzen?
Am Samstag, den 18.07.2015, 11:07 +0200 schrieb picard:
Am 18.07.2015 um 10:25 schrieb Bjoern Franke:
munin-update rödelt da rum.
# RRD updates are per default, performed directly on the rrd files. # To reduce IO and enable the use of the rrdcached, uncomment it and set it to # the location of the socket that rrdcached uses. # #rrdcached_socket /var/run/rrdcached.sock
sollten wir rrdcached nutzen?
Klingt nach einer Idee.
Zitat von Bjoern Franke bjo@nord-west.org:
tun wir uns so einen großen Gefallen, wenn wir srv01 weiter verwenden? Mit netmon wieder darauf dürfte das nicht besser werden.
munin hat rrdcached bekommen, diesen hat clemens installiert, getestet usw... die IO ist wieder normal und avg load bewegt sich wieder im normalen bereich (avg1 0.12 | avg5 0.19 | avg15 0.21) dokumentiert ist das ganze auch https://pad.freifunk.net/p/ffnw-admin-dienste -> Munin -> Admin-Doku: https://fr32k.de/pad/p/ffnw_munin
-
Bjoern Franke -
Clemens John -
Jan-Tarek Butt -
picard -
picard