symlink.ch
Wissen Vernetzt - deutsche News für die Welt
 
symlink.ch
FAQ
Mission
Über uns
Richtlinien

Moderation
Einstellungen
Story einsenden

Suchen & Index
Ruhmeshalle
Statistiken
Umfragen

Redaktion
Themen
Partner
Planet

XML | RDF | RSS
PDA | WAP | IRC
Symbar für Opera
Symbar für Mozilla

Freunde
Benutzergruppen
LUG Switzerland
LUG Vorarlberg
LUGen in DE
SIUG
CCCZH
Organisationen
Wilhelm Tux
FSF Europe
Events
LinuxDay Dornbirn
BBA Schweiz
CoSin in Bremgarten AG
VCFe in München
Menschen
maol
Flupp
Ventilator
dawn
gumbo
krümelmonster
XTaran
maradong
tuxedo

 
FreeBSD 7 skaliert besser als Linux
Veröffentlicht durch Ventilator am Mittwoch 14. Maerz 2007, 10:35
Aus der Das-Ewige-Wettrennen Abteilung
BSD Doener schreibt: "Pro-Linux berichtet von einem Skalierbarkeitstest Kris Kennaways, in dem FreeBSD und Linux samt MySQL-Datenbank auf einem Acht-Prozessor-System jeweils auf ihre Skalierbarkeit getestet wurden. Dabei zeigte sich, dass die kommende Version von FreeBSD inzwischen bei geringer und mittelhocher Last ebensogut skaliert wie Linux. Unter Höchstlachst brach die Performance das Linux-Systems ein, während die Leistung des FreeBSD-System konstant blieb. Der Test sorgte für eine Diskussion auf der Linux-Kernel-Mailingliste. Ein ausführlicher Test macht in erster Linie die Speicherverwaltung der GNU C Library für das Problem verantwortlich."

XMMS2 Logo Wettbewerb 2007 | Druckausgabe | OpenExpo 2007 vorbei - nächste in Planung  >

 

 
symlink.ch Login
Login:

Passwort:

extrahierte Links
  • FreeBSD
  • GNU
  • Linux
  • MySQL
  • Pro-Linux
  • Doener
  • Pro-Linux berichtet
  • Skalierbarkeitstest Kris Kennaways
  • FreeBSD
  • MySQL-Datenbank
  • Diskussion auf der Linux-Kernel-Mailingliste
  • ausführlicher Test
  • GNU C Library
  • Mehr zu BSD
  • Auch von Ventilator
  • Diese Diskussion wurde archiviert. Es können keine neuen Kommentare abgegeben werden.
    Das Problem unter Linux scheint gelöst: (Score:2)
    Von Doener am Wednesday 14. March 2007, 11:18 MES (#1)
    (User #2169 Info) http://blogage.de/
    Das Problem unter Linux scheint gelöst:
  • http://ozlabs.org/~anton/linux/sysbench/
  • http://lkml.org/lkml/2007/3/13/19

  • Lokalisiert ungleich gelöst... (Score:0)
    Von Anonymer Feigling am Wednesday 14. March 2007, 15:41 MES (#7)
    ...weil:

    ""
    I guess googlemalloc (tcmalloc?) isn't suitable for a general purpose glibc allocator.
    ""
    EOQ (http://lkml.org/lkml/2007/3/13/148)

    Und wo der Haken im glibc-malloc liegt haben sie wohl noch nicht gefunden :-/
    Gelöst ?? (Score:0)
    Von Anonymer Feigling am Wednesday 14. March 2007, 11:19 MES (#2)
    Das Problem soll gelöst sein: hier
    entweder man nimmt nicht die glibc oder es ist im userspace zu finden?

    Ich kenne mich hier nicht so gut aus ...
    Open Source spielt seine Stärken aus! (Score:2)
    Von bones am Wednesday 14. March 2007, 12:58 MES (#3)
    (User #481 Info) http://www.chabis.ch
    Na, kaum ist die Meldung draussen startet ein Dutzend Programmierer durch, lokalisiert das Problem und findet eine Alternative zur Stadardlibrary, die das Problem bereits löst und mit wenigen Handgriffen installiert werden kann.

    Analysieren können die Closed Source Anbieter auch, wenn sie gross genug sind, aber ihr Geschäftsmodell erschwert oder verhindert, dass ein anderer bereits die Lösung programmiert hat (ob nun absichtlich oder aus Versehen) und man dessen Lösung einfach
    rasch einbaut.

    Grüsse vom Knochen
    --
    Ein christlich Regiment wird durch nichts mehr verhunzt als durch zu viel sogenannte Justiz.
    J. Gotthelf
    hmm (Score:0)
    Von Anonymer Feigling am Wednesday 14. March 2007, 13:10 MES (#4)
    ein wunder dass hier noch nichts zu dem thema steht: http://blog.fefe.de/ er zieht doch sonst immer so über die glibc her und promoted seine dietlibc (oder verwechsle ich jetzt personen und/oder projekte?)
    Re: hmm (Score:2)
    Von Frank-Schmitt am Wednesday 14. March 2007, 13:27 MES (#5)
    (User #1302 Info)
    Vergiss die dietlibc, aus zwei Gründen.
    1.) compiliert fast garnichts damit
    2.) werden damit compilierte Programme statisch gelinkt, bei einem dietlibc-update darfst du also alles recompilieren.
    Wenn du eine funktionierende glibc-alternative willst, schau dir die uClibc an.
    Re: hmm (Score:0)
    Von Anonymer Feigling am Wednesday 14. March 2007, 14:07 MES (#6)
    Wenns doch statisch gelinkt ist, dann muss man doch gar nichts neu compilieren, weil ja eh schon alles im entsprechenden Binary ist? Sonst waers ja dynamisch, weil dann dynamisch etwas dazu geladen wird.
    Re: hmm (Score:2)
    Von bones am Wednesday 14. March 2007, 15:47 MES (#8)
    (User #481 Info) http://www.chabis.ch
    Ja, aber wenn die Lib ein Sicherheitsloch hat kannst Du sie nicht austauschen, ohne das gesamte Binary neu zu bauen oder zu warten, bis das jemand für Dich gemacht hat.

    Grüsse vom Knochen
    --
    Ein christlich Regiment wird durch nichts mehr verhunzt als durch zu viel sogenannte Justiz.
    J. Gotthelf
    Re: hmm (Score:0)
    Von Anonymer Feigling am Wednesday 14. March 2007, 15:53 MES (#9)
    Es wäre sehr unprofessionell, um nicht zu sagen, dumm und kindisch[1], wegen eines Problems die komplette Implementation zu wechseln. Nein, das wäre gar religiös. Sachlich dagegen ist es, das Problem zu lokalisieren und dann zu beheben.

    [1] Sorry Kinder, viele Erwachsene sind sicherlich dümmer als ihr.
    Re: hmm (Score:1)
    Von Leonidas am Wednesday 14. March 2007, 22:56 MES (#10)
    (User #2132 Info) http://xivilization.net/
    Aber wenn man die Implementation wechselt, dann hat man das Problem schon zumindest grob lokalisiert. Schon weiß man, dass das Problem in der glibc ist und kann nun versuchen es zu beheben.

    Also gar nicht religiös oder kindisch sondern einfach sehr praktisch zu Debuggingzwecken.
    Re: hmm (Score:0)
    Von Anonymer Feigling am Thursday 15. March 2007, 01:36 MES (#11)
    Wenn es gar nicht erst kompiliert oder einfach nur crasht, dann bist du so schlau wie vorher. Es gibt schon einen Unterschied zwischen systematischem Vorgehen und Schaun-mer-mal. Man kann z.B. einfach einen Profiler nutzen. Dann sieht man sehr schnell, wo viel CPU-Zeit verbraten wird.
    Re: hmm (Score:1)
    Von Leonidas am Thursday 15. March 2007, 16:03 MES (#12)
    (User #2132 Info) http://xivilization.net/
    Aber da es kompiliert hat und beim starten nicht crasht ist sofort klar woran das liegt.

    Klar, mit einem Profiler würde das wohl auch gehen. Aber so ist das für die Grobeingrenzung auch effaktiv.

    Von Kindisch hier zu sprechen finde ich auf jeden Fall stark übertrieben.
    Re: hmm (Score:1)
    Von Leonidas am Thursday 15. March 2007, 16:04 MES (#13)
    (User #2132 Info) http://xivilization.net/
    <a href="http://blog.fefe.de/?ts=bb063d77">Bitteschön</a>, er hat was dazu geschrieben. Fefe erstaunt mich manchmal, denn ich habe mich genau das gleiche gefragt, warum da nichts zu lesen war.
    Re: hmm (Score:1)
    Von Leonidas am Thursday 15. March 2007, 16:07 MES (#14)
    (User #2132 Info) http://xivilization.net/

    Gut, und noch nochmal richtig furmuliert:

    Bitteschön, er hat was dazu geschrieben. Fefe erstaunt mich manchmal, denn ich habe mich genau das gleiche gefragt, warum da nichts zu lesen war.

    Hmm, die Vorschaufunktion ist eine Sache die sollte ich vielleicht unter Umständen öfter nutzen. Das passiert immer wenn man einmal nicht drauf klickt.


    Linux User Group Schweiz
    Durchsuche symlink.ch:  

    Never be led astray onto the path of virtue.
    trash.net

    Anfang | Story einsenden | ältere Features | alte Umfragen | FAQ | Autoren | Einstellungen