Ein 64-Bit-Betriebssystem bringt per se Vorteile durch den großen adressierbaren Speicherbereich. Mit 32 Bit breiten Adressregistern ist ohne komplexes Segment-Offset-Management bei maximal vier GByte Arbeitsspeicher Schluss. Diese Grenze ist im 64-Bit-Betrieb kein Thema mehr. Und gerade im professionellen Bereich wird schnell mehr Arbeitsspeicher benötigt.
Entsprechend bieten Linux-Distributoren wie Novell SUSE oder Red Hat ihre Betriebssysteme in 64-Bit-Versionen an. Auch an 64-Bit-Anwendungen mangelt es nicht, besonders speicherhungrige Datenbanken sind im Angebot.
Neben dem Vorteil des großen Speicherraums bleibt natürlich die Frage nach der Performance von 64-Bit-Anwendungen. Die Prozessoren bieten im 64-Bit-Betrieb jedenfalls breitere Datenregister als bei 32 Bit. Pro Taktzyklus lässt sich somit die doppelte Datenmenge verarbeiten. Das Ganze hat aber einen Haken, der die Leistung auch nach unten drücken kann: Adresszeiger und native Datentypen wie Integer sind nun 64 Bit breit, statt 32 Bit. Sie belegen somit doppelt so viel Speicher - effektiv finden dadurch nur noch halb so viele Daten im schnellen Prozessor-Cache Platz.
Dafür erhöht sich bei CPUs wie dem Opteron oder Xeon im 64-Bit-Betrieb die Anzahl der allgemeinen Register von 8 auf 16. Zumindest dies steigert bei angepassten Programmen auf jeden Fall die Geschwindigkeit.
tecCHANNEL hat Linux in der 32- und 64-Bit-Version mit entsprechend angepassten 32- und 64-Bit-Applikationen getestet. Wir zeigen, ob im professionellen Einsatz wie mit Datenbanken 64-Bit-Versionen Performance-Vorteile ermöglichen.
Benchmark-Vorbetrachtung
Bei den Benchmarks unter Linux setzten wir auf Fedora Core 3 in der 32- und 64-Bit-Version. Als Testsystem kam ein Intel-Server mit zwei Xeon 3,60 GHz "Nocona" zum Einsatz. Die Prozessoren ermöglichen durch EM64T den 64-Bit-Betrieb. Den CPUs stand über den E7520-Chipsatz 4 GByte Dual-Channel-DDR2-400-Speicher zur Verfügung.
Das Testszenario musste sich sowohl Standard-Benchmarks als auch Anwendungen aus dem Alltag stellen. Hierbei kamen Linpack 2.1.2, dbench 3.03, SQL-Bench aus der MySQL-Suite und die Zeitmessung einer Kernel-Kompilierung zum Einsatz. Bei allen Ergebnissen handelt es sich um Durchschnittswerte. Mindestens fünf Läufe waren pro Benchmark angesetzt.
MySQL
MySQL liefert seine eigene Benchmark Suite. SQL-Bench stresst dabei mit einer Vielzahl an Operationen die Open-Source-Datenbank. Unterschiedliche Datenmanipulationen aus insert, update, delete sowie Zugriffsmessungen via select in Verbindung mit count und distinct laufen gegen die Datenbank. Verbindungsaufbau, Tabellen anlegen, löschen und verändern sind ebenfalls enthalten.
Zum Einsatz kam die in Fedora Core 3 enthaltene MySQL 3.23.58 ohne weitere Veränderungen oder Tunings. Da einige Ergebnisse stark schwankten, führten wir den Datenbank-Benchmark mit jeweils zehn Läufen durch. Beim insert_key (100.000) waren die stärksten Abweichungen von Maximal- und Minimalwerten zu sehen. 32 Bit hatte hier ein Minimum von 99 Sekunden, und das Maximum lag bei 179 Sekunden. Das 64-Bit-System sieht ähnlich durchwachsen aus: 87 Sekunden als schnellster und 167 Sekunden als langsamster Lauf.
MySQL: Details
Bei diesem Test muss man jedoch die Details betrachten. Denn es gibt durchaus Ergebnisse, bei denen das 32-Bit-System deutlich schneller, aber auch erheblich langsamer ist.
MySQL-Server 4 zeigte bei denselben Tests äquivalente Schwächen in der 64-Bit-Variante des Linux-Systems. tecCHANNEL prüfte das nach, um sicher zu gehen, dass es nicht an der Datenbankversion liegt.
MySQL: Tabellarischer Überblick
Operation | Durchschnitt 32 Bit [sek.] | Durchschnitt 64 Bit [sek.] |
|---|---|---|
Kleinere Werte sind besser | ||
Results per test in seconds: | ||
ATIS | 11,2 | 10,6 |
alter-table | 58,6 | 56,7 |
big-tables | 9,2 | 8,3 |
connect | 19,8 | 17,7 |
create | 21,2 | 18,7 |
insert | 832,7 | 762,2 |
select | 284,6 | 320,4 |
wisconsin | 4,7 | 4,3 |
The results per operation: | ||
alter_table_add (992) | 32,7 | 31,5 |
alter_table_drop (496) | 24,6 | 24 |
connect (10000) | 3,8 | 3,5 |
connect+select_1_row (10000) | 4,8 | 4,2 |
connect+select_simple (10000) | 4,2 | 4 |
count (100) | 4,9 | 6,3 |
count_distinct (1000) | 9,4 | 10,1 |
count_distinct_2 (1000) | 12,4 | 12,1 |
count_distinct_big (120) | 22,7 | 29,3 |
count_distinct_group (1000) | 24,6 | 22 |
count_distinct_group_on_key (1000) | 9,9 | 11,4 |
count_distinct_group_on_key_parts (1 | 24,5 | 22,1 |
count_distinct_key_prefix (1000) | 7,3 | 8,2 |
count_group_on_key_parts (1000) | 9 | 11,9 |
count_on_key (50100) | 75,7 | 89,5 |
create+drop (10000) | 5 | 4,8 |
create_MANY_tables (10000) | 3,8 | 3,4 |
create_index (8) | 0,3 | 0,5 |
create_key+drop (10000) | 6,4 | 6 |
create_table (31) | 0 | 0,1 |
delete_all (12) | 3,9 | 3,4 |
delete_all_many_keys (1) | 59,4 | 59,3 |
delete_big (1) | 0,5 | 0,2 |
delete_big_many_keys (128) | 59,4 | 59,3 |
delete_key (10000) | 0,9 | 0,7 |
drop_index (8) | 1 | 0,6 |
drop_table (28) | 0,1 | 0 |
drop_table_when_MANY_tables (10000) | 4,8 | 3,2 |
insert (350768) | 29,2 | 26,3 |
insert_duplicates (100000) | 7,2 | 6,3 |
insert_key (100000) | 130 | 113,6 |
insert_many_fields (2000) | 1,8 | 1,6 |
insert_select_1_key (1) | 1,2 | 1,2 |
insert_select_2_keys (1) | 1,6 | 1,2 |
min_max (60) | 4 | 5,6 |
min_max_on_key (85000) | 35,3 | 37,5 |
multiple_value_insert (100000) | 1,6 | 1,4 |
order_by_big (10) | 19,9 | 17,5 |
order_by_big_key (10) | 17,7 | 14,2 |
order_by_big_key2 (10) | 17,1 | 13,8 |
order_by_big_key_desc (10) | 17,6 | 14,2 |
order_by_big_key_diff (10) | 19,4 | 16,2 |
order_by_big_key_prefix (10) | 17,3 | 13,7 |
order_by_key2_diff (500) | 2,1 | 1,8 |
order_by_key_prefix (500) | 1,2 | 1 |
order_by_range (500) | 1,5 | 1,4 |
outer_join (10) | 12,6 | 11,3 |
outer_join_found (10) | 12,6 | 11,1 |
outer_join_not_found (500) | 7,6 | 6,7 |
outer_join_on_key (10) | 8,3 | 9 |
select_1_row (10000) | 0,8 | 1 |
select_2_rows (10000) | 0,8 | 0,6 |
select_big (80) | 17,3 | 14,3 |
select_big_str (10000) | 3,9 | 2,9 |
select_column+column (10000) | 0,8 | 0,9 |
select_diff_key (500) | 25,9 | 32,4 |
select_distinct (800) | 3,1 | 2,7 |
select_group (2911) | 35 | 36,4 |
select_group_when_MANY_tables (10000 | 1,2 | 1,3 |
select_join (100) | 0,8 | 0,3 |
select_key (200000) | 37,1 | 32,2 |
select_key2 (200000) | 38,2 | 33,6 |
select_key2_return_key (200000) | 35,9 | 31,3 |
select_key2_return_prim (200000) | 36,9 | 32,2 |
select_key_prefix (200000) | 38,4 | 33,6 |
select_key_prefix_join (100) | 3,3 | 3,6 |
select_key_return_key (200000) | 35,6 | 31,3 |
select_many_fields (2000) | 7,2 | 6,7 |
select_query_cache (10000) | 21,8 | 28,2 |
select_query_cache2 (10000) | 21,6 | 28,2 |
select_range (410) | 33,3 | 33,8 |
select_range_key2 (25010) | 5,1 | 4,5 |
select_range_prefix (25010) | 5 | 4,5 |
select_simple (10000) | 0,7 | 0,6 |
select_simple_join (500) | 0,6 | 0,7 |
update_big (10) | 12,5 | 9,9 |
update_of_key (50000) | 6,8 | 6,1 |
update_of_key_big (501) | 6,6 | 6,6 |
update_of_primary_key_many_keys (256 | 29,9 | 32,8 |
update_with_key (300000) | 27,1 | 24,3 |
update_with_key_prefix (100000) | 7,6 | 6,5 |
wisc_benchmark (114) | 1,8 | 1,6 |
TOTALS | 1285,4 | 1243,8 |
Linpack
Linpack misst die Geschwindigkeit eines Computers durch das Lösen von linearen Gleichungen. Die Einheit wird in GFlops (Fließkomma-Operationen pro Sekunde) angegeben. Linpack ist sehr speicherintensiv. Die Speicherzuweisung erfolgt über eine Matrix-Berechnung. Size x LDA x 8 (Anzahl der Gleichungen x Input x 8 Bit) ergibt den zu allokierenden Speicher.
Da 32-Bit-Systeme für Anwendungen typischerweise maximal 2 GByte Arbeitsspeicher zuweisen können, ist ein direkter Vergleich erst ab dieser Grenze möglich. Aber auch hier ist das 64-Bit-System fast fünf Prozent schneller.
dbench
Aus der Feder des Samba-Entwicklers Andrew Tridgell stammt die dbench-Testsuite. Das Samba-Team benutzt sie, um das Lastverhalten des Filesystems im Allgemeinen sowie des Samba-Servers im Speziellen zu untersuchen.
dbench simuliert Dateisystemzugriffe, die eine Anzahl vordefinierter Clients auf einem Samba-Server erzeugen. Dieser Benchmark ist somit interessant für Administratoren, die einen Fileserver betreiben.
Kernel-Kompilierung
Ein sehr praxisnaher Test ist die Zeitmessung der Kompilierung eines Vanilla-Kernels. Hierzu dienten die Sourcen des Kernels 2.6.11 von kernel.org. Mit dem Kommando
time make -j3 bzImage modules
wurde schlicht die Dauer bis Beendigung des Vorgangs gemessen. Hier gibt es drei Werte: real, user und sys. real beschreibt die tatsächlich verstrichene Zeit. user gibt die Gesamtzahl der Sekunden an, die der Prozess im user mode verbrachte. sys ist die Gesamtzeit, die der Prozess im kernel mode verweilte.
Fazit
Mit Linux bringt 64 Bit in allen getesteten Bereichen Geschwindigkeitsvorteile. Und das nicht nur, wenn die Adressierung des Speichers über die 32-Bit-Grenze hinausgeht. Fünf Prozent mehr Prozessorleistung auf der gleichen Maschine, wie es Linpack zeigt, ist nicht schlecht. 20 Prozent schneller bei intensiven Operationen, wie einen Kernel kompilieren, was hier über sieben Minuten Zeitgewinn entspricht, kann sich sehen lassen. Und dbench zeigt in der 64-Bit-Version mit zirka 30 Prozent sogar einen erheblichen Leistungszuwachs.
Nur im Datenbank-Benchmark sollte man den Einzelfall genauer betrachten. Kommt eine aggregierte Datenbank - aus der nur gelesen wird - zum Einsatz, lohnt es sicher, vorher ausgiebige Tests durchzuführen. Denn gerade in bestimmten "select"-Anweisungen hat die 32-Bit-Version von MySQL deutlich die Nase vorn. Es ist somit zu eruieren, was Ihre MySQL-Datenbank-Server machen und worin deren Hauptaufgabe besteht. (cvi)