zum I/O-Durchsatz des VmKernels.
Hallo erstmal.
Also es muss ja sicher eine theoretische Obergrenze geben, die den I/O-Durchsatz des kernels begrenzt. Worauf es mir ankommt ist eine Prognose darüber, an welcher Stelle Performanz-Engpässe zu erwarten sind - auf dem Strorage-Prozessor ober im VmKernel. Kennt jemand eine InfoQuelle, die solche theoretischen Werte angibt? Oder gibt es eine Art Faustformel, nach der sich der Wert in etwa ermitteln lässt?
Gruß,
Oculus
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
Theoretische Frage...
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo,
eigentlich ganz einfach.
Solange ein IO von einem Disk/Storage Array beantwortet wird, wird immer dort das Bottleneck sein.
Schließlich reden wir bei
- CPU Cyclen im ns Bereich,
- Memory (RAM) von Zugriffs- und Antwortzeiten im ns Bereich
während Disk Arrays im ms Bereich agieren.
Egal welches Storage Array du verwendest, irgendwann muß es die Daten von den Platten holen bzw. auf die Platten schreiben.
Um z.B eine vernünftige Planung für die Plattenanforderungen einer Applikation durchführen zu können, sollte ein Array Cache bei den Berechnungen bezüglich der notwendigen Anzahl von Platten immer vernachlässigt werden.
Falls du weitere Fragen zum Thema Performance hast, einfach hier posten.
Gruß
Ralf
eigentlich ganz einfach.
Solange ein IO von einem Disk/Storage Array beantwortet wird, wird immer dort das Bottleneck sein.
Schließlich reden wir bei
- CPU Cyclen im ns Bereich,
- Memory (RAM) von Zugriffs- und Antwortzeiten im ns Bereich
während Disk Arrays im ms Bereich agieren.
Egal welches Storage Array du verwendest, irgendwann muß es die Daten von den Platten holen bzw. auf die Platten schreiben.
Um z.B eine vernünftige Planung für die Plattenanforderungen einer Applikation durchführen zu können, sollte ein Array Cache bei den Berechnungen bezüglich der notwendigen Anzahl von Platten immer vernachlässigt werden.
Falls du weitere Fragen zum Thema Performance hast, einfach hier posten.
Gruß
Ralf
Hm,
ich glaube da gibt es keine softwareseitige Obergrenze.Der Kernel leitet die Daten an den jeweiligen Stack weiter. Läuft der Stack voll, weil die darunterliegenden Layer (sei es Software wie BIOS oder Hardware) nicht schnell genug nachkommt, gibt ein 'Overflow-Handling', fertig.
Aber es gibt m.W.n. keine vorgegebene Begrenzung, die den Kernel veranlaßt, zu sagen: bis hier hin und nicht weiter. Zumindest habe ich nie irgendwo sowas gelesen.
I
Es gibt da einen recht netten (Marketing
) Artikel von VMware:
http://blogs.vmware.com/performance/200 ... opera.html
ich glaube da gibt es keine softwareseitige Obergrenze.Der Kernel leitet die Daten an den jeweiligen Stack weiter. Läuft der Stack voll, weil die darunterliegenden Layer (sei es Software wie BIOS oder Hardware) nicht schnell genug nachkommt, gibt ein 'Overflow-Handling', fertig.
Aber es gibt m.W.n. keine vorgegebene Begrenzung, die den Kernel veranlaßt, zu sagen: bis hier hin und nicht weiter. Zumindest habe ich nie irgendwo sowas gelesen.
I
Es gibt da einen recht netten (Marketing
http://blogs.vmware.com/performance/200 ... opera.html
Vielen Dank erstmal.
Die Problematik ist, dass ich eine Applikation habe, die erwartet sehr viel IO produzieren wird - Domino-Server halt. Nun sind die Domino-Admins bange, dass der ESX nicht die geforderte IO-Last bedienen kann. Da ich aber nicht das Gegenteil beweisen kann, habe ich ein Problem in der Argumentation. Überhaupt kenn ich mich damit nicht hinreichend aus, was z.b. den IO-Durchsatz eines Storagearrys angeht bzw. wie man so etwas berechnen kann. Aber ich denke mal, dass ich mit dem Dokument schon mal was an der Hand habe.
Die Problematik ist, dass ich eine Applikation habe, die erwartet sehr viel IO produzieren wird - Domino-Server halt. Nun sind die Domino-Admins bange, dass der ESX nicht die geforderte IO-Last bedienen kann. Da ich aber nicht das Gegenteil beweisen kann, habe ich ein Problem in der Argumentation. Überhaupt kenn ich mich damit nicht hinreichend aus, was z.b. den IO-Durchsatz eines Storagearrys angeht bzw. wie man so etwas berechnen kann. Aber ich denke mal, dass ich mit dem Dokument schon mal was an der Hand habe.
Lotus Domino Server funktionieren einwandfrei, solange sie genügend RAM zugewiesen bekommen.
Bekanntermaßen hat Domino ja die Eigenschaft, sämtliche nsf-Datenbanken immer geöffnet zu haben, was zugegebenermaßen ordentlich I/O erzeugt. Aber es werden an sich keine großen Datenmengen bewegt, sondern es passieren viele kleine Dateizugriffe. Wenn das das bislang eingesetzte Storage schafft, klappt das auch über den/die ESXen.
Es sei denn, da schickt jeder jedem Mails mit 50MB Attachement
Es gibt, glaube ich auf der VMware Seite eine Whitepaper zu Domino. Ebenso gibt es sowas auf der IBM-Seite zu ESX und Domino..Goggle mal danach.
Ist der Domino-Server mit einer DB/2 Datenbank verbunden, gelten hier natürlich die Restriktionen bzgl Datenbanken. Aber auch dazu gibts ein Whitepaper bei IBM.
Bekanntermaßen hat Domino ja die Eigenschaft, sämtliche nsf-Datenbanken immer geöffnet zu haben, was zugegebenermaßen ordentlich I/O erzeugt. Aber es werden an sich keine großen Datenmengen bewegt, sondern es passieren viele kleine Dateizugriffe. Wenn das das bislang eingesetzte Storage schafft, klappt das auch über den/die ESXen.
Es sei denn, da schickt jeder jedem Mails mit 50MB Attachement
Es gibt, glaube ich auf der VMware Seite eine Whitepaper zu Domino. Ebenso gibt es sowas auf der IBM-Seite zu ESX und Domino..Goggle mal danach.
Ist der Domino-Server mit einer DB/2 Datenbank verbunden, gelten hier natürlich die Restriktionen bzgl Datenbanken. Aber auch dazu gibts ein Whitepaper bei IBM.
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 51 Gäste