HOSTBLOGGER.de

Auf einem Server mit 1 oder 2 GB braucht man kein 64bit, 32bit ist etwas effektiver (ob das merklich was ausmacht, ist die andere Frage).

Wer rein 32-bittige proprietäre Software einsetzt (hatte das selbst im Bereich Geo/Kartenapplikation), hat auf einem 64-bit-System Spass mit Libraries. Ging aber. Ob für die verschwindend kleine Zahl an potentiellen Kunden, die es brauchen, die dauerhafte Pflege des Systems lohnt, ist natürlich eine andere Frage. Für Bestands-Maschinen wäre es auf jeden Fall schlau, wenigstens die Debian (etc.)-Mirrors mal auf Nutzung abzuklappern und vielleicht noch ein Weilchen zu halten.

Für die Installation neuer Maschinen: Abschalten.

64bit hat nur unter Windows was mit RAM zu tun... die Adressleitungen waren schon beim guten alten Pentium Pro 56 Bit breit!

64bit ist nebenbei definitiv schneller, schon allein wegen wegen der größeren Anzahl an GPR.

So einfach ist das leider auch nicht.

Ja, 64bit-Pointer sind größer als 32bit. Keine Frage.
Andererseits kann der Prozessor im 64bit-Modus auch breitere und vor allem mehr Register nutzen, so dass seltener auf Cache oder gar RAM zugegriffen werden muss. Von weiteren Befehlen ganz zu schweigen.

Aus diesem Grund gab es die Idee, einen "x32"-Mode im Linux-Kernel zu nutzen - also künstlich auf 32bit beschränkte Pointer und der Rest im 64bit-Modus. Wie weit das gediehen ist weiss ich aber nicht. (siehe z.B. http://www.heise.de/open/artikel/Kernel-Log-x32-ABI-umgeht-Nachteile-des-64-Bit-Betriebs-1341264.html)

Zum Thema des Threads: 64bit only sollte heute kein Problem mehr sein. Wenn die Kunden 32bit wollen können sie ja prinzipiell selber installieren (oder?). Die entsprechenden Repositories etc. könnt ihr ja prinzipiell weiter vorhalten, das macht kaum Aufwand - im Gegensatz zu gepflegten Installtionsimages (wie ich vermute).

Das Problem mit den von 4GB sind nur 3,5GB nutzbar ist eher die Schuld auf dem Motherboard zu suchen. Das wird nicht vom Betriebssystem verwurstet wie oft gemeint.

Weg damit, denke der Pflege-Aufwand ist die Häufigkeit der Einsätze nicht mehr wert.

Wer dann wirklich, aufgrund älterer Software, 32bit Systeme braucht, kann sie sich ja dann selber über das Rescuesystem installieren. Denke aber, dass das nur sehr wenige sein werden

Braucht es heute noch 32bit?
============================
Ja!

Ich mache es beispielsweise rein vom Hauptspeicher abhängig, ob ich ein 32bit oder 64bit Betriebssystem installiere. Dabei gilt die Faustregel: Alles 32bit, ansonsten 64bit.

Praxisbeispiel:
Gegeben ist ein alter Manitu-Server mit AMD X2 Prozessor (64bit-fähig) aber nur 2 GB Hauptspeicher. Wenn ich hier 1,5 GB RAM rein für die Anwendungen reservieren würde, könnte ich bei meiner PHP-Konfiguration mit einem 32bit Betriebssystem ~75 Worker fahren. Bei gleicher Konfiguration, aber mit 64bit Betriebssystem (somit auch 64bit Software) sind es nur noch ~37.
Das Beispiel kann man so eigentlich an jeder Software durchspielen (gerade bei Anwendungen mit Workern tritt das Problem umso stärker auf).

Der Geschwindigkeitsvorteil den ein 64bit Betriebssytem auf einem 64bit-fähigen Prozessor gegenüber einem 32bit Betriebssystem auf einem 64bit-fähigen Prozessor bietet, kann diesen Nachteil nicht annähernd kompensieren.


Brauche ich 32bit Installations-Images?
=======================================
Nein. Ich brauche allerdings auch keine 64bit Installations-Images, da ich immer manuell installiere.

Ich sehe in der Praxis bei der Bereitstellung aber keinen Unterschied: Wenn der Prozess zur Erstellung eines 64bit Images steht, sollte sich dieser ohne großen Aufwand auch auf 32bit übertragen lassen und umgekehrt.

Wenn es aktuell Aufwand bedeutet, ist evtl. der Prozesz falsch...


Brauche ich eine 32bit Rettungsumgebung?
========================================
Definitiv JA! Ohne 32bit Umgebung, kann man ein 32bit System weder installieren noch reparieren. Somit braucht es definitiv eine funktionierende 32bit Rettungsumgebung.

Aber siehe oben:
Wenn man einmal einen ordentlichen Prozess zur Erstellung eines Images hat, sollte jede weitere Architektur ohne weiteren Aufwand möglich sein.


P.s. Wenn ihr nicht selber einen Prozess entwickeln wollt, schaut euch doch einmal bei http://live.debian.net/ um. Aber auch OpenSUSE oder Gentoo bieten entsprechende Lösungen an, um ganz bequem sich etwas individuell bauen zu lassen.

Ich persönlich würde allerdings einfach die aktuelle SysRescCD bereitstellen. Gibt es auch für NetBoot (also PXE was ihr nutzt). Die wird von extern gepflegt, die Qualität stimmt und der Kernel sollte auch überall starten. Es müsste lediglich ein Start-Skript hinterlegt werden, welches das Root-Kennwort setzt.

Geh hin und baue PHP in 32bit und 64bit fest mit

--with-openssl' '--with-zlib' '--enable-bcmath' '--with-bz2' '--enable-calendar' '--with-curl' '--with-curlwrappers' '--enable-exif' '--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-xpm-dir=/usr' '--with-freetype-dir=/usr/bin' '--enable-gd-native-ttf' '--with-gettext' '--with-mhash' '--with-imap' '--with-kerberos' '--with-imap-ssl' '--enable-intl' '--enable-mbstring' '--with-mcrypt' '--with-mysql=mysqlnd' '--with-mysqli=mysqlnd' '--with-pdo-mysql=mysqlnd' '--enable-soap' '--enable-sockets' '--enable-sysvmsg' '--enable-sysvshm' '--enable-sysvsem' '--with-tidy' '--enable-wddx' '--enable-zip' '--with-pear' '--with-zend-vm=GOTO' '--enable-zend-multibyte'

Jetzt gehe hin und lasse bspw. phpinfo() laufen und messe den Speicherverbrauch des dafür notwendigen PHP-Prozesses. Sei es nur mit top/ps oder auch mit PHP-Funktionen.

Du wirst feststellen, dass PHP x64 auf einem x64 System einfach von sich aus mehr Speicher verbraucht, als PHP x86 auf einem x86 System.

x64 verbraucht nicht genau doppelt soviel Speicher, aber halt fast. Und das merkt man schon. Weiter geht es in einer Antwort auf #7.2

> Die worker selber verbrauchen genau einmal Speicher

Genau darum geht es doch:
Nimm eine php-fcgi Umgebung (bspw. php-fpm). Jeder der gestarteten Worker entspricht einer vollständigen PHP-Instanz. Der Speicher den eine Instanz benötigt, von diesem Speicherverbrauch rede ich. Und dieser Footprint ist bei einem x64 System mit x64 Software eben knapp doppelt so hoch, wie bei einem x86 System mit x86 Software. Das liegt einfach an x64 -- Stichwort Pointer, vereinfacht ausgedrückt sind alle Pointer auf x64 Systemen doppelt so groß

Ich spreche nicht von den Skripten. Zur Laufzeit steigt der Speicherverbrauch natürlich noch einmal - aber das ist abhängig von dem jeweiligen Skript.


Wir müssen auch gar nicht bei PHP bleiben:

Nehmen wir amavisd-new. Ich baue einen Mailserver. Der Mailserver soll X Mails parallel verarbeiten können. Also brauche ich mindestens x amavisd-new Worker. Auf einem x86 System kann ich einfach mehr Worker laufen lassen als auf einem x64 System bei gleichem Hauptspeicher.

Nehmen wir Ruby: Jede Ruby-Anwendung frisst auf einem x64 System doppelt soviel Speicher wie auf einem x86 System.

Nehmen wir JAVA: Starte eine Anwendung, welche die JRE verwendet, bspw. einen Jabber-Server. Der Footprint der JRE ist auf einem x64 System doppelt so groß wie auf einem x86 System.

Das ist ein Fakt. Leicht zu überprüfen. Somit würde ich mir bei Das erstellen der Images stellst Du dir leider zu einfach vor

Da unterschätzt du mich

Ich selber arbeite in einem universitären Betrieb wo wir viel mit PXE/Netboot machen. Bei über 2000 Clients kommen da schon diverse Konfigurationen zusammen.
Das ist alles nur eine Frage des Prozesses. Wenn man einmal ordentlich eine Lösung gebaut hat, stößt man später nur noch Skripte an und lehnt sich zurück. JA -- man muss einmal so eine Lösung bauen. Das kostet. Diese Investition macht sich aber ein Leben lang bezahlt (sofern man ordentlich entwickelt hat und nicht nach 2j, wenn man erweitern will feststellt, dass das nicht geht).

Ich stimme dir zu, dass auf der SysRescCD Dinge sind, die ihr nicht braucht. Streicht meinetwegen X und die verschiedenen Kernel-Versionen (ein Kernel pro Architektur wird reichen). Aber die Datenmenge ist doch bitte kein Problem? Die aktuelle SysRescCD ist knapp 400 MB groß. Das via PXE zu laden ist weiß Gott kein Problem. Bzw. ich weiß nicht wie ihr das macht, je nachdem kann es ein Problem sein... aber wenn man es "richtig" macht (nicht falsch verstehen), sollte es kein Problem sein. Ich denke da an PXE-Bootmenü via Syslinux. Über PXE lädt der Kernel. Im Startprozess verbindet sich das System dann via HTTP mit eurem Image-Server und lädt den Rest herunter. So machen wir das hier. Abersolut kein Thema. Selbst bei 100MBit sollte das System so keine 3 Minuten zum Start brauchen.
Nur als Anmerkung: Schau mal wie groß WinPE ist. Das ist überhaupt kein Problem.

Für die Installation:
Habt ihr euch da mal Chef, Puppet usw. angeschaut? Damit ziehen wir Räume mit 120 Clients unterschiedlicher Hardware in 20min hoch. Der Vorteil gegenüber einer Image-Installation: Man kann viel schneller reagieren, da die Systeme in Echtzeit arbeiten (eure nächste Server-Generation setzt auf EFI und >= 3 TB Festplatten. Ihr setzt auf GPT und syslinux. Ihr habt bereits die Master-Installation fertig und auch das Provision-Skript. Nun stolpert ihr über ein Problem in syslinux, was aber in syslinux-5.01 behoben wurde. Ihr passt also nur kurz das Setup-Skript an und könnt sofort den Testlauf starten. Kein langes Image erstellen... Auch erlaubt diese Lösung individuell zu reagieren (ihr habt Server mit einer speziellen RAID-Karte? Kein Problem. Einfach schnell ein Anweisung schreiben, welche sicherstellt, dass das entsprechende Modul auf den Kisten vorhanden ist und diesen Rechnern zuweisen).

zum Rescue-System:
Catalyst ist ja auch OK (wobei ich euch empfehle, einmal Metro anzuschauen). Was mich jedoch bei euch stört:

- Veraltete Software
- Kein Paketmanager
- Fehlende Kernelmodule (dm, Crypto)
- Kein syslog (JA! Auch im Rescue-Mode brauche ich den. Unzählig viele Programme geben via syslog Meldungen raus. Ohne syslog sehe ich die aber nicht.)

Hier habt ihr zwei Möglichkeiten:
Wenn ihr bei SRC-basierten Rescue-Images bleiben wollt, dann müsst ihr einfach öfters aktualisieren (oder alles mitliefern, dass der Kunde die Möglichkeit hat, selber Software via Paketmanager zu installieren).

Der Vorteil von Paket-basierten Rescue-Images ist: Ihr liefert meinetwegen irgendeine Stable-Version aus (sei es Debian, Ubuntu LTS, OpenSUSE...). Der Kunde kann jetzt aber auf Wunsch das Rescue-System aktualisieren. Das funktioniert zumindest bei euren Mitbewerbern recht gut (einfach kurz die /etc/apt/sources.list bearbeiten und aktualisieren). Ich persönlich finde das zwar immer nervig, im Gegensatz zu eurer Umgebung kann ich das aber immerhin tun. Gerade zu Zeiten wo man es mit 3 TB Platten und EFI zutun bekommt ist es toll auf ein Debian Testing (oder eben SysRescCD Image) zurückgreifen zu können, um so via gdisk usw. bequem zu arbeiten.

Aber was ich so herauslese ist, dass euer Kernproblem die fehlende Automatik ist. Euch fehlt ein Prozess (den wir eben haben, weswegen ich davon so einfach erzählen kann). Wenn ihr euch Sorgen über den Testaufwand macht, dann stimmt da etwas nicht. Ich muss heute automatisch testen können. Sonst kann ich nicht Schritt halten und falle zurück. Zu dem Prozess gehört also auch, dass ihr bspw. alle gängigen Server-Konfigurationen bei euch als Testgeräte stehen habt und automatisiert die neuen Images testen könnt. Glaubt mir, sobald ihr einmal so eine Umgebung habt, geht später alles andere leicht von der Hand. Das ist eine Investition die sich auszahlt.


> Nebenbei reicht es eben nicht nur das Passwort nach dem Laden zu setzen,
> Netzwerkkonfiguration, eine Singnalisierung, dass der Start erfolgt ist,
> usw., da hängt mehr dran als man auf den ersten Blick denkt.

Ähm? Wenn ihr die Kisten bei euch installiert, dann kennt ihr doch die MACs usw., weil ihr die Daten für eure restliche Konfiguration braucht. Somit lässt sich alles weitere doch bequem via PXE/DHCP regeln.

Bzgl. Kennwort und Rückmeldungen: Ja, auch hier braucht man eine Lösung. So machen wir es:

Wir haben einen Provision-Server (das kann Chef/Puppet sein, als auch einen eigenen Webservice). Wenn die Clients starten, kommt ein PXE-Loader (syslinux). Sofern nichts anliegt würden die Clients nach x Sekunden von der Platte starten. Liegt etwas an, bspw. wurde am Provision-Server der Client für den Rescue-Mode vorgesehen (analog zu eurem "In Rettungsmodus booten"), wird bspw. unser Rescue-Image gestartet. Die Netzwekkonfiguration erfolgt hier via DHCP.
Im Startprozess kontaktiert der Client dann unseren Provision-Server und fragt nach weiteren Aufgaben. Dazu gehört bspw. die Task "Root-Kennwort setzen", aber auch "sshd starten". Das sind im Prinzip alles nur Skripte. Das erste Skript fragt vereinfacht, welches Skript es ausführen soll. Es schaut dann nach, ob das Skript vorhanden ist, wenn nicht, versucht es das Skript aus dem Repository herunterzuladen. Im Erfolgsfall wird das Skript dann ausgeführt. Die Rückgabewerte der Skripte werden an den Provision-Server zurückgemeldet, wodurch dieser in der Lage ist den aktuellen Status anzuzeigen oder auf Ereignisse zu reagieren. Uns sind da eigentlich keine Grenzen gesetzt. Wir haben da nun schon ein schönes Skript-Framework zusammengebaut, ähnlich den OpenRC-Skripten (init-Skripten) von Gentoo... durch die SOA können wir an so gut wie jeder Stelle ansetzen und erweitern (aktuell bauen wir bspw. ein neues Webfrontend für den Provision-Server).

Aber auch hier gilt: Ihr habt so etwas wohl aktuell noch nicht. So etwas zu implementieren ist eine Investition. Da dies aber euer tägliches Geschäft ist, wie eben auch unseres, wird sich das schnell lohnen. Ganz wichtig ist einfach die Automatisierung. Unvorstellbar, wenn wir für die zig Konfigurationen manuell irgendetwas bauen würden. Alleine die Chance, dass man da einen Fehler macht... Kommt das einmal vor und hat Stunden für die Behebung gebraucht, wird mans ich beim nächsten Update scheuen ("Wirklich notwendig?" aka "Ich habe Angst"). Wenn der Vorgang aber automatisiert ist, dann ist der Fehler reproduzierbar und somit schnell gefunden.


> Natürlich sind die Unterschiede zwischen den 32 Bit und 64 Bit Versionen
> gering, aber Sie sind da und manchmal sehr subtil (aktuell den Fall
> gehabt, dass jeweils eine andere udev Version Stable und damit eine
> andere Syntax erforderte).

Das ist doch nicht wirklich ein Problem. Gerade bei SRC-based Distributionen: Erst einmal muss man wissen, wieso es sein kann, dass bei x86 v1.9 stable ist, während bei amd64 schon v2.0 stable ist. Oftmals liegt es daran, dass es keinen aktiven x86 Maintainer mehr gibt oder der amd64 Maintainer einfach aktiver ist. Bei Gentoo ignorieren wir bspw. "~". Somit sind wir bei der gleichen Version.
Natürlich: Das bedingt, dass wir den Bugtracker im Auge haben. Aber das ist ja irgendwie schon unsere Aufgabe, wenn wir selber etwas bauen

In den wenigen Fällen wo dann wirklich mal etwas unter einer Architektur nicht läuft, in der anderen schon, kommt es dann drauf an: Sofern es nur ein Minor-Update ist, kann man den Unterschied riskieren. Sobald sich aber wie von dir erwähnt die Syntax ändert oder man es einfach nicht riskieren will, wird auf die letzte in allen von uns unterstützten Architekturen zurückgegangen. Da stimme ich dir nämlich zu: Diese Fragmentation wäre ansonsten wirklich zuviel Aufwand. Aber bei Gentoo ist das ja absolut kein Problem. Noch eine Anmerkung: Wichtig ist, dass ihre diese Probleme dann auch im Bugtracker meldet. Nur so kann das Problem gelöst werden und die Gemeinschaft profitiert am Ende davon.


> Davon ab kann man mit einem 64 Bit System natürlich ein 32 Bit System reparieren

Rein technisch, ja.

In der Praxis würde ich keine 4 GB RAM erweitern. Dann würde ich auf amd64 wechseln

2) Ihr braucht einen Prozess. Es lebe die (kontrollierte) Automatik.

Das mit dem COW war falsch ausgedrückt, er kopiert die Speicherseiten erst, wenn sich auch tatsächlich was ändert, bei 100 Workern die das gleiche ausführen ist im optimal Fall nur der Speicher für das Skript mein seinen Parametern mehrmals im Speicher.

Was übrigens mit ein Grund ist, warum Worker nach einer gewissen Anzahl Request neu läft.