Heute morgen kam endlich der langersehnte Speicher für unseren Icinga-Server. Die OpenVZ-VM hat jetzt 16GB RAM und 4GB Swap.
Seit diesem Zeitpunkt haben wir auch die Option use_large_installation_tweaks auf 1 gesetzt. Hatten wir vorher durchschnittliche Ausführungszeiten von 120 – 150 Sekunden konnten wir das mit 8GB mehr Speicher und der Option auf ca. 7 Sekunden bei den Services und 2 Sekunden bei den Hosts minimieren. Der Server wuppt jetzt wie Hölle:

# LARGE INSTALLATION TWEAKS OPTION
# This option determines whether or not Icinga will take some shortcuts
# which can save on memory and CPU usage in large Icinga installations.
# Read the documentation for more information on the benefits/tradeoffs
# of enabling this option.
# Values: 1 - Enabled tweaks
#         0 - Disable tweaks (default)
 
use_large_installation_tweaks=1

Interessant sind auch die Munin-Graphen dazu:

Beim Root-System handelt es sich um einen HP DL-380 mit jetzt 36GB RAM (vorher 12GB) und 2 Intel X5550 Quad-Cores mit 2.67GHz und HT. Für die OpenVZ-VM sind 16GB und alle 16 virtuellen Prozessoren reserviert.

Der Peak bei I/O-Waits heute morgen ist dem Neustart des Servers geschuldet. Die etwas höhere I/O-Wait-Last unter Tags verträgt der Server übrigens sehr gut. Im Root-System stecken zwei, als RAID-1 konfigurierte, 2,5″ 146GB-SAS-Festplatten mit 15,000 Umdrehungen.

Um die I/O-Last etwas zu senken, haben wir ein paar Temp-FS eingerichtet. Zum einen die in der Icinga-Dokumentation (http://docs.icinga.org/latest/de/tuning.html) beschriebenen Dinge, zum anderen für temporäre Checkergebnisse wie z.B. für check_cisco_snmp

...
none on /usr/local/icinga/var/tmpfs type tmpfs (rw,relatime,size=131072k,nr_inodes=1316970)
none on /usr/local/icinga/var/spool/checkresults type tmpfs (rw,relatime,size=524288k,nr_inodes=1316970)
none on /usr/local/icinga/var/spool/.BitPerSec type tmpfs (rw,relatime,size=131072k,nr_inodes=1316970)
none on /usr/local/icinga/var/spool/.ifErrors type tmpfs (rw,relatime,size=262144k,nr_inodes=1316970)
...