Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Linuxtopia - Red Hat Enterprise Linux Einfuhrung in die System-Administration - Bandbreite und Prozessleistung

Kapitel 3. Bandbreite und Prozessleistung

Von den zwei Ressourcen, die in diesem Kapitel beschrieben werden, ist eine davon (Bandbreite) oft f�r den Systemadministrator nicht einfach zu verstehen, w�hrend die andere (Prozessleistung) zumeist einem einfach zu verstehenderen Konzept unterliegt.

Zus�tzlich dazu mag der Anschein erweckt werden, dass diese beiden Ressourcen nicht eng miteinander verbunden sind — warum also gemeinsam behandeln?

Der Grund daf�r, dass beide Ressourcen gemeinsam behandelt werden, ist derjenige, dass diese Ressourcen auf Hardware basieren, welche in direktem Zusammenhang mit der F�higkeit eines Computers Daten zu transportieren und zu verarbeiten stehen.

3.1. Bandbreite

Grunds�tzlich ist Bandbreite die Kapazit�t zur Daten�bertragung — in anderen Worten, wieviele Daten in einem bestimmten Zeitraum von einem Punkt zum anderen transportiert werden k�nnen. Eine Punkt-zu-Punkt Datenkommunikation setzt folgende zwei Dinge voraus:

  • Einen Satz elektrische Leiter, um eine Kommunikation auf unterster Ebene m�glich zu machen

  • Ein Protokoll, um die effiziente und verl�ssliche Kommunikation von Daten zu erleichtern

Es gibt zwei Arten von Systemkomponenten, die diesen Anforderungen entsprechen:

  • Busse

  • Datenpfade

Die folgenden Abschnitte untersuchen diese in allen Einzelheiten.

3.1.1. Busse

Wie zuvor angegeben, erm�glichen Busse Punkt-zu-Punkt Kommunikation und benutzewn eine Art Protokoll, um sicher zu gehen, dass jegliche Kommunikation auf eine kontrollierte Art abl�uft. Jedoch haben Busse auch andere charakteristische Merkmale:

  • Standardisierte, elektrische Merkmale (wie zum Beispiel die Anzahl von Leitern, Spannungspegel, �bertragungsgeschwindigkeit, usw.)

  • Standardisierte, mechanische Merkmale (wie die Art von Stecker, Kartengr��e, physikalische Anordnung, usw.)

  • Standardisiertes Protokoll

Das Wort "standardisiert" ist wichtig, da Busse die haupts�chliche Form darstellen, in der verschiedene Systemkomponenten verbunden werden.

In vielen F�llen erlauben Busse die Verbindung von Hardware unterschiedlicher Hersteller; ohne Standardisierung w�re dies nicht m�glich. Jedoch auch in Situationen, in denen ein Bus urheberrechtliches Eigentum eines bestimmten Erzeugers ist, ist Standardisierung ein wichtiger Punkt, der dem Erzeuger erlaubt auf einfachere Weise verschiedene Komponenten zu implementieren, wobei eine allgemeine Schnittstelle verwendet wird — n�mlich der Bus selbst.

3.1.1.1. Beispiele von Bussen

Ganz egal wo Sie bei einem Computersystem nachschauen, finden Sie Busse. Hier sind einige der gebr�uchlicheren Busse:

  • Massenspeicher-Busse (ATA und SCSI)

  • Netzwerke[1] (Ethernet und Token Ring)

  • Speicher-Busse (PC133 und Rambus®)

  • Expansions-Busse (PCI, ISA, USB)

3.1.2. Datenpfade

Datenpfade k�nnen schwerer zu identifizieren sein, sind jedoch wie Busse �berall anzutreffen. Genauso wie Busse erm�glichen auch Datenpfade Punkt-zu-Punkt-Kommunikation. Jedoch im Gegensatz zu Bussen:

  • Benutzen Datenpfade ein einfacheres Protokoll (falls �berhaupt)

  • Besitzen Datenpfade wenig (falls �berhaupt) mechanische Standardisierung

Der Grund daf�r ist, dass Datenpfade normalerweise systemintern sind und nicht dazu benutzt werden, ad-hoc die Verkn�pfung zwischen verschiedenen Komponenten herzustellen. Als solches sind Datenpfade h�chst optimiert auf bestimmte Situationen, in denen Geschwindigkeit und geringe Kosten gegen�ber langsamerer und teurerer Mehrzweck-Flexibilit�t vorgezogen werden.

3.1.2.1. Beispiele von Datenpfaden

Hier sind einige typische Datenpfade:

  • 'CPU zu On-Chip Cache'-Datenpfad

  • 'Grafik Prozessor zu Video-Speicher'-Datenpfad

3.1.3. Potentielle Bandbreiten-bezogene Probleme

Es gibt zwei Arten auf denen Probleme, die auf Bandbreiten bezogen sind, entstehen k�nnen (entweder f�r Busse oder Datenpfade):

  1. Der Bus oder Datenpfad kann eine gemeinsam benutzte Ressource darstellen. In diesem Fall wird durch die dadurch f�r den Bus entstehende Konkurrenzsituation die effektive Bandbreite reduziert, die f�r alle Ger�te am Bus erh�ltlich ist.

    Ein SCSI-Bus mit einigen h�chst aktiven Laufwerken w�re ein gutes Beispiel daf�r. Die h�chst aktiven Laufwerke s�ttigen den SCSI-Bus, wobei nur wenig Bandbreite f�r jegliche andere Ger�te auf dem selben Bus �brig bleibt. Als Endergebnis sind alle I/O-Vorg�nge in Verbindung mit irgendeinem der Ger�te auf diesem Bus langsam, sogar wenn jedes einzelne Ger�te auf dem Bus nicht �berm��ig aktiv ist.

  2. Der Bus oder Datenpfad kann eine fest zugeordnete Ressource mit einer festgelegten Anzahl von angeschlossenen Ger�ten sein. In diesem Fall schr�nken die elektrischen Eigenschaften des Busses (und in gewisser Weise auch die Art des benutzten Protokolls) die erh�ltliche Bandbreite ein. Dies ist normalerweise h�ufiger bei Datenpfaden als bei Bussen der Fall. Dies ist auch einer der Gr�nde, warum Grafik-Adapter dazu neigen, bei h�heren Aufl�sungen oder Farbtiefen langsamer zu arbeiten — Bei jedem Auffrischen des Bildschirms m�ssen mehr Daten entlang des Datenpfads transportiert werden, welcher Videospeicher und Grafikprozessor miteinander verbindet.

3.1.4. Potenzielle, Bandbreiten-bezogene L�sungen

Gl�cklicherweise kann auf Probleme, die sich auf Bandbreite beziehen, reagiert werden. Tats�chlich gibt es einige unterschiedliche Vorgehensweisen:

  • Die Last verteilen

  • Die Last reduzieren

  • Die Kapazit�t erh�hen

Die folgenden Abschnitte befassen sich genauer mit jeder Vorgehensweise:

3.1.4.1. Verteilen der Last

Die erste Ann�herung ist die gleichm��igere Verteilung der Bus-Aktivit�t. In anderen Worten, wenn ein Bus �berlastet und ein anderer frei ist, so k�nnte die Situation wahrscheinlich dadurch verbessert werden, dass einiges der Arbeitslast an den freien Bus weitergeleitet wird.

Als Systemadministrator ist dies die erste Methode, die sie in Betracht ziehen sollten, da des �fteren bereits zus�tzliche Busse in ihrem System vorhanden sind. Zum Beispiel beinhalten die meisten PCs mindestens zwei ATA-Channels (was nur eine andere Bezeichnung f�r Bus ist). Wenn Sie zwei ATA-Laufwerke besitzen und zwei ATA-Channels, warum sollten dann beide Laufwerke auf dem selben Channel sein?

Auch wenn Ihre Systemkonfiguration keine zus�tzlichen Busse beinhaltet, so kann auch die reine Verteilung der Last eine vern�nftige L�sung darstellen. Die Ausgaben f�r Hardware, um dies zu bewerkstelligen, w�ren immer noch geringer, als wenn ein bestehender Bus durch Hardware mit h�herer Kapazit�t ausgetauscht werden m�sste.

3.1.4.2. Reduzieren der Last

Auf den ersten Blick scheinen das Verteilen und das Reduzieren der Last lediglich verschiedene Seiten der selben M�nze zu sein. Immerhin gilt, dass wenn man die Last verteilt, dies gleichzeitig die Last reduziert (zumindest auf dem �berlasteten Bus), richtig?

W�hrend dieser Standpunkt zwar korrekt erscheint, hat das Verteilen der Last jedoch nicht die selbe Auswirkung, als das globale Reduzieren der Last. Der Schl�ssel dazu liegt in der Ermittlung, ob ein gewisser Aspekt in der Systemlast zur �berlastung des jeweiligen Busses f�hrt. Kann es sein, dass zum Beispiel ein Netzwerk schwerstens �berlastet ist aufgrund unn�tiger Aktivit�ten? Vielleicht ist auch eine kleine tempor�re Datei der Empf�nger enormer Lese-/Schreib-Eing�nge/Ausg�nge? Wenn sich diese tempor�re Datei auf einem im Netzwerk befindlichen Dateiserver befindet, so k�nnte viel Netzwerkverkehr vermieden werden, wenn z.B. lokal mit dieser Datei gearbeitet wird.

3.1.4.3. Die Kapazit�t erh�hen

Die offensichtliche L�sung f�r ungen�gende Bandbreite ist diese irgendwie zu erh�hen. Jedoch ist dies normalerweise ein teures Unterfangen. Nehmen wir zum Beispiel einen SCSI-Controller und dessen �berlasteten Bus. Um dessen Bandbreite zu erh�hen, m�sste der SCSI-Controller (und wahrscheinlich alle angeh�ngten Ger�te) gegen schnellere Hardware ausgetauscht werden. Wenn der SCSI-Controller eine separate Karte ist, dann w�re dies ein relativ unkomplizierter Prozess. Wenn der SCSI-Controller jedoch ein Teil der Hauptplatine ist, so wird es zusehends schwerer den �konomischen Punkt einer solchen Ver�nderung zu rechtfertigen.

3.1.5. Im �berblick…

Alle Systemadministratoren sollten sich �ber Bandbreite und die Auswirkungen von System-Konfiguration und -Benutzung auf die Bandbreite im Klaren sein. Leider ist es nicht immer offensichtlich, wenn es sich bei einem Problem um ein Bandbreiten-Problem handelt. Manchmal ist der Bus selbst nicht das Problem, daf�r eine der Komponenten, welche mit dem Bus verbunden sind.

Stellen Sie sich zum Beispiel einen SCSI-Adapter vor, der mit einem PCI-Bus verbunden ist. Im Falle von Performance-Problemen mit dem SCSI-Festplatten-I/O kann dies das Ergebnis eines d�rftig ausf�hrenden SCSI-Adapters sein, auch wenn die SCSI- und PCI-Busse nicht im Geringsten deren eigentliche Bandbreiten-F�higkeiten erreicht haben.

Fu�noten

[1]

Anstatt eines Intra-System-Bus, k�nnen Netzwerke auch als Inter-System-Bus angesehen werden.

 
 
  Published under the terms of the GNU General Public License Design by Interspire