Debian Box - eine "einfache" Entscheidung

[icebreaker]

Hi,

also ich habe mit einen Rootserver bestellt. AMD Athlon64 3700+ mit 2 GB RAM. Nun stellt sich für mich die Frage - debian32 oder debian64? Ich habe einige Themen hier gelesen und habe festgestellt, dass debian64 eine blöde Entscheidung wäre ( da der Server "nur" einige Seiten hosten soll ).

Gibt es Troubles mit dem debian32 auf einer 64-bit Maschine?

Würdet ihr Etch für einen Produktionsserver empfehlen? Ich kann einfach nicht mit den "alten" Paketen aus Sarge leben :(

Ich freue mich auf Anregungen !

Gruß,

Ice

[mattiass]

also ich habe mit einen Rootserver bestellt. AMD Athlon64 3700+ mit 2 GB RAM. Nun stellt sich für mich die Frage - debian32 oder debian64? Ich habe einige Themen hier gelesen und habe festgestellt, dass debian64 eine blöde Entscheidung wäre ( da der Server "nur" einige Seiten hosten soll ).

Naja, bei 64Bit sind die Binaries größer (vernachlässigbar), die Einrichtung von 32Bit-Apps ist oft frickelig und die Performance von 64Bit ist nur bei einigen Anwendungen wie Video-Transkodierung wirklich schneller. Dass 64Bit langsamer als 32Bit ist, ist nur selten der Fall.

Gibt es Troubles mit dem debian32 auf einer 64-bit Maschine?

Nicht wenn der Kernel frisch genug ist.

Würdet ihr Etch für einen Produktionsserver empfehlen? Ich kann einfach nicht mit den "alten" Paketen aus Sarge leben :(

Ich freue mich auf Anregungen !

Wie wäre es mit Ubuntu LTS als Kompromiss? Ich habe gestern auch so einen Server bei einem fränkischen Provider fertig gemacht, bei dem die Partitionierung sowieso eine Neuinstallation nötig gemacht hat. Ich habe dort Ubuntu 6.06 einfach mit "debootstrap" installiert.

[daemotron]

Ich habe neulich das Thema "32 vs. 64 Bit" auch noch mal ein wenig gewälzt... Bislang bin ich hier im Rootforum immer wieder auf die Aussage gestoßen, 64 Bit mache erst ab 4 GB RAM wirklich Sinn (wegen Adressierung und so).

Wenn man sich seinen Kernel nun aber selbst baut, kann man diesen so konfigurieren, dass er bis zu 64 GB RAM über extended Memory adressieren kann - auch auf einem 32 Bit-System (AMD K7 von anno dazumal als Architektur). Ist das nun ein Fehler in dieser Kernel-Version (gentoo-hardened 2.6.17-r1, also kein vanilla), eine vermurkste Konfiguration oder kann ein 32 Bit OS tatsächlich 64GB RAM adressieren?

Mal angenommen das funktioniert wirklich, dann gibt es für 64 Bit nicht mehr viele Argumente - es sei denn, ich will einem einzelnen Prozess mehr als 2 GB RAM zuweisen (sinnvoll eventuell bei threaded laufenden Programmen) oder aber Numbercrunching im großen Stil betreiben (zusätzl. Prozessor-Register, größere Datenwort-Länge).

Nur um es noch mal in aller Deutlichkeit zu sagen: Damit wäre auch der Einsatz sog. "Enterprise Systeme" (was auch immer das heißt, aber gemeint sind große Hobel von Sun, IBM und Konsorten) teilweise in Frage gestellt (zumindest als Plattform für z. B. einen Apache-Prefork-basierten Applikationsserver) - Sinn würde ihr Einsatz doch nur bei DB-Servern o. ä. machen, wo ich die vielen RAM-Gigabytes wirklich einem einzelnen Prozess zur Verfügung stellen möchte...

[aquajo]

Wenn man sich seinen Kernel nun aber selbst baut, kann man diesen so konfigurieren, dass er bis zu 64 GB RAM über extended Memory adressieren kann - auch auf einem 32 Bit-System (AMD K7 von anno dazumal als Architektur). Ist das nun ein Fehler in dieser Kernel-Version (gentoo-hardened 2.6.17-r1, also kein vanilla), eine vermurkste Konfiguration oder kann ein 32 Bit OS tatsächlich 64GB RAM adressieren?

Ein 32 Bit Linux-Kernel kann >4Gb Adressieren, aber nur mit "üblen Hacks" die viel Performance kosten.

[daemotron]

Subsummieren wir also: in einem Datenwort von 32 Bit länge kann ich den Wertebereich 0 bis 4294967295 abbilden - oder anders gesprochen 4.294.967.296 Bytes adressieren (bei der Zuordnung von einer Adresse je Byte). Dies entspricht 4.194.304 KB oder 4.096 MB oder schlicht 4 GB.

Also wäre der "natürlich" adressierbare Speicherbereich 4 GB groß, darüber hinaus vorhandener Speicher würde auf einem 32-Bit System per Physical Address Extension (PAE) angesprochen, also mittels dreistufigem Paging. OK, also das, was Du als "üblen Hack" beschreibst... nachvollziehbar

Wozu existiert dann aber der 3GB/1GB-Modus?

If you are compiling a kernel which will never run on a machine with more than 1 Gigabyte total physical RAM, answer "off" here (default choice and suitable for most users). This will result in a "3GB/1GB" split: 3GB are mapped so that each process sees a 3GB virtual memory space and the remaining part of the 4GB virtual memory space is used by the kernel to permanently map as much physical memory as possible.

OK, das Prinzip habe ich verstanden - aber welche konkreten Vorteile ergeben sich gegenüber HIGHMEM4G=y? Es besagt doch lediglich, dass alle Speicheradressen ab 1.048.576 auf keinen Fall auf physikalisch vorhandenen Speicher zeigen können.