Login
Login-Name Passwort


 
Newsletter
Werbung

Di, 13. März 2007, 18:48

Software::Distributionen::BSD::FreeBSD

FreeBSD-Skalierbarkeit verbessert

Die kommende Version 7.0 von FreeBSD wird besser auf Mehrprozessor-Systemen laufen als ihre Vorgängerversionen und hat Linux in der Geschwindigkeit eingeholt.

Seit einem Jahr ist ein Team von Entwicklern damit befasst, die Skalierbarkeit von FreeBSD auf Mehrprozessor-Systeme zu verbessern. Ein Bericht von Kris Kennaway stellt nun die erzielten Fortschritte vor. Zur Messung der Leistung wurde ein Benchmark mit MySQL 5 (Version 5.0.27, später 5.0.33) auf einem Acht-Prozessor-AMD-System durchgeführt. Dabei erreichte FreeBSD etwa die gleiche, bei höheren Lasten sogar eine deutlich bessere Leistung als Linux.

Gemessen wurde dies mit sysbench und einer variablen Zahl von Client-Threads, die SQL-Abfragen an einen lokalen MySQL-Server stellten. Während die Entwicklerversion von FreeBSD 7 bei acht Client-Threads die maximale Leistung erreichte und bei noch mehr Threads konstant auf diesem Leistungsniveau blieb, erreichte Linux zwar das gleiche Maximum, um aber bei höheren Client-Zahlen genauso schnell in der Leistung einzubrechen.

FreeBSD erreichte diese Skalierbarkeit durch das Entfernen einer globalen Kernel-Sperre und zahlreiche Performance-Messungen, um Engpässe zu identifizieren und zu eliminieren. Unter Linux wurden ähnliche Arbeiten schon früher durchgeführt, besonders während der Entwicklung von Kernel 2.6. Seither gilt Linux als sehr gut skalierbar und läuft beispielsweise in SGI-Rechnern auf bis zu 1024 Prozessoren.

Auf der Mailingliste des Linux-Kernels wurden die Ergebnisse des FreeBSD-Teams seit Ende Februar diskutiert. Rik van Riel gab an, das Problem auf einem Vierprozessor-System reproduzieren zu können. Das Maximum der Leistung wird offenbar erreicht, wenn die Zahl der Threads gleich der Zahl der CPUs ist, darüber bricht sie ein. Erste Tests ergaben, dass eine Scheduler-Option für einen Teil des Problems verantwortlich sein könnte. Schaltet man sie ab, fällt der Leistungsabfall geringer aus.

Anton Blanchard jedoch macht nach eingehender Analyse die GNU C Library (glibc), speziell deren Speicherverwaltung, für das Problem verantwortlich. Mit einer alternativen malloc-Bibliothek sei das Problem verschwunden, schreibt er. Andere Entwickler wiesen auf andere Merkwürdigkeiten in MySQL hin, die jedoch nur zu einem geringen Teil zu dem Leistungsverlust beitragen.

Werbung
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung