Od czasu aktualizacji do Solaris 11, mój rozmiar ARC konsekwentnie wycenia 119 MB, pomimo 30 GB pamięci RAM. Co? Dlaczego?

Uruchomiłem urządzenie NAS / SAN w systemie Solaris 11 Express przed wydaniem systemu Solaris 11. Pudełko to HP X1600 z dołączonym D2700. W sumie 12 x 1 TB dysków SATA 7200, 12 x 300 GB dysków 10k SAS 10k w osobnych basenach zpool. Całkowita pamięć RAM wynosi 30 GB. Świadczone usługi to CIFS, NFS i iSCSI.

Wszystko było dobrze i miałem wykres zużycia pamięci ZFS, który wygląda tak:

Dość zdrowy rozmiar łuku około 23 GB - wykorzystanie dostępnej pamięci do buforowania.

Potem jednak zaktualizowałem system do Solaris 11, kiedy to się pojawiło. Teraz mój wykres wygląda następująco:

Częściowa produkcja arc_summary.plto:

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)

Jego celowanie to 119 MB, gdy siedzi przy 915 MB. Ma 30 GB do gry. Dlaczego? Czy coś zmienili?

Edytować

Dla wyjaśnienia, arc_summary.plnależy do Bena Rockwooda, a odpowiednie linie generujące powyższe statystyki to:

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};

Wpisy Kstat już tam są, po prostu wyciągam z nich nieparzyste wartości.

Edytuj 2

Właśnie zmierzyłem rozmiar łuku za pomocą arc_summary.pl- zweryfikowałem te liczby za pomocą 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)

Uderza mnie to, że rozmiar docelowy wynosi 119 MB. Patrząc na wykres, jest on ukierunkowany na dokładnie taką samą wartość (124,91 mln według kaktusów, 119 mln według arc_summary.pl- myślę, że różnica to tylko 1024/1000 problemów z zaokrąglaniem) od momentu zainstalowania Solaris 11. Wygląda na to, że jądro robi zero wysiłku, aby zmienić docelowy rozmiar na cokolwiek innego. Obecny rozmiar zmienia się, ponieważ potrzeby systemu (duże) walczą z wielkością docelową i wydaje się, że równowaga wynosi między 700 a 1000 MB.

Pytanie jest teraz nieco bardziej precyzyjne - dlaczego Solaris 11 ustawia mój docelowy rozmiar ARC na 119 MB i jak to zmienić? Czy powinienem zwiększyć rozmiar minimalny, aby zobaczyć, co się stanie?

Utknąłem na wyjście kstat -n arcstatsna http://pastebin.com/WHPimhfg

Edytuj 3

Ok, dziwność teraz. Wiem, że flibflob wspomniał, że była łatka, aby to naprawić. Nie zastosowałem jeszcze tej poprawki (wciąż rozwiązuję wewnętrzne problemy z obsługą) i nie zastosowałem żadnych innych aktualizacji oprogramowania.

W ubiegły czwartek pudło się rozbiło. Jak w, całkowicie przestał reagować na wszystko. Kiedy ponownie go uruchomiłem, wszystko wróciło dobrze, ale oto, jak teraz wygląda mój wykres.

Wygląda na to, że problem został rozwiązany.

To jest teraz właściwe. Dosłownie nie mam pojęcia, co się dzieje. :(

Niestety nie mogę rozwiązać Twojego problemu, ale oto kilka podstawowych informacji:

• Rozmiar docelowy ARC nie wydaje się być wartością stałą. Ten sam problem występuje na komputerze z systemem Solaris 11 i po każdym ponownym uruchomieniu w pewnym momencie rozmiar docelowy wydaje się blokować na wartości od ~ 100 do ~ 500 MB.

• Co najmniej 3 inne osoby stoją przed tym samym problemem, jak omówiono w http://mail.opensolaris.org/pipermail/zfs-discuss/2012-J January/050655.html

• Istnieje również otwarty raport o błędach (7111576) w „My Oracle Support” ( https://support.oracle.com ). Jeśli Twój serwer jest objęty ważną umową o pomoc techniczną, powinieneś złożyć zgłoszenie serwisowe i odnieść się do tego błędu. Na razie wydaje się, że wszelkie poprawki nadal trwają ...

Poza tym niewiele możesz zrobić. Jeśli jeszcze nie zaktualizowałeś wersji zpool / zfs, możesz spróbować uruchomić się w starym środowisku rozruchowym Solaris 11 Express i uruchamiać go, dopóki Oracle nie zdecyduje się na wydanie SRU, które rozwiązuje problem.

Edycja: Ponieważ kwestia obniżenia wydajności została omówiona powyżej: Wszystko zależy od tego, co robisz. Od czasu aktualizacji do wersji Solaris 11 11/11 widziałem straszne opóźnienia w moim udziale Solaris 11 NFS. Jednak w porównaniu do twojego systemu mam stosunkowo niewiele wrzecion i polegam w dużej mierze na buforowaniu ARC i L2ARC, działającym zgodnie z oczekiwaniami (pamiętaj, że problem powoduje również, że L2ARC nie rośnie do żadnego rozsądnego rozmiaru). Z pewnością nie jest to problem źle interpretowanych statystyk.

Nawet jeśli nie polegasz zbytnio na ARC / L2ARC, prawdopodobnie będziesz w stanie go odtworzyć, czytając duży plik (który normalnie mieściłby się w twojej pamięci RAM) wiele razy za pomocą dd . Prawdopodobnie zauważysz, że pierwszy odczyt pliku będzie w rzeczywistości szybszy niż jakiekolwiek kolejne odczyty tego samego pliku (ze względu na absurdalny rozmiar ARC i niezliczone eksmisje z pamięci podręcznej).

Edycja: Udało mi się teraz otrzymać poprawkę IDR od Oracle, która rozwiązuje ten problem. Jeśli twój system jest obsługiwany, powinieneś poprosić o poprawkę IDR dla CR 7111576. Poprawka dotyczy Solaris 11 11/11 z SRU3.

Zmienili kstaty.

Oracle Solaris 11 usunął następujące statystyki z zfs: 0: arcstats:

• evict_l2_cached
• evict_l2_eliable
• evict_l2_ineliable
• evict_skip
• hdr_size
• l2_free_on_write
• l2_size recycle_miss

i dodał do zfs: 0: arcstats:

• rozmiar buf
• meta_limit
• meta_max
• meta_used

Może to być po prostu problem ze skryptem.