Apache wird nachgesagt ein eher behäbiger und vorallem speicherfressender Webserver zu sein. Das mag bei schlechter Konfiguration auch stimmen.

Ich selber betreibe Apache auf allen Webservern unter meiner Fuchtel und habe noch nie besondere Performanceprobleme bemerkt (ausser natürlich bei aufwendigen MySQL-Abfragen via PHP, aber das ist eine ganz andere Geschichte).

Zunächst sollte man sich über die Hardware, welche einem zur verfügung steht im Klaren sein. Das ist vor allem bei V-Servern nicht immer einfach, hier sollte man so kalkulieren, dass einem ein Drittel der Host-CPU-Kerne zur verfügung stehen.

Auf den meisten Apache2-Servern wird MPM-Prefork laufen, da die meisten Webserver mit allerlei Scriptsprachen (vor allem PHP) ausgestattet sind. Apache benutzt Forking (oder Threading) um mehrere Surfer gleichzeitig mit Internetseiten bedienen zu können, alle Anfragen die nicht sofort von einem “Worker” abgearbeiten werden können werden in eine Warteschlange gesteckt und bald möglichst bedient.

Folgendes ist ein Beispiel aus einem 12-Kern-System, die einzelnen Werte erkläre ich dann sofort.

<IfModule mpm_prefork_module>
    StartServers         12
    MinSpareServers      12
    MaxSpareServers      12
    MaxClients           24
    MaxRequestsPerChild  50
</IfModule>

StartServers sagt Apache wie viele Prozesse nach starten des Servers sofort verfügbar sein sollen.

MinSpareServers sagt Apache wie viele Prozesse mindestens immer zur freien verfügung stehen sollen.

MaxSpareServers sagt Apache wie viele Prozesse er höchstens im vorraus starten darf.

MaxClients sagt Apache wie viele Prozesse er höchstens insgesamt starten (MixSpareServers startet bei erreichen des Wertes auch keine neuen Prozesse mehr) darf.

MaxRequestsPerChild sagt Apache nach wievielen bedienten Anfragen ein Prozess beendet oder neu gestartet werden soll (je nach bedarf). Das schützt vorallem vor extremen Speicheranhäufungen der Apache-Prozesse.

Generell empfiehlt es sich im leerlauf für jeden CPU-Kern einen Prozess zu haben, so können im Beispiel schonmal 12 Surfer gleichzeitig bedient werden. Maximal darf Apache 24, also theoretisch zwei Prozesse für pro Kern starten, was auch Problemfrei funktioniert, da die wenigsten Anfragen wirklich Leistung benötigen. Bei einer 2 GHz-CPU kann man auf einem durchschnittlichen Webserver auf welchem PHP-Anwendungen laufen getrost bis zu fünf Prozesse pro Kern als Maximalwert angeben.

Bei HyperThreading CPUs muss man ein bisschen experimentieren und von den ganzen tollen HT-Kernen die man so hat in der Konfiguration ggf. einen oder zwei abziehen. Da habe ich leider keine Erfahrung.

Als letzten Tipp: Wenn Apache anfängt die Warteschlange zu benutzen steht das meistens auch im globalen Log von Apache. Wenn man einen solchen Eintrag findet nicht gleich in Panik geraten, sondern das System mal eine Runde beobachten. Sollte es sich wirklich um Prozessmangel handeln, addiert man die Kernzahl auf den MaxClients wert drauf und läd Apache neu.

Hoffe das gibt einigen eine Idee, eigene Erfahrungen dürfen sehr gerne in Kommentaren geteilt werden!

Das man Minecraft-Server via

screen -dmS meinserver java -jar minecraft-server.jar -Xmx1G

in den Hintergrund starten lassen, man dann via

screen -r meinserver

wieder in die Minecraft-Konsole gelangt und zuletzt mit dem Tastenkürzel Ctrl+A, D die Minecraft-Konsole wieder verlässt sollte ein alter Hut sein.

Ich möchte hier vorstellen, wie man einfache Befehle (zB für Backups) auch ausführen kann ohne in die Mc-Konsole wechseln zu müssen. Diese Variante funktioniert mit allen gängigen Minecraft-Servern, wie z.B. Bukkit.

Im laufe des Artikels wird ein Bash-Steuerscript erstellt, welches dazu dient Befehle direkt ausführen zu können und dann ein simples Backups-Script erstellt welches das Steuerscript nutzt.

Fangen wir also an, zunächst schreiben wir uns das Grundgerüst des Steuerscriptes:

#!/bin/bash
 
# der Dateiname der Server-Jar, darf auch ein absoluter Pfad sein
SERVER_NAME="minecraft_server.jar"
 
# der Name der Screen-Session die Erstellt und verwaltet wird
SCREEN_NAME="meinserver"
 
if [ $# -gt 0]; then
    case $1 in
    "start")
        ;;
    "stop")
        ;;
    "restart")
        ;;
    "save-off")
        ;;
    "save-on")
        ;;
    "save-all")
        ;;
    "say")
        ;;
    "--help")
        ;;
    esac;
else
    $0 --help;
fi;

Nun kann man schon grob erahnen wo das ganze hin führen wird. Wir werden in der Lage sein, den Server von der normalen Linux-Konsole aus zu stoppen, zu starten, neu zu starten, die Welt zu speichern und etwas als [SERVER] zu sagen. Des weiteren schreiben wir uns auch eine Hilfe, damit wir nicht vergessen wie das Script zu bedienen sein wird.

Zunächst schreiben wir uns eine Helfs-Funktion, welche einen Befehl ausführt:

mc_cmd() {
       screen -S $SCREEN_NAME -p 0 -X stuff "`printf "$*\r"`";
}

Die Bereiche Start, Stop und Restart werden um die folgenden Zeilen ergänzt:

        "start")
                echo -n "Starting minecraft... ";
                screen -dmS $SCREEN_NAME java -Xmx1536M -Xms64M -jar $SERVER_NAME && echo "OK";
                ;;
        "stop")
                say "Stoppe in 5 Sekunden.";
                sleep 5;
                echo -n "Stopping minecraft... ";
                mc_cmd stop && echo "OK";
                ;;
        "restart")
                $0 stop;
                sleep 5;
                $0 start;
                ;;

Zusätzlich bauen wir noch wrapper für save und say ein:

        "save-off")
                mc_cmd save-off && echo "save-oFF.";
                ;;
        "save-on")
                mc_cmd save-on && echo "save-oN.";
                ;;
        "save-all")
                mc_cmd save-all && echo "save-ALL.";
                ;;
        "say")
                say $2;
                ;;

Zum Schluss die Hilfe:

        "--help")
                echo "Usage: ./run.sh <Command> [<Options>]";
                echo "";
                echo "Available commands are:";
                echo "  start          Starts the server.";
                echo "  stop           Stops the server.";
                echo "  restart        Restarts the server.";
                echo "  save-off       Turns level saving off.";
                echo "  save-on        Turns level saving on.";
                echo "  save-all       Saves the level.";
                echo "  say <msg>      Prints <msg> to the game chat.";
                ;;

Nun das Backup-Script, welche den Ordner “world” in einen Tarball mit Timestamp packt. Das Script von oben wird unter ./run.sh aufgerufen.

#!/bin/bash
./run.sh say "[BACKUP] Starte. Speichere Welt...";
./run.sh save-off;
./run.sh save-all;
cp -R world bak_tmp && ./run.sh say "[BACKUP] Gespeichert, komprimiere ...";
./run.sh save-on;
nice -n +5 tar -cf - bak_tmp | nice -n +5 gzip -9 - > world-$(date "+%d-%m-%Y_%H-%M").tar.gz;
rm -R bak_tmp;
./run.sh say "[BACKUP] Alles Fertig.";

Nicht vergessen, beiden Scripten ausführungsrechte zu geben (via chmod u+x scriptname.sh). Dann Spaß beim Minecraft-Fernsteuern haben!

Wer rausfindet, wie man prüft ob eine Screen-Sitzung noch läuft darf das gerne in die Kommentare schreiben!

Die in Dell-Servern standardmäßig verbauten PERC RAID-Controller bieten umfangreiche Konfigurations- und RAID-Möglichkeiten. Bei den Standardeinstellungen von neuen RAID-Verbunden wurde allerdings die Failsafe-Variante gewählt, was nicht nur unperformant ist sondern auch arge Probleme auf Servern mit hoher Festplattenaktivität mit sich ziehen kann.

Der Controller bietet die Möglichkeit einen Lese- sowie Schreib-Cache zu aktivieren. Der Lesecache ist standardmäßig aktiviert, jedoch nicht der Schreibcache, was dazu führt, dass Schreibzugriffe das System verlangsamen oder sogar aufhalten. Beim Versuch den Schreibcache im BIOS zu aktivieren, versucht eine Warnmeldung vor möglichem Dateiverlust einem dies wieder aus zu reden. Ganz unrecht hat die Warnmeldung nicht, in abartig seltenen Fällen (z.B. bei einem Stromausfall) gehen Daten, welche sich noch im Schreibcache befanden, verloren (da die Daten ja noch im Cache und nicht auf der Festplatte waren). Da das aber ein gut kalkulierbares Risiko ist (zumindest in europäischen Rechenzentren) und man sowieso ständig Backups auf andere Server zieht, kann man den Cache getrost aktivieren.

Wer schon eine bestehende RAID-Konfiguration hat und nicht ins BIOS-Menü möchte, kann den Cache auch nachträglich via OpenManage aktivieren. Der Befehl über das Kommandozeilentool lautet:

omconfig storage vdisk action=changepolicy controller=0 vdisk=0 diskcachepolicy=enabled
# die nummern für controller= und vdisk= entsprechend anpassen
# der befehl setzt alle policy-optionen auf caching (lesen und schreiben)

Weitere Informationen finden sich im OpenManage Manual unter http://support.dell.com/support/edocs/software/svradmin/1.9/en/stormgmt/cli.html#1093196

Viel Erfolg, und wie immer eigene Erfahrungen und Infos in die Kommentare!

Mit Dell-Servern wird i.d.R. immer zumindest der so genannte iDRAC Express (integrated Dell Remote Access Controller), zuletzt in der Version 6, mit ausgeliefert. Dieses System erlaubt dem Administrator den Server von zu Hause, oder einem anderen Server aus, herunter zu fahren, zu starten und zu resetten (Die Enterprise-Version hat noch ein paar mehr Features, dieser Artikel behandelt aber die Express-Variante). Bei der Einrichtung gibt es allerdings einige Fallen in die man leicht stolpern kann. Ich versuche hier kein Schritt-für-Schritt Tutorial an zu bieten, sondern viel mehr Informationen die dem Manual fehlen.

Falle 1

Der iDRAC soll auf einem anderen Netzwerkport (hier ist die physische Buchse gemeint) als dem ersten betrieben werden.

Das ist nicht möglich. Der Controller möchte unbedingt, sofern angeschlossen, das erste Interface verwenden. Dies ist meist das mit der niedrigsten Nummer gekennzeichnete on-board Interface.

Mein Tipp: iDRAC von vorn herein einplanen und den ersten Port frei lassen, sofern iDRAC irgendwann mal verwendet werden soll.

Falle 2

Der iDRAC soll auf der selben IP wie der Server selbst (oder andere Anwendungen des Servers) erreichbar sein.

Das geht grundsätzlich, allerdings mit einigen drastischen Einschränkungen. Der vom iDRAC6 Express belegte Netzwerkport kann auch bei aktiviertem (korrekt Konfiguriertem) iDRAC noch vom Betriebssystem aus verwendet werden, allerdings klaut sich der Remote Controller die Ports 22, 80 und 443. Also nicht erschrecken, wenn auf der einzigen öffentlichen IP auf einmal der iDRAC anstatt der Webserver dran geht. Nicht mehr lustig wird das ganze allerdings dann, wenn man sich aus SSH (Port 22) aussperrt und man ins Rechenzentrum fahren darf um die iDRAC-Konfiguration zu ändern.

Mein Tipp: Wenn man einen weiteren Server im selben Rechenzentrum hat, die beiden über Crossover mit ein ander verbinden. Nun kann man das iDRAC vom anderen Server aus via SSH ansprechen. Wenn man keine andere Maschine vor Ort hat und man den iDRAC gerne vom Arbeitsplatz (oder von zu Hause) aus bedienen möchte, bleibt einem wohl oder übel nichts anderes übrig, als eine zweite IP und zweite Ethernet-Verbindung zu mieten (was u.U. teuer sein kann).

Falle 3

Man glaubt, die dem iDRAC zugewiesene IP stellt sich automatisch ein.

Das ist nicht der Fall. Die IP, welche iDRAC benutzen soll, muss genau so auch im Betriebssystem eingerichtet werden. Das Betriebssystem ist für die Verwaltung des Interfaces zuständig, iDRAC ’schmarotzt’ lediglich. Achtung: Nachdem das Betriebssystem herunter gefahren wurde, läuft iDRAC auf dem Interface unter der eingestellten IP weiter, man kann den Server also wieder Remote-Booten, wenn man das Interface allerdings im OS mit einer anderen IP versieht funktioniert das ganze nicht mehr!


Beispielsetup mit zwei Servern

Wie oben beschrieben, werden beide Server möglichst im gleichen oder nebeneinander stehenden Racks verbaut und via Crossover verbunden. Hierbei ist wichtig, dass der iDRAC-Server auf NIC1 angeschlossen wird. Sollte der andere Server ebenfalls über iDRAC verfügen, sollte das Kabel dort nicht auf NIC1 gelegt werden.

Danach gibt man den Servern statische IP-Adressen auf den Ports (z.B. 192.168.1.1 und .2) und wiederholt diese Einstellung im iDRAC.

Beispielsetup mit einem Server

Bei dieser Variante kommt man ums Mieten einer zweiten IP, sowie eines zweiten Ethernet-Ports nicht drum herum.  Man richtet wie bei der Server-Server variante die zweite IP auf NIC1 ein und stellt auch den iDRAC darauf ein. Bonus dieser Variante ist allerdings, dass man nun auch das auf HTTPS laufende Web-Panel des iDRAC nutzen kann.

Tipp

Zum einstellen des iDRAC zur laufzeit (also ohne ins BIOS/POST-Menü zu müssen), empfiehlen sich die von Dell angebotenen OpenManage-Softwarepakete (unter Debian “srvadmin”), über welche sowohl über eine Kommandozeilen-Tool als auch eine Weboberfläche diverse Einstellungen und Überwachungen vorgenommen werden können. omreport chassis remoteaccess zeigt auf der Konsole die aktuellen Einstellungen des iDRAC.

Viel Erfolg und wie immer, eigene Erfahrungen bitte in den Kommentaren teilen!

Habe heute ein einfaches script geschrieben, welches laufende Prozesse auf Linux-Systemen anhand von Suchmustern mit einer neuen Priorität versieht. Das ganze ist vorallem dann nützlich wenn man Prozessen eine  Priorität zuweisen will, welche sich nicht ohne weiteres direkt mit einer speziellen Priorität starten lassen.

Folgenden code einfach in eine neue Datei “reniced” speichern:

#!/bin/sh
pattern="convert|mogrify|bzip2|pigz|gzip";
while [ true ]; do
 for arg in `ps -A | egrep -e $pattern | grep -v grep | cut -c 1-5`; 
  do
  echo "Reniceing $arg";
  renice -n +5 $arg;
 done;
 sleep 1;
done;

Einfach per [sudo] ./reniced > reniced.log & starten und alle im Suchmuster per “|” separierten Prozesse bekommen die neue Priorität aus Zeile 7.

Der Schlaf-Wert in Zeile 9 kann ebenfalls je nach bedarf justiert werden, je nach dem wie schnell man auf neue zutreffende Prozesse reagieren möchte. Wer’s ganz schnell haben will kann auch usleep verwenden.

Nachdem man erfolgreich Debian oder Ubuntu auf seinem Server installiert hat, möchte man womöglich den RAID Status seines Adaptec RAID Controllers auslesen. Nunja, Adaptec supportet nur RHEL, Fedora und SuSE, also muss man ein wenig tricksen.

Die folgenden Kommandos sind der Weg zum Erfolg!

sudo su - # wir wollen schnell arbeiten, unter Debain einfach nur su -
apt-get update
apt-get install alien libstdc++5 -y
wget http://download.adaptec.com/raid/storage_manager/asm_linux_x64_v5_20_17414.rpm
alien --scripts asm_linux_x64_v5_20_17414.rpm
 
# <ARCH> = Systemarchitektur, zB amd64, TAB hilft ;)
dpkg -i storman_5.20-1_<ARCH>.deb 
 
# arcconf binary in ein normales Verzeichnis linken
ln -s /usr/StorMan/arcconf /usr/bin/arcconf

Wenn alles erfolgreich passiert ist, kann man daten wie folgt auslesen:

arcconf GETCONFIG 1

Gibt eine ausführliche übersicht über die verbauten Komponenten und deren Status aus.

arcconf GETSTATUS 1

Gibt eine rückmeldung über aktuelle vorgänge des Festplattenverbundes und deren fortschritt (z.B.: Rebuild 50%)

Den mit installierten StorMan kann man auf servern wegen der fehlenden Desktopumgebung leider nicht verwenden. (Bei einer Desktopumgebung via VNC (o.ä.) wäre dies allerdings möglich.)

Viel erfolg!

Schon seit etwas mehr als einem Jahr habe ich jetzt meinen Server bei Netcup gemietet und bin mit den Leistungen überaus zufrieden.

Hier ein paar Gutscheincodes für Sparfüchse, mit denen man bei Netcup ein wenig Geld sparen kann

Wenn ihr merkt das keine mehr gültig sind, schreibt n Kommi drunter ich poste dann neue.

Wenn du auf deinem Debian (vielleicht auch Verwandte) System neulich postfix geupdated hast, postfix mit MySQL verwendest, und dich nun wunderst warum du keine E-Mails mehr bekommst, gibt’s hier die Lösung!

1. In deiner /var/log/mail.warn und /var/log/mail.err tauchen sachen auf wie

postfix/trivial-rewrite[23095]: warning: connect
to mysql server localhost:
Can't connect to local MySQL server through socket
'/var/run/mysqld/mysqld.sock'

2. Dein E-Mail client Spuckt meldungen aus wie

3. Dein ganzes Serversystem kommt dir ungewöhnlich langsam vor.

Hier die Ursache:

Das Update hat das Init-Script zum starten von Postfix ausgetauscht und nach beenden des Updates ausgeführt. Im neuen Init-Script fehlt jedoch der Teil der die Socket-Datei von MySQL in die ChRoot-Umgebung von Postfix linkt. Das Resultat daraus ist, das Postfix sich nicht mehr mit dem MySQL Server verbinden kann, weil in der ChRoot-Umgebung eine alte oder garkeine Socket-Datei ist.

Um diesen schwerwiegenden Fehler zu beheben fügt man einfach die nachfolgende Zeilen in /etc/init.d/postfix zwischen

case "$1" in
    start)
        log_daemon_msg "Starting Postfix Mail Transport Agent" postfix
        RUNNING=$(running)
        if [ -n "$RUNNING" ]; then
            log_end_msg 0
        else

und

# see if anything is running chrooted.
            NEED_CHROOT=$(awk '/^[0-9a-z]/ && ($5 ~ "[-yY]") { print "y"; exit}' /etc/postfix/master.cf)

ein.
Hier nun die entscheidenden Zeilen zum erfolg:

# CHANGE FOR USE WITH MYSQL
 
        if [ -e /var/spool/postfix/var/run/mysqld/mysqld.sock ]; then
            rm /var/spool/postfix/var/run/mysqld/mysqld.sock;
        fi
 
        mkdir -p /var/spool/postfix/var/run/mysqld
        chown mysql /var/spool/postfix/var/run/mysqld
        ln /var/run/mysqld/mysqld.sock /var/spool/postfix/var/run/mysqld/mysqld.sock
 
 
        # END OF CHANGE FOR USE WITH MYSQL

Wenn ihr dann versucht wieder E-Mail abzurufen, nicht vergessen ggf. den courier-authdeamon wieder anzuschmeissen, sonst klappts auch nicht.

Appendix:
Es kann auch vorkommen das sich durch den Updatevorgang euer MySQL aufhängt, welches ihr dann per kill-Kommando getötet habt. Achtung! Einige hatten danach beschädigte Tabellen, diese sind zu löschen falls sie nicht repariert werden können! Ist schade und doof, aber es geht nicht anders. Lasst ihr diese Tabellen beschädigt wird sich euer MySQL bei jedem zugriff auf diese Tabellen aufhängen. Sucht als erstes bei den Mailtabellen und danach nach häufigkeit der Verwendung der Tabellen/Datenbanken.

Viel Glück!