Seit dem Upgrade auf Solaris 11 hat meine ARC-Größe trotz 30 GB RAM konstant 119 MB erreicht. Was? Warum?


9

Ich habe eine NAS / SAN-Box unter Solaris 11 Express ausgeführt, bevor Solaris 11 veröffentlicht wurde. Die Box ist ein HP X1600 mit einem angeschlossenen D2700. Insgesamt 12x 1 TB 7200 SATA-Festplatten, 12x 300 GB 10k SAS-Festplatten in separaten Zpools. Der Gesamtspeicher beträgt 30 GB. Die angebotenen Dienste sind CIFS, NFS und iSCSI.

Alles war gut und ich hatte ein ZFS-Speichernutzungsdiagramm, das so aussah:

Eine ziemlich gesunde Arc-Größe von ca. 23 GB - Nutzung des verfügbaren Speichers für das Caching.

Ich habe dann jedoch ein Upgrade auf Solaris 11 durchgeführt, als das herauskam. Nun sieht mein Diagramm folgendermaßen aus:

Teilausgabe von arc_summary.plist:

System Memory:
     Physical RAM:  30701 MB
     Free Memory :  26719 MB
     LotsFree:      479 MB

ZFS Tunables (/etc/system):

ARC Size:
     Current Size:             915 MB (arcsize)
     Target Size (Adaptive):   119 MB (c)
     Min Size (Hard Limit):    64 MB (zfs_arc_min)
     Max Size (Hard Limit):    29677 MB (zfs_arc_max)

Es zielt auf 119 MB ab, während es bei 915 MB sitzt. Es hat 30 GB zum Spielen. Warum? Haben sie etwas geändert?

Bearbeiten

Zur Verdeutlichung arc_summary.plist Ben Rockwoods, und die relevanten Zeilen, die die obigen Statistiken generieren, sind:

my $mru_size = ${Kstat}->{zfs}->{0}->{arcstats}->{p};
my $target_size = ${Kstat}->{zfs}->{0}->{arcstats}->{c};
my $arc_min_size = ${Kstat}->{zfs}->{0}->{arcstats}->{c_min};
my $arc_max_size = ${Kstat}->{zfs}->{0}->{arcstats}->{c_max};
my $arc_size = ${Kstat}->{zfs}->{0}->{arcstats}->{size};

Die Kstat-Einträge sind da, ich bekomme nur ungerade Werte daraus.

Bearbeiten 2

Ich habe gerade die Bogengröße mit neu gemessen arc_summary.pl- ich habe diese Zahlen überprüft mit kstat:

System Memory:
     Physical RAM:  30701 MB
     Free Memory :  26697 MB
     LotsFree:      479 MB

ZFS Tunables (/etc/system):

ARC Size:
     Current Size:             744 MB (arcsize)
     Target Size (Adaptive):   119 MB (c)
     Min Size (Hard Limit):    64 MB (zfs_arc_min)
     Max Size (Hard Limit):    29677 MB (zfs_arc_max)

Was mir auffällt, ist, dass die Zielgröße 119 MB beträgt. In der Grafik wird arc_summary.plseit der Installation von Solaris 11 genau derselbe Wert angestrebt (124,91 Mio. nach Kakteen, 119 Mio. nach - ich glaube, der Unterschied beträgt nur 1024/1000 Rundungsprobleme). Es sieht so aus, als würde der Kernel keine Anstrengungen unternehmen, um die Zielgröße auf etwas anderes zu verschieben. Die aktuelle Größe schwankt, da die Anforderungen des (großen) Systems mit der Zielgröße kämpfen und das Gleichgewicht zwischen 700 und 1000 MB zu liegen scheint.

Die Frage ist jetzt etwas genauer: Warum setzt Solaris 11 meine ARC-Zielgröße nur schwer auf 119 MB und wie ändere ich sie? Sollte ich die Mindestgröße erhöhen, um zu sehen, was passiert?

Ich habe die Ausgabe von kstat -n arcstatsover unter http://pastebin.com/WHPimhfg festgehalten

Bearbeiten 3

Ok, jetzt Verrücktheit. Ich weiß, dass flibflob erwähnt hat, dass es einen Patch gab, um dies zu beheben. Ich habe diesen Patch noch nicht angewendet (es werden immer noch interne Supportprobleme behoben) und ich habe keine anderen Software-Updates angewendet.

Letzten Donnerstag stürzte die Box ab. Wie in, hörte völlig auf, auf alles zu reagieren. Als ich es neu gestartet habe, war es wieder in Ordnung, aber so sieht mein Diagramm jetzt aus.

Es scheint das Problem behoben zu haben.

Das ist jetzt richtig la la land Zeug. Ich habe buchstäblich keine Ahnung, was los ist. :(

Antworten:


4

Leider kann ich Ihr Problem nicht lösen, aber hier einige Hintergrundinformationen:

  • Die ARC-Zielgröße scheint kein fester Wert zu sein. Ich habe das gleiche Problem auf einem Solaris 11-Computer und nach jedem Neustart scheint sich die Zielgröße irgendwann auf einen Wert zwischen ~ 100 und ~ 500 MB festzulegen.

  • Mindestens drei weitere Personen sind mit demselben Problem konfrontiert, wie unter http://mail.opensolaris.org/pipermail/zfs-discuss/2012-January/050655.html beschrieben

  • Es gibt auch einen offenen Fehlerbericht (7111576) zu "My Oracle Support" ( https://support.oracle.com ). Wenn Ihr Server unter einem gültigen Supportvertrag steht, sollten Sie eine Serviceanfrage stellen und auf diesen Fehler verweisen. Derzeit scheint jeder Bugfix noch in Arbeit zu sein ...

Abgesehen davon können Sie nicht viel tun. Wenn Sie Ihre zpool / zfs-Versionen noch nicht aktualisiert haben, können Sie versuchen, in Ihre alte Solaris 11 Express-Startumgebung zu booten und diese auszuführen, bis Oracle schließlich beschließt, eine SRU freizugeben, die das Problem behebt.

Bearbeiten: Da die Frage der Leistungsverschlechterung oben diskutiert wurde: Es hängt alles davon ab, was Sie tun. Seit dem Upgrade auf Solaris 11 11/11 sind auf meiner Solaris 11 NFS-Freigabe schreckliche Latenzen aufgetreten. Im Vergleich zu Ihrem System habe ich jedoch relativ wenige Spindeln und verlasse mich stark darauf, dass ARC- und L2ARC-Caching wie erwartet funktioniert (bitte beachten Sie, dass das Problem auch dazu führt, dass L2ARC nicht auf eine vernünftige Größe wächst). Dies ist sicherlich kein Problem falsch interpretierter Statistiken.

Auch wenn Sie sich möglicherweise nicht zu stark auf ARC / L2ARC verlassen, können Sie es wahrscheinlich reproduzieren, indem Sie eine große Datei (die normalerweise in Ihren RAM passt) mehrmals mit dd lesen . Sie werden wahrscheinlich feststellen, dass das erste Lesen der Datei tatsächlich schneller ist als alle aufeinander folgenden Lesevorgänge derselben Datei (aufgrund der lächerlichen ARC-Größe und unzähliger Cache-Räumungen).

Bearbeiten: Ich habe es jetzt geschafft, einen IDR-Patch von Oracle zu erhalten, der dieses Problem behebt. Wenn Ihr System unterstützt wird, sollten Sie nach dem IDR-Patch für CR 7111576 fragen. Der Patch gilt für Solaris 11 11/11 mit SRU3.


Ich glaube, ich werde unterstützt, aber ich arbeite in einem massiven Unternehmen. Wer weiß?
wachsen

1

Sie haben die Statistiken geändert.

Oracle Solaris 11 hat die folgenden Statistiken aus zfs entfernt: 0: arcstats:

  • evict_l2_cached
  • evict_l2_eligible
  • evict_l2_ineligible
  • evict_skip
  • hdr_size
  • l2_free_on_write
  • l2_size recycle_miss

und fügte Folgendes zu zfs hinzu: 0: arcstats:

  • buf_size
  • meta_limit
  • meta_max
  • meta_used

Dies könnte also im Grunde nur ein Problem mit Ihrem Skript sein.


Es ist ein interessanter Punkt, aber ich glaube nicht, dass ich eine dieser Metriken verwende, um diese Zahlen zu melden. Siehe Bearbeiten.
wachsen

Die sind tatsächlich noch hier. In Anbetracht dessen sieht das sehr seltsam aus. Sehen Sie irgendeine Art von Leistungsabfall?
Juwi

Ich kann nicht sagen, dass ich habe. Ich sollte das wahrscheinlich messen.
wachsen

Für den Fall, dass dies kein Fehler in dem ist, was Sie betrachten, und Sie dort wirklich eine Seltsamkeit haben, beachten Sie bitte, dass Sie diese Werte im laufenden Betrieb auf einem Live-System oder dauerhaft mit / etc / system ändern können.
Nex7
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.