hallo,
ich habe nach erfolgreicher Installation eine für einen Idle Zustand hohe CPU Auslastung (4% bei 2 Kernen) und dauerhafte disk-writes um die 20k.
Icinga gibt mir einen Fehler “check_ntp_time: Invalid hostname/address - pool.ntp.org”.
Unter Zustand des NTP Server steht “No association ID’s returned”.
Woran kann das liegen?
Danke schonmal für eine kurze Antwort.
Gruß,
Afox
Hallo nochmal,
leider ist das Problem nach der Lösung des ntp-Problems weiterhin vorhanden. Ich habe bei sonst keiner anderen Maschine eine so hohe Auslastung beim “Nichtstuen”. Habt ihr zufällig ein paar Vergleichswerte für mich?
Eine Theorie von mir ist, dass die Überwachungssoftware dafür verantwortlich ist. Gibt es eine Möglichkeit die Aggressivität der Protokolle (falls für die Schreibvorgänge verantwortlich) zu reduzieren?
Gruß,
Afox
Bringe erst einmal in Erfahrung welcher Prozess für die Lasten verantwortlich ist. Ggf. dazu iotop manuell aus den Squeeze-Quellen nachinstallieren (manuelles entpacken reicht).
hi, danke für deine Antwort. Könntest du evtl. die Aussagen “aus den Squeeze-Quellen nachinstallieren” und “manuelles entpacken reicht” ein wenig konkretisieren. Meine Skills reichen nicht für einen Transfer und google hilft mir auch grade nicht weiter 
Hallo,
wenn Du keine Ahnung hast, solltest Du nun als aller erstes ein vollständiges Backup Deiner MobyDick erstellen. 
Anschließend:
cd /tmp
wget http://ftp.de.debian.org/debian/pool/main/i/iotop/iotop_0.4-2+squeeze1_all.deb
dpkg -i iotop_0.4-2+squeeze1_all.deb
Jetzt kannst du iotop nutzen.
Hinweis: Das Paket wird sich nach /usr installieren. Änderungen an /usr können nicht persistiert werden, sprich sie überleben einen Neustart nicht. Die Paket-Datenbank allerdings schon… d.h. du solltest nach einem Neustart hier aufräumen und als root “dpkg --purge iotop” ausführen.
wow, vielen Dank für die Mühe. Ich glaube es geht nicht komfortabler 
also ich habe iotop jetzt mal eine ganze Weile beobachtet und die die immerwieder und in sehr kurzen Abständen Writes verursachen sind:
java -Djava.Zeichengewusel
jbd2/dm-0-8 (relativ häufig)
jbd2/dm-1-8 (relativ häufig)
icinga -d /e~ga/icinga.cfg
postgres: st~ector process (sehr hohe write Zahlen um 180 kb/sec)
weitere Prozesse:
rsyslogd -c4
java -Xmx720~b/startup.jar
apache2 -k start
Jetzt weiß ich nicht ob da etwas nicht normal läuft. Ich kann nur sagen dass diese sehr häufig auftauchen und wieder verschwinden…
Speziell würde mich interessieren ob das Verhalten von jbd2 normal ist?
Wie viele Nutzer gibt es? Wie viele Nutzer sind davon ca. gerade aktiv?
Was wird unter “Total/Actual Disk Writes” angezeigt?
Läuft die MB auf einer VM oder als dediziertes System?
jbd2 ist das Journal des Dateisystems/LVM.
es gibt nur den anfänglich bereits vorhandenen Admin-Nutzer. Keiner aktiv 
(bin ja gerade dabei das einzurichten)
Total writes schwankt von 0-180 kb/sek
Moby läuft auf einer KVM:
virtuelle HDD-Settings: Bus/device=virtio, Storage=lvm, Format=QEMU image format (qcow2), Cache=Write back
Vielleicht liegt da der Hund begraben…
Wie hast du denn die hohe Auslastung überhaupt festgestellt (Methodik)?
Bitte Eckdaten zum Host- und KVM-Guest:
Bitte die Ausgabe von
cat /proc/loadavg
beider Systeme.
Bzgl. der ~180kb/s sehe ich erst einmal ehrlich gesagt kein Problem. Zum einen sind das keine Werte, zum anderen führen OpenFire, Incigna und Asterisk eben im Hintergrund periodisch Arbeiten aus. Aber wie gesagt, regelmäßige Spikes von 0 auf 180kb/s sollten kein Problem darstellen.
Hast du die Möglichkeit iostat -h -x 1 60 >/tmp/iostat.log auf dem Host-System auszuführen (ggf. musst du das sysstat Paket der von dir verwendeten Distribution vorher installieren)? Der Befehl würde für 60sek das System beobachten und nach /tmp/iostat.log loggen. Diesen Inhalt solltest du uns hier dann via pastebin.com etc. bereitstellen.
Ich kann z.B. CPU-usage, diskreads und -writes für jede KVM in Form eines Graphen anzeigen lassen und somit auch die einzelnen VMs miteinander vergleichen.
Host:
CPU: 2x Xeon E5620 (2,4 GHz, 12MB), HT ist aus also 8 echte Kerne
RAM: 48GB
KVM:
CPU: 1 socket, 2 cores
RAM: 4GB
cat /proc/loadavg-Ergebnisse:
Host: 0.02 0.03 0.00 1/911 457738
KVM: 0.01 0.03 0.05 1/308 6759
Der Host ist (noch) nicht sonderlich belastet da mein Projekt noch das Licht der Welt erblicken wird
iostat kennt er nicht
Daher schrieb ich, dass du dafür vermutlich das sysstat Paket deiner Distribution erst einmal installieren musst.
Aber ich sehe ehrlich gesagt nichts ungewöhnliches: Die load ist meiner Meinung nach vollkommen in Ordnung. Evtl. ist der Fehler in deiner Annahme zu suchen, dass die Kiste bei 0% liegen sollte (da sie deiner Meinung nach nichts macht). Diese Annahme wäre in meinen Augen falsch, schließlich laufen wie gesagt im Jabber-Server (XMPP, die JAVA-Sache) regelmäßig Tasks ab. Gleiches gilt für Asterisk und die MD-Webanwendung selber… dazu eben noch die regelm. Checks durch Nagios.
Du kannst ja mal testweise die ganzen Dienste der Reihe nach stoppen,
dann solltest du annähernd bei 0 angekommen sein.
Aber wie gesagt, auch wenn die Kiste vermeintlich noch nicht genutzt wird, laufen da bereits regelmäßige Tasks ab.
hi, ich habe das gerade gemacht und hänge mal die Ergebnisse an. Was auffällt: Postgre SQL scheint für realtiv viele writes verantwortlich zu sein…
ich habe wie folgt gestoppt:
20:30 Icinga
20:45 Nagios
20:50 xmppd
20:55 asterisk
21:00 apache2
21:05 postgresql
Hallo,
ich sehe auf den Screenshots nicht wirklich etwas, was einem Sorgen machen sollte.
Wenn dich das dennoch stört: Das ist der Stats Collector von postgresql (schön zu sehen wenn alles andere außer postgresql gestoppt ist und man iotop -o ausführt).
Zwei Möglichkeiten:
track_activities = off
track_counts = off
Das deaktiviert den Stats Collector.
Achtung: Bei Updates kann diese Datei überschrieben werden.
tmpfs /var/lib/postgresql/9.1/main/pg_stat_tmp tmpfs defaults,noatime,mode=1777,uid=postgres,gid=postgres,nosuid,nodev 0 0
Nach einem Neustart schreibt postgresql die Stats dann in den RAM was zu spürbarer IO-Aktivitätsreduktion führen sollte.
Achtung: Wenn sich die postgresql-Version ändert, muss die fstab-Zeile wieder angepasst werden. Alternativ kann man einen Versions-unabhängigen Pfad wählen und darauf in /etc/postgresql/9.1/main/postgresql.conf per stats_temp_directory = … verweisen. Trotzdem muss man bei Updates nachschauen, ob die Konfigurationsdatei überschrieben wurde. Hier wäre es schön wenn pascom einfach include_dir ‘directory’ setzen könnte und User würden dann Anpassungen in “directory” ablegen und müssen sich bei Updates keine Sorgen machen.
@ pascom:
Letzteres solltet ihr euch selber einmal anschauen und evtl. gar standardmäßig umsetzen.
Hallo zusammen,
Bitte fummelt nicht an der postgresql Konfiguration rum! Es hat einen Grund das die Konfiguration so ist wie sie ist, und gerade für unsere kommerziellen Anlagen müssen wir sicherstellen, das diese Stabil laufen - eigene Basteleien an dieser Stelle zu unterstützen wäre viel zu problematisch.
@Afox: Bei der Load sehe ich hier auch nichts ungewöhnliches - Schlussendlich sollen die Benutzer das System ja möglichst problemlos zur Kommunikation nutzen können, und um das zu erreichen passiert halt auf dem System auch so einiges auch im Hintergrund.
Grüße,
Jan
Hallo, so ganz ok war das System gestern nicht. Nachdem die genannten Services gestoppt waren habe ich nochmals iotop laufen lassen und mir fiel auf dass verhältnismäßig oft in die syslog geschrieben wurde.
Daraufhin habe ich mir die syslog einmal vorgenommen und es kam in sehr kurzen Abständen immer wieder die Meldung
localhost ntpd_intres[PID]: ntp_intres.request: permission denied
Weitere Nachforschungen ergaben den Tipp man solle mal den ntp-service manuell neustarten
service ntp restart
danach trat dieser Fehler nicht mehr auf!
ein nützlicher Befehl war mir in diesem Zusammenhang
iotop -oPak
Nun ist der größte “write-Verursacher” eindeutig PostgreSQL.
postgres:~or process
Wenn diese Writes optional durch die genannten Änderungen in den RAM verlagert werden könnten wäre mir dies Recht da eine SSD/HDD auch nicht besser wird wenn ständig geschrieben wird.
Nochmal etwas anderes: hat die Moby etwas Ähnliches wie Fail2Ban? Wie wird diese vor stumpfen 22er Attacken geschützt? Wie/wo konfiguriere ich am Besten meine Firewall?
Gruß,
Afox
Hallo,
ich glaube auch dass es nicht schaden würde, wenn pascom von Haus aus pg_stat_tmp auf ein TMPFS auslgern würde:
# ps faux
...]
postgres 3284 0.0 0.2 101440 9212 ? S 17:35 0:00 /TARGET/RAM/usr/lib/postgresql/9.1/bin/postgres -D /var/lib/postgr
postgres 3286 0.0 0.0 101440 1828 ? Ss 17:35 0:00 \_ postgres: writer process
postgres 3287 0.0 0.0 101440 1580 ? Ss 17:35 0:00 \_ postgres: wal writer process
postgres 3288 0.0 0.0 102732 3300 ? Ss 17:35 0:00 \_ postgres: autovacuum launcher process
postgres 3289 0.0 0.0 70444 1924 ? Ss 17:35 0:00 \_ postgres: stats collector process
# date
Fri May 8 17:35:51 CEST 2015
# cat /proc/3289/io
rchar: 273978
wchar: 821936
syscr: 68
syscw: 205
read_bytes: 0
write_bytes: 417792
cancelled_write_bytes: 139264
# date
Fri May 8 18:06:16 CEST 2015
# cat /proc/3289/io
rchar: 273978
wchar: 68220524
syscr: 68
syscw: 16933
read_bytes: 0
write_bytes: 35233792
cancelled_write_bytes: 139264
# date
Fri May 8 18:35:43 CEST 2015
# cat /proc/3289/io
rchar: 273978
wchar: 132331376
syscr: 68
syscw: 32845
read_bytes: 0
write_bytes: 68329472
cancelled_write_bytes: 139264
Wir sprechen also von einer Schreiblast von knapp 70MB pro Stunde (67911680 Bytes).
Vor allem weil sich das so einfach vermeiden lässt (ein Eintrag in /etc/fstab reicht, wobei fraglich ist, wozu es in einer Appliance diese Stats überhaupt braucht, da sie IMHO aktuell nicht verwendet werden) schließe ich mich Afox an. Neben SSDs sollte man auch an Installationen denken die auf SD-Karten schreiben (Rasperry Pi usw).
hi Whissi, könntest du vllt. nochmal einen Vorschlag dazu einstellen? Mir kommt es so vor als würde dies hier keine Beachtung finden… LG
Hallo zusammen,
hi Whissi, könntest du vllt. nochmal einen Vorschlag dazu einstellen? Mir kommt es so vor als würde dies hier keine Beachtung finden… LG
na klar findet es bei uns Beachtung (und Respekt) wenn sich jemand so detailliert und kompetent mit einem Thema auseinandersetzt ;).
Jan legt ein Entwickler-Ticket mit eurem erarbeiten Vorschlag an und wir werden es bewerten und ggf. einfließen lassen. Welche Version das dann sein wird, kann ich leider noch nicht vorhersagen.
Ja, Whissi, Du hast recht, es ist relativ einfach. Wir müssen aber auch immer die Updatemechanismen und Seiteneffeke prüfen. Das kann mitunter aufwändiger werden als es im ersten Moment scheint.
Jedenfalls Danke für Euer Engagement!
LG
Mathias
Hallo zusammen,
wie hier bereits beschrieben, hab ich ein Ticket diesbezüglich aufgenommen.
Grüße,
Jan