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!

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!

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!

So, nicht viel geschwafel, sondern direkt los legen. Zuerst importiert man die Basisklassen:

dojo.require("dijit._Widget");
dojo.require("dijit._Templated");

dijit._Widget ist die Basisklasse für Dijits generell und dijit._Templated ist ein sehr nützlicher Dijit-Zusatz zur Markup-Verwaltung.

Danach erstellt man seine Klasse mittels dojo.declare, wobei wir uns der zuvor geladenen “Mix-Ins” bedienen. In die hinteren geschweiften Klammern kommt gleich unser eigentlicher Code.

dojo.declare("my.widget", [ dijit._Widget, dijit._Templated ], {});

In dem Beispiel hier werden wir einfach “Hallo Welt” ausgeben, um zu verstehen wie Dijits aufgebaut sind. Dazu schreiben wir uns erst ein bisschen Markup (HTML) in die Code-Klammern:

{
    templateString: "<div data-dojo-attach-point='ausgabeDiv'></div>",
    postCreate: function () {}
}

Die Namen, die man Elementen via data-dojo-attach-point gibt, lassen sich nach postCreate als Eigenschaften in this verwenden. postCreate ist also so zu sagen der Konstruktor.

Dennoch schreiben wir uns erst eine Funktion, welche “Hallo Welt” in unser Div schreiben soll:

    schreibHalloWelt: function ()
    {
        this.ausgabeDiv.innerHTML = "Hallo Welt!";
    }

Dann rufen wir das ganze im postCreate einfach auf:

this.schreibHalloWelt();

Sodass der gesamte Code am Ende so aussieht:

dojo.require("dijit._Widget");
dojo.require("dijit._Templated");
dojo.declare("my.widget", [ dijit._Widget, dijit._Templated ], {
    templateString: "<div data-dojo-attach-point='ausgabeDiv'></div>",
 
    postCreate: function () 
    {
        this.schreibHalloWelt();
    },
 
    schreibHalloWelt: function ()
    {
        this.ausgabeDiv.innerHTML = "Hallo Welt!";
    }
});

Ein solches Dijit erstellt man später ganz normal durch den Namen, den man Ihm gegeben hat, in HTML z.B. so:

<div data-dojo-type="my.widget" data-dojo-props=""></div>

Über die data-dojo-props lassen sich Eigenschaften der Klasse ändern, da in diesem Beispiel aber keine Eigenschaften vorhanden sind, klappt das hier auch nicht.

Viel Erfolg, und eigene Erfahrungen und Infos gerne in den Kommentaren schreiben!

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!

Diese Klickmaschine ruft jede Minute die angegebene Webseiten-URL auf um mögliche Besucherzähler zu erhöhen. Dabei werden Besucherzähler-Schutzmechanismen jedoch nicht umgangen.

Das Programm benötigt das .NET Framework Version 4.

DOWNLOAD Version 0.1

Eine ausführliche Liste aller Anweisungen und Bedinungen liegt dem Paket als “referenz.txt” bei.

Viel Spaß beim “programmieren” (falls man das bei Karol so nennen kann).

DOWNLOAD Version 0.1

Das Original Quandary (in der Version 4.2, auch 1.8 ready) gibt es hier, den Download unterm Bild.

» DOWNLOAD «

Dazu entschlossen habe ich mich vorallem wegen der vielen kleinen Verbesserungen die mit Froxlor hinzu kommen, von den großen Neuerungen wie Unterstützung für zusätzliche PHP-Module mache ich keinen Gebrauch.

Nun zum Upgrade sei gesagt, dass die aktuelle Version von Froxlor (0.9.x) vollständig abwärtskompatibel zu den letzten SysCP-Versionen ist. Wer also eine aktuelle SysCP-Installation hat, dürfte keine Probleme mit dem Upgrade bekommen. Wer sich unsicher ist, kann mit mysqldump ein backup der SysCP-Datenbank anlegen.

Zuerst wird die aktuelle Froxlor-Version als Tarball heruntergeladen (ein Upgrade wird vom Repository aus wahrscheinlich nicht funktionieren) und in das Verzeichnis in dem SysCP liegt entpackt, sodass man hinterher einen syscp- und einen froxlor-Ordner hat.

cd /var/www # oder wo auch immer
wget http://files.froxlor.org/releases/froxlor-latest.tar.gz
tar -xf froxlor-latest.tar.gz

Danach wird die alte Konfigurationsdatei von SysCP nach Froxlor kopiert. Dadurch wird das Froxlor-Setup umgangen und die meisten Einstellungen werden übernommen, um die restlichen kümmern wir uns später. Auch benennen wir den SysCP-Ordner um, und linken auf Froxlor, damit alte Browser-Bookmarks auf das neue System zeigen.

cp syscp/lib/userdata.inc.php froxlor/lib/userdata.inc.php
mv syscp syscp_old
ln -s froxlor syscp

Danach besucht man seine neue Installation unter http://SERVER_IP/froxlor/ oder eben wie zuvor im Unterordner /syscp/. Froxlor weist einen darauf hin, dass sich ein Administrator einloggen muss um das Upgrade ab zu schließen, also loggt man sich mit einem Administrator-Account ein. Die Upgrade-Konfiguration sollte man sorgfältig lesen und auswählen was man benötigt. Zum Beispiel können beim aktivieren der Domain-Wildcards ungewollte Nebeneffekte auftreten.

Abschließend wird in /etc/cron.d/ der SysCP-Cronjob gelöscht oder deaktiviert und der Froxlor-Cronjob, vorzugsweise in der Datei froxlor, wie folgt eingetragen.

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
*/5 * * * *     root    /usr/bin/php5 -q /var/www/froxlor/scripts/froxlor_master_cronjob.php

Dann noch den CRON-Dienst neustarten, damit die Änderungen auch angenommen werden.

/etc/init.d/cron restart # bei SysVInit (sollte immer funktionieren)
service cron restart # bei Upstart (ab Debian Squeeze oder Ubuntu 10)

Dann ist man auch schon fertig.

Viel Erfolg!

In dieser Version gibt es das neue “Process CPU”-Meter, welches lediglich die vom Gastsystem produzierte CPU-Durchschnittsauslastung anzeigt. Zeigt das Meter also 100% an, so benützt der eigene VServer die gesamte verfügbare Rechenleistung.

htop-lvs.tar.gz

Hoster, welche virtuelle Server auf basis von Linux-VServer anbieten, sind z.B. netcup.

Den Sourcecode gibt’s unter svn://doenemeier.de/ahtop/branch/htop-lvs/ .

Viel Spaß!