Archiv verlassen und diese Seite im Standarddesign anzeigen : serverperformance optimieren
hi,
ich bin nicht so der riesen linux-freak. klar kenn ich mich soweit aus, aber ich hab nicht so wirklich die ahnung, wie ihc (m)einen server hinsichtlich der performance für apache/mysql optimieren kann.
schätze es wäre durchaus interessant mal alles zu sammeln, was mit performance-optimierung zu tun hat (ob jetzt hinsichtlich webserver oder nicht).
danke schonmal :D
martin
ich denke mal dass eine intelligente partitionierung (/var auf eigener part usw.) schon einiges zur performance beitragen könnte.
ein selbstgebastelter, aufs system optimierter kernel versteht sich ja von selbst :ugly:
Hi,
warum /var auf eine eigene Partition legen? Was ist da drin was so viel Resourcen braucht?!
Shutdown
dumpfbacke
06.07.04, 15:17
Vieleicht weil auf das /var verzeichniss von aussen aus zugegriffen wird (Apache, ftp ...) und beansprucht wird :)
MFG.
Hi,
warum /var auf eine eigene Partition legen? Was ist da drin was so viel Resourcen braucht?!
Shutdown
squid-Cache, Mails, logs, News, ...
'cuda
Hi,
Das wegen der Partitonierung habe ich auch schon oft gehört, gelesen. Kann das mal jemand beweisen, beziehungsweise klar erläutern?
Ich persönnlich habe das Gefühl, dass das nichts bringt. Schlussendlich wird ja auf die gleiche Festplatte zugegriffen. Wenn man /var auf eine zusätzliche Festplatte auslagert, ist das natürlich wieder etwas anderes!
Gruss
Chrigu
Hi,
Das wegen der Partitonierung habe ich auch schon oft gehört, gelesen. Kann das mal jemand beweisen, beziehungsweise klar erläutern?
Ich persönnlich habe das Gefühl, dass das nichts bringt. Schlussendlich wird ja auf die gleiche Festplatte zugegriffen. Wenn man /var auf eine zusätzliche Festplatte auslagert, ist das natürlich wieder etwas anderes!
Gruss
Chrigu
Bingo. Allerdings sollte man auch immer mal gucken, was gefordert ist und wo der Flaschenhals
liegt. Der duerfte bei den aktuellen Festplattengeschwindigkeiten zu 99% an der Netzwerkanbindung
liegen. Und da laesst sich, ausser durch gescheite Karten, recht wenig optimieren.
'cuda
Hi,
Das wegen der Partitonierung habe ich auch schon oft gehört, gelesen. Kann das mal jemand beweisen, beziehungsweise klar erläutern?
Ich persönnlich habe das Gefühl, dass das nichts bringt. Schlussendlich wird ja auf die gleiche Festplatte zugegriffen. Wenn man /var auf eine zusätzliche Festplatte auslagert, ist das natürlich wieder etwas anderes!
Gruss
Chrigu
ja, stimmt mit eigener partition hatte ich das ja auch eigentlich gemeint. sorry, falsch ausgedrückt.
also prinzipiell kann eine platte schon zum bottleneck werden ... kommt halt auf die belastung an. ich schwöre da immernoch auf ein nettes SCSI RAID 10 und 2 per bonding/load balancing angesprochene GBIT netzwerk schnitstellen. mit so einem setup sollte (zumindest hardware mässig) kein problem auftauchen.
Hi,
Wieviel Durchsatz erreichst du mit deinem Raid10? Schaffts du wirklich genug, um 2 GBit-Karten auszulasten?
Ich schaffe mit einem Raid5 (5x 73GB, U320, 10k) ca. 60MB/s, somit laste ich eine GBit-Karte etwa zur Hälfte aus!
Gruss
Chrigu
womit wir den bottleneck auch schon gefunden hätten ;)
Ja klar, bei mir sind es die Platten. Mich würde aber immer noch interessieren, wieviel du mit einem Raid10 schaffst?
Könnt ihr mal allgemein eure Erfahrungen posten, mit den verschiedenen Raid-Leveln, und was ihr dabei für Transferraten erzielt habt?
Würde mich schon mal interessieren.. ;)
Gruss
Chrigu
hab ich um ehrlich zu sein noch nie getestet.
was mich an 10 nur ruhiger schlafen lässt is die datenredundanz :) darum hab ich das so gewählt!
Wenn du aber nicht unbedingt auf die super Performance eines Raid10 angewiesen bist, dann ist ein Raid5 schon nur Preis/Leistungsmässig viel besser?!
Bei Raid 10 verschenkst du ja die Hälfte deiner Kapazität?
ja, gottseidank muss ich die dinger auch ned bezahlen da is das "verschenken" der kapazität verkraftbar ....
gut, also wieder ontopic :)
hat noch wer weiterführende tipps als meine aus meinem ersten post da oben?
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.