Plattenauslastung

[Frank.Sobanek]

Guten Morgen,

habe eine Testmaschine i 520 V5R4M0.

Gelten die Aussagen noch,
das bei über 80 % Plattenbelastung die Performance erheblich leidet,
und dieser Wert nicht überschritten werden soll. ?

Gruß

Frank

[madoxx]

Hallo Frank,

ab 80 Prozent Plattenbelegung werden neue Objekte komprimiert gespeichert. Das bedeutet Zeit für die komprimierung aber auch Zeit für die dekromprimierung beim Lesen.
Dazu kommt auch der längere mechanische Weg der Plattenarme. Bei den vielen Plattenzugriffsbewegungen eines OS400-System kann sich das Zeitverhalten entsprechend hochschaukeln.


Gruß Madoxx

[KingofKning]

Also das mit der Plattenarmbewegung kannst Du ja in V5R4 schon optimieren. Stichwort STRDSKRGZ & STRASPBAL.

GG

[Fuerchau]

Die 80% sind schon relativ gesehen.
Bei 1 TB sind ja noch 200GB frei, da dürfte es noch keine Probleme geben.

[Felidae]

Moin,

wir hatten vor 2 Jahren bei unserer 550 unter V5R4 eine Plattenplatzbelegung von stellenweise 80% bei 1,5TB.

Ich habe ca. 1000 Leute auf der Maschine - das hat man trotz Optimierung ganz schön an der Performance gemerkt... Sobald wir nach einer "Gewaltbereinigung" wieder bei ca. 75% Belegung waren, ging's wieder ratzifatzi.

Daher meine Erfahrung - die 80%-Grenze kann u.U. schon Probleme machen.

Gruss Simone

[Fuerchau]

Wahrscheinlich auch nur eine technische Marketingbremse von IBM um teure Platten zu verkaufen.
Bei 300GB freiem Platz gibts eigentlich noch keinen Grund hier eine Bremse anzuziehen.

[holgerscherer]

Bei 300GB freiem Platz gibts eigentlich noch keinen Grund hier eine Bremse anzuziehen.

Es geht weniger um den freien Platz als um den Weg, den die Köpfe im Lauf der Millisekunden zurücklegen müssen. Im WRKDSKSTS immer mal die letzte Spalte beachten.

-h

[Chris.jan]

Ist die Plattenbelegung/-auslastung bei SAN-Platten eigentlich "egal"? Wir haben LUNs die sich im Hintergrund auf ganz viele Platten verteilen, da muß sich auf der Seite der AS/400 kein physischer Arm bewegen.

[andreaspr@aon.at]

Ein gutes Storage Management System (egal ob auf der AS/400, SAN, XIVs oder was auch immer) sollte versuchen jene Blöcke die oft benötigt werden auf den äußeren Ringen/Sektoren der Disk zu speichern, da der Zugriff dort am schnellsten ist.
Je mehr belegt ist, desto mehr müssen auch die inneren (langsameren) Sektoren benützt werden.

Aus diesem Grund gilt IMMER: Je voller desto langsamer!

lg Andreas

[Chris.jan]

Klar, da hast Du recht. Bei uns im SAN (4x V7000 uvm.) ist allerdings nicht mehr die Platte das Nadelöhr, sondern die Infrastruktur. Allerdings ist uns jetzt gesagt worden, daß wir unseren ASP besser auf die doppelte Anzahl der Platten mit jeweils der halben Plattengröße verteilen sollen, um die Performance auf der Seite der AS/400 zu erhöhen. Darauf wollte ich hinaus.

[KingofKning]

Ein gutes Storage Management System (egal ob auf der AS/400, SAN, XIVs oder was auch immer) sollte versuchen jene Blöcke die oft benötigt werden auf den äußeren Ringen/Sektoren der Disk zu speichern, da der Zugriff dort am schnellsten ist.
Je mehr belegt ist, desto mehr müssen auch die inneren (langsameren) Sektoren benützt werden.

Aus diesem Grund gilt IMMER: Je voller desto langsamer!

lg Andreas

Also dieser Meinung kann ich mich nicht anschließen. Das hatte ganz bestimmt seine Berechtigung in der Steinzeit der EDV aber bei den heutigen Systemen mit Ihrer Cachstrategie und Ihrer Datenverteilung auf div. Platten kann ich mir das nicht vorstellen.

Wenn Du z.B. eine Abfrage per SQL über einen Artikelstamm machst der bei einer Plattenauslastung von 10% 50 Sekunden dauert, dann wird der auch nicht länger brauchen wenn die Platte mit anderen Daten zu 90% belegt ist.

Wenn der Artikelstamm allerdings dann 10 mal so groß geworden ist ist es klar das es länger dauert.

Ohne genaue Kenntnisse der Raid-Controller der Cache Strategie und der Verteilung der Daten auf den einzelnen Platten wird man da wohl keine konkrete Aussage machen können.
Aber interessieren würden mich die technischen Zusammenhänge schon.

GG

[Fuerchau]

Nun ja, Fakt ist aber trotzdem (siehe oben), je mehr Plattenarme zur Verfügung stehen, desto mehr kann parallel zugegriffen werden.
Viele kleine Platten sind daher besser als wenige große und mehrere Plattenkontroller sind besser als wenige.

Ich habe es bei Kunden schon des öfteren erlebt, dass ein neues "schnelles" System langsamer war als das alte, da die Anzahl der Platten erheblich reduziert wurde.

Bei SQL-Abfragen mit vielen Platten lohnt sich ggf. auch die Aktivierung des Parallel-Features, da dann auch SQL mehrere Prozessoren für eine Abfrage verwendet.

Man hat allerdings keine Möglichkeit die Verteilung der Dateien auf der Platte zu steuern. Die Wahrscheinlichkeit, dass große Tabellen auf mehreren Töpfen legt ist größer als bei kleinen Dateien.