Mam hosta produkcyjnego poniżej:

System wykorzystuje 1 GB swapu, zachowując prawie 40 GB wolnego, nieużywanego miejsca w pamięci. Czy powinienem się tym przejmować, czy jest to w większości normalne?

To nie jest problem i prawdopodobnie jest normalne. Dużo kodu (i ewentualnie danych) jest używanych bardzo rzadko, więc system podmieni go, aby zwolnić pamięć.

Zamiana jest głównie problemem tylko wtedy, gdy pamięć jest ciągle wymieniana. Jest to rodzaj działania, które zabija wydajność i sugeruje problem w innym miejscu w systemie.

Jeśli chcesz monitorować aktywność wymiany, możesz to zrobić za pomocą kilku narzędzi, ale vmstatzwykle jest to bardzo przydatne np

$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 348256  73540 274600    0    0     1     9    9    6  2  0 98  0  0
 0  0      0 348240  73544 274620    0    0     0    16   28   26  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   29   33  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   21   23  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   24   26  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   23   23  0  0 100  0  0

Zignoruj ​​pierwszy wiersz, ponieważ jest to aktywność od momentu uruchomienia systemu. Zwróć uwagę na kolumny sii sopod ---swap--; zazwyczaj powinny być to dość małe cyfry, jeśli nie 0, przez większość czasu.

Warto również wspomnieć, że ta zapobiegawcza zamiana może być kontrolowana za pomocą ustawienia jądra. Plik at /proc/sys/vm/swappinesszawiera liczbę od 0 do 100, która informuje jądro, jak agresywnie wymienia pamięć. Cat plik, aby zobaczyć, co to jest ustawione. Domyślnie większość Linuksów domyślnie przyjmuje wartość 60, ale jeśli nie chcesz widzieć zamiany przed wyczerpaniem pamięci, wyświetl 0 w pliku w następujący sposób:

echo 0 >/proc/sys/vm/swappiness

Można to zrobić na stałe, dodając

vm.swappiness = 0

do /etc/sysctl.conf.

Linux uprzednio wypisze strony na dysk, jeśli nie ma nic lepszego do roboty. Że ma nie znaczy, że będzie eksmitować tych stron z pamięci, choć. Tyle, że na wypadek, gdyby kiedyś musiał wyrzucić te strony, nie musi czekać, aż zostaną zapisane na dysk, ponieważ już tam są.

W końcu kończy Ci się pamięć, prawdopodobnie dlatego, że twój komputer już ciężko pracuje, nie chcesz dodatkowo obciążać go wymianą. Lepiej zrobić wymianę, gdy maszyna nic nie robi.

Z podobnego powodu twoja pamięć powinna być zawsze pełna. Strony pamięci, pamięć podręczna systemu plików, tmpfsjest tak wiele rzeczy, które można przechowywać w pamięci. Naprawdę powinieneś się martwić, jeśli twoja pamięć jest pusta; w końcu zapłaciłeś za to dużo pieniędzy (przynajmniej w porównaniu z taką samą ilością miejsca na dysku), więc lepiej go wykorzystać!

Wykorzystanie swapu nie jest złe, ale jest dużo aktywności swapowej

  vmstat 1
  procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
  6  0 521040 114564   6688 377308    8   13   639   173    0 1100  5  4 90  0
  1  0 521040 114964   6688 377448    0    0   256     0    0 1826  3  4 94  0
  0  0 521040 115956   6688 377448    0    0     0     0    0 1182  7  3 90  0
  0  0 521036 115992   6688 377448    4    0    16     0    0 1154 10  2 88  0
  3  0 521036 114628   6696 377640    0    0   928   224    0 1503 15 17 67  1

Zamiana kolumn nie stanowi żadnego problemu. Niezerowe wartości w kolumnach si, a zatem są śmiertelne dla wydajności serwera. Zwłaszcza te z dużą ilością pamięci RAM.

Najlepiej wyłączyć swapinness na maszynach z kilkoma GB pamięci RAM:

sysctl -w vm.swappiness=0

Nie spowoduje to wyłączenia wymiany. Poinstruuje Linuksa, aby użył wymiany jako ostatecznego środka. To zmarnuje kilka MB programów, które nie muszą znajdować się w pamięci RAM ... Ale lepiej jest zamienić wzdęte kolejki dostępu do dysku.

Edycja 1: dlaczego domyślna wartość swapiness nie jest optymalna

Pamiętamy dwie dekady temu, że duży 486 miał tylko 32 MB pamięci RAM. Algorytmy wymiany zostały opracowane, gdy cała pamięć RAM mogła zostać przeniesiona na dysk w ułamku sekundy. Nawet z wolniejszymi dyskami tego czasu. Dlatego domyślne zasady zamiany są tak agresywne. RAM był w tych czasach wąskim gardłem. Od tego czasu rozmiar pamięci RAM wzrósł ponad 10 000 razy, a prędkość dysku mniej niż 10 razy. Spowodowało to przesunięcie wąskiego gardła do przepustowości dysku.

Edycja 2: dlaczego taka aktywność jest zabójcza dla serwerów?

Si i tak aktywność na komputerach z tonami pamięci RAM jest zabójcza, ponieważ oznacza, że ​​system sam z sobą walczy o pamięć RAM. Co się dzieje, dyski, nawet duże magazyny, są zbyt wolne w porównaniu do pamięci RAM. Agresywna zamiana faworyzuje pamięć podręczną dysku jądra w stosunku do danych aplikacji i jest najczęstszym źródłem walki o pamięć RAM. Ponieważ system operacyjny będzie musiał zwolnić pamięć podręczną dysku na każdym si , czas życia dodatkowej pamięci podręcznej zapewnianej przez swap jest zbyt krótki, aby i tak był użyteczny. Powoduje to, że zabierasz przepustowość dysku do przechowywania pamięci podręcznej, która prawdopodobnie nie zostanie wykorzystana, i wstrzymujesz programy czekające na strony si . Oznacza to, że zużywa dużo zasobów krytycznych przy niewielkich lub zerowych korzyściach dla aplikacji.

Zwróć uwagę na tytuł odpowiedzi „duża aktywność wymiany na serwerach z dużą ilością pamięci RAM”. Nie dotyczy to maszyn z okazjonalną si i tym samym aktywnością. Może to nie mieć zastosowania w przyszłości, jeśli w systemach operacyjnych zostaną opracowane inteligentniejsze algorytmy wymiany.

Edycja 3: „zimne” strony

Ludzie romantyzują algorytm zamiany. Niektórzy twierdzą, że „zajmuje mniej stron RAM”, ale jądro wcale tego nie robi. Rzeczą trudną do zrozumienia w kwestii zamiany jest to, że jądro nie wie, co to jest „zimna strona”. Jądro nie ma dobrych danych pozwalających ustalić, czy strona zostanie użyta, czy może być używana w najbliższej przyszłości. Aby obejść, że jądro umieszcza strony w swapie mniej więcej losowo, a strony, które nie są potrzebne, pozostają tam. Problemem tego algorytmu jest to, że strony muszą przejść do wymiany, aby dowiedzieć się, czy są potrzebne aplikacjom. A to oznacza, że ​​wiele „gorących” stron trafi do wymiany. Problem polega na tym, że dyski są zbyt powolne w porównaniu do pamięci RAM.

Zbudowałem własny test porównawczy, który jest realistycznym scenariuszem bardzo powszechnym w wielu aplikacjach o przyzwoitej głośności. Z moich testów nie zauważyłem żadnych korzyści w zakresie przepustowości ani opóźnień, gdy używane są swapy. Daleko stąd. Po rozpoczęciu zamiany spowalnia zarówno przepustowość, jak i opóźnienie o co najmniej rząd wielkości.

Idę trochę dalej: rozumiem, że zamiana nie jest przeznaczona do przetwarzania. Zamiany są tylko w nagłych wypadkach. Te chwile, kiedy jednocześnie działa zbyt wiele aplikacji i następuje skok pamięci. Bez zamiany spowodowałoby to błędy braku pamięci. Uważam, że użycie wymiany jest porażką zespołów programistów i producentów. To tylko opinia, która wykracza daleko poza to, o czym tutaj mówiliśmy, ale tak myślę. Oczywiście moje aplikacje same mają doskonałe zarządzanie pamięcią.

To nie jest odpowiedź na twoje pytanie; ale raczej dodatkowe informacje, które pomogą Ci podjąć świadomą decyzję.

Jeśli chcesz wiedzieć, jakie procesy wykorzystują ile swapów, oto mały skrypt powłoki:

#!/bin/bash

set -o posix
set -u

OVERALL=0
for DIR in `find /proc/ -maxdepth 1 -type d -regex "^/proc/[0-9]+"` ; do
  PID=`echo $DIR | cut -d / -f 3`
  PROGNAME=`ps -p $PID -o comm --no-headers`

  SUM=0
  for SWAP in `grep Swap $DIR/smaps 2>/dev/null| awk '{ print $2 }'` ; do
    let SUM=$SUM+$SWAP
  done
  echo "PID=$PID - Swap used: $SUM - ($PROGNAME )"

  let OVERALL=$OVERALL+$SUM
done
echo "Overall swap used: $OVERALL"

Powinienem również dodać, że tmpfs również się zamieni. Jest to bardziej powszechne w nowoczesnych systemach Linux wykorzystujących systemd, które tworzą nakładki przestrzeni użytkownika / tmp za pomocą tmpfs.

Zauważyłem, że replikacja klastra MySQL spowalnia lub kończy się niepowodzeniem, gdy agenci znacznie się podmieniają. Być może niektóre aplikacje nie mają nic przeciwko, a może nawet korzystają z wymiany, ale bazy danych naprawdę cierpią z tego powodu. Jednak wiele dyskusji, które widziałem na forach dyskusyjnych, wymieniają swapy zdekontekstualizowane z konkretnej dyskusji obciążenia pracą.

W świecie DBA wydaje się, że konsensus brzmi: „Powszechnie uważa się, że kiedy korzystasz z MySQL (lub naprawdę dowolnego innego DBMS), nie chcesz widzieć żadnych operacji we / wy w swoim obszarze wymiany. Skalowanie rozmiaru pamięci podręcznej (przy użyciu innodb_buffer_pool_size w przypadku MySQL) to standardowa praktyka zapewniająca wystarczającą ilość wolnej pamięci, aby wymiana nie była potrzebna.

Ale co, jeśli popełnisz błąd lub przeliczysz, a zamiana nastąpi? Jak bardzo to wpływa na wydajność? Właśnie to postanowiłem zbadać. „

Mam nadzieję, że czytelnicy znajdą następujące linki apropos.

https://www.percona.com/blog/2017/01/13/impact-of-swapping-on-mysql-performance/

https://www.percona.com/blog/2010/01/18/why-swapping-is-bad-for-mysql-performance/