Nieoczekiwana (?) Wysoka „zmarnowana” pamięć w pamięci memcached

18

Zaktualizowano, patrz na dole długiego (przepraszającego) pytania.

Patrząc na nasze zapamiętane statystyki, myślę, że znalazłem problem, o którym wcześniej nie wiedziałem. Wygląda na to, że mamy dziwnie dużą ilość zmarnowanej przestrzeni. Sprawdziłem zmiany w phpmemcacheadmin i znalazłem ten obraz, który na mnie patrzył:

grafika wielkości pamięci podręcznej

Teraz miałem wrażenie, że najgorszym scenariuszem byłoby 50% marnotrawstwa, chociaż jako pierwszy przyznam, że nie znam wszystkich szczegółów. Przeczytałem - między innymi - tę stronę, która jest rzeczywiście nieco stara, ale taka jest też nasza wersja memcached. Wydaje mi się, że rozumiem, jak działa system ( np. ), Ale trudno mi zrozumieć, w jaki sposób możemy uzyskać 76% zmarnowanej przestrzeni.

Wskaźnik eksmisji pokazany przez phpmemcacheadmin jest 2 ev/s, więc jest tutaj pewien problem.

  • Podstawowe pytanie brzmi: co mogę zrobić, aby to naprawić . Mógłbym wrzucić w to więcej pamięci (myślę, że jest trochę więcej dostępnych), może powinienem majstrować przy konfiguracji płyty (czy to w ogóle możliwe w tej wersji?), Może są inne opcje? Aktualizacja wersji memcached nie jest szybką opcją.

  • Drugie pytanie, z ciekawości, brzmi oczywiście, czy oczekuje się 75% (i rosnącej) marnowanej powierzchni, a jeśli tak, to dlaczego.

System: Obecnie nie mogę nic na to poradzić, wiem, że wersja memcached nie jest najnowsza, ale to są karty, które dostałem.

  • Memcached 1.4.5
  • Apache 2.2.17
  • PHP 5.3.5

W odpowiedzi na odpowiedź @DavidSchwartz: oto statystyki płyt, które generuje phpmemcacheadmin: (oprócz tych płyt jest więcej)

( Wkleiłem też statystyki nieco później w formacie tekstowym )

Szczegóły płyty

AKTUALIZACJA

Zrestartowałem demona z opcją -f 1.5 i wyglądało to naprawdę dobrze. Po pewnym ociepleniu zużyliśmy / zmarnowaliśmy 50/50. Ale podobnie jak poprzednio, im dłużej mieliśmy w ciągu dnia (robi się coraz bardziej ruchliwie w ciągu dnia), zaczęło wracać do obecnego poziomu: 30/70, a zmarnowane wciąż rośnie. Poza tym wciąż nie wiem, skąd pochodzi „zmarnowany”. Widzę tę płytę:

**Slab 5 Stats**
Chunk Size  496.0 Bytes
Used Chunk  77502 [24.6 %]
Total Chunk 314986
Total Page  149
Wasted      117.3 MBytes
Hits        30.9 Request/sec
Evicted     0

Nie jest pełny, nie ma eksmisji, ale marnuje 117,3 MB. Szybka kalkulacja, którą zrobiłem (popraw mnie, jeśli się mylę) to:

  • poprzednia płyta ma rozmiar fragmentu 328, więc najgorszy przypadek jest wypełniony fragmentami 329 bajtów.
  • oznacza to, że marnuje 167 bajtów na wykorzystaną porcję = 12942834 bajtów = 12,3 MB

Skąd więc wzięło się pozostałe 105 MB zmarnowanych ? To większy brat tuż obok wygląda tak:

**Slab 6 Stats** 
Chunk Size  744.0 Bytes
Used Chunk  17488 [31.0 %]
Total Chunk 56360
Total Page  40
Wasted      31.1 MBytes
Hits        107.7 Request/sec
Evicted     1109
Nanne
źródło
Problem polega na tym, że w innych płytach jest mnóstwo niewykorzystanego miejsca, ale płyta 3 jest w 100% pełna i widzimy eksmisje.
David Schwartz,
Dobrze, że to wyjaśniałoby eksmisje, chociaż tak naprawdę nie jestem pewien, jak obliczana jest „zmarnowana” liczba. Jeśli na płycie 8 wykorzystano tylko 13,9%, to na pewno musi pozostać trochę „wolnego” miejsca?
Nanne
Tak, na tej płycie jest wolne miejsce. Ale to nie pomaga, jeśli eksmitowane obiekty nie wchodzą w tę płytę.
David Schwartz
Tak właśnie wymyśliłem na podstawie twojej odpowiedzi, ale dlaczego nie ma na liście wolnego miejsca? Powinna być jakaś część tego białego wykresu kołowego (tak jak jest na mojej instalacji testowej), jeśli przynajmniej pozostało wolne miejsce, przynajmniej tak właśnie wymyśliłem
Nanne

Odpowiedzi:

10

Minęło rok od tego pytania i nie wiem, czy znalazłeś odpowiedź, ale powiem, że twoje postrzeganie „zmarnowanego” jest złe.

Zmarnowana pamięć jest przydzielana w pamięci, więc nie może być używana przez inną aplikację, ale nadal jest dostępna do pamięci memcached.

Aby uprościć wyjaśnienie, załóż, że masz pamięć podręczną z 3 MB pamięci RAM z 3 płytami:

slab class  1: chunk size     10485 perslab      100
slab class  2: chunk size    104857 perslab       10
slab class  3: chunk size   1048576 perslab        1

Wykonaj pojedynczy „zestaw” o rozmiarze 10k. W swoich statystykach (z grubsza) zobaczysz, że masz:

0.03% used
66.6% free
33% wasted

Wynika to z faktu, że Memcached przydzielił pojedynczy fragment z „klasy płyty 1”, a 99% pamięci dla tej płyty jest „zmarnowane”, a 1% jest „wykorzystane”. Nie oznacza to, że płyta i pamięć przydzielona dla tej płyty zniknęły.

Wykonaj kolejny pojedynczy „zestaw” o rozmiarze 10k. Tym razem zobaczysz:

0.06% used
66.6% free
32.7% wasted

więc teraz używasz 2 na 100 przydzielonych porcji w płycie 1, statystyki „zmarnowane” spadły, a statystyki używane wzrosły.

Nie ma nic złego w tym, że użyty% + zmarnowany% jest równy 100%. Nie oznacza to, że nie ma już więcej pamięci, oznacza to po prostu, że przydzielono co najmniej jeden fragment z każdej płyty.

Aby zobaczyć ten problem, „zestaw” o rozmiarze 100k i kolejny o rozmiarze 1000k

Teraz zobaczysz

36.6% used
   0% free
63.3% wasted
kali
źródło
To brzmi dobrze! Czy masz link do utworzenia kopii zapasowej? Jeśli tak, oznacza to, że mój serwer memcache działał (jest) lepiej, niż myślimy :). Jeśli dobrze cię rozumiem, oznacza to, że zmarnowany oznacza, że ​​został przydzielony, ale nadal jest dostępny do użycia. Oznacza to, że jeśli nic nie jest za darmo, nie możesz przydzielić więcej płyt, ale nie powinno to oznaczać, że masz problem sam w sobie?
Nanne
1
Nie mam linku na głowie, ale bardzo łatwo jest się sprawdzić. Naciśnij linię poleceń i utwórz przykładowy mały serwer, aby sprawdzić, jak to działa. Możesz użyć opcji -vv dla pełnych komunikatów debugowania, które pokażą ci początkowo utworzone płyty, tj .: „memcached -vv -p 11500 -m 3 -n 10000 -f 10” utworzy ci 3 płyty o wielkości fragmentów 10k 100k i 1000k. Wydawaj „zestawy” i zobacz, jak zmarnowane / używane statystyki zmieniają się dokładnie tak, jak to opisano powyżej.
kali
Słuszna uwaga. teraz, aby dowiedzieć się, w jaki sposób mogę uzyskać dla ciebie dodatkową uwagę :)
Nanne
6

Prawdopodobnie masz bardzo dużą liczbę bardzo małych obiektów. Zwykle najmniejsza płyta zawiera 104-bajtowe wpisy. Jeśli masz wiele wpisów, które odwzorowują tylko jedną liczbę całkowitą na drugą, możesz zmarnować nawet 85%.

Informacje o tym, jak obejść ten problem, można znaleźć w artykule Memcached dla małych obiektów .

David Schwartz
źródło
Jeśli poprawnie przeczytałem stronę statystyk, tak nie jest. Większość odpadów znajduje się na płycie zawierającej 480,0 bajtów. Pozwól, że sprawdzę, czy mogę pokazać statystyki ...
Nanne
Och, to jest w porządku i normalne, nie ma się czym martwić. Teraz jest tam po prostu mniej danych. (Zauważ na przykład, że ta płyta jest używana tylko w 14%.)
David Schwartz
Ale w jaki sposób 75% jest marnowane normalnie? Czy liczba ta obejmuje niewykorzystane miejsce? Spodziewałbym się, że będzie to liczone jako „darmowe”. Widzimy także wzrost zmarnowanej // zmniejszenia zużytej pamięci w miarę upływu dnia, podczas gdy strona staje się bardziej zajęta. To i fakt, że mamy eksmisje, każe mi się zastanawiać, co można zrobić.
Nanne
Posiadanie mniejszej liczby płyt może pomóc uniknąć problemu, że zbyt dużo pamięci utknie na niewłaściwej płycie. Na przykład -f 1.5 -I 2800może pomóc.
David Schwartz
Strona podręcznika nie jest zbyt jasna: -I 2800oznacza to 2800 KB, w przeciwieństwie do domyślnego 1M?
Nanne
-1

Miałem ten problem i przeniosłem się z Memcached na Redis (bez zapisywania na dysku). Wiem, że może to nie być możliwe, ale możesz wypróbować to jako opcję i pilnować fragmentacji pamięci. Możesz nawet włączyć trwałość, aby naprawić problemy ze „starą pamięcią podręczną” przy ponownym uruchomieniu.

genealogia
źródło