Jak znaleźć, co używa wymiany linux lub co jest w zamianie?


12

Mam wirtualny serwer linux (Fedora 17) z 28 GB pamięci RAM i 2 GB wymiany. Serwer działa z bazą danych MySQL skonfigurowaną do korzystania z większości pamięci RAM.

Po pewnym czasie serwer zaczyna używać swap do zamiany niepotrzebnych stron. To dobrze, ponieważ moja zamiana wynosi domyślnie 60 i jest to oczekiwane zachowanie.

Dziwne jest to, że liczba w top / meminfo nie odpowiada informacjom z procesów. Czyli serwer zgłasza te liczby:

/proc/meminfo:
SwapCached:        24588 kB
SwapTotal:       2097148 kB
SwapFree:         865912 kB

top:
Mem:  28189800k total, 27583776k used,   606024k free,   163452k buffers
Swap:  2097148k total,  1231512k used,   865636k free,  6554356k cached

Jeśli użyję skryptu z /server//a/423603/98204 , zgłasza rozsądne liczby (kilka MB zamienionych przez bash'es, systemd itp.) I jeden duży przydział z MySQL (pominąłem wiele wierszy wyjściowych ):

892        [2442] qmgr -l -t fifo -u
896        [2412] /usr/libexec/postfix/master
904        [28382] mysql -u root
976        [27559] -bash
984        [27637] -bash
992        [27931] SCREEN
1000       [27932] /bin/bash
1192       [27558] sshd: admin@pts/0
1196       [27556] sshd: admin [priv]
1244       [1] /usr/lib/systemd/systemd
9444       [26626] /usr/bin/perl /bin/innotop
413852     [31039] /usr/libexec/mysqld --basedir=/usr --datadir=/data/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/data/mysql/err --open-files-limit=8192 --pid-file=/data/mysql/pid --socket=/data/mysql/mysql.sock --port=3306
449264   Total Swap Used

Jeśli więc poprawnie otrzymam wynik skryptu, całkowite użycie wymiany powinno wynosić 449264 K = ok. 440 MB z mysql przy użyciu ok. 90% zamiany.

Pytanie brzmi, dlaczego tak bardzo różni się od górnego i meminfo? Czy jest jakiś sposób, aby „zrzucić” informacje o zamianie, aby zobaczyć, co faktycznie w niej jest, zamiast sumowania zużycia wymiany ze wszystkich procesów?

Analizując problem, wpadłem na różne pomysły, ale wszystkie wydają się błędne:

  1. Dane wyjściowe skryptu nie są w KB. Nawet gdyby był w jednostkach 512 lub 4KB, nie będzie pasował. W rzeczywistości stosunek (1200: 440) wynosi około 3: 1, co jest liczbą „dziwną”.
  2. Niektóre strony w swap są w jakiś sposób współdzielone między procesami, jak wspomniano w /server//a/477664/98204 . Jeśli to prawda, jak mogę znaleźć rzeczywistą liczbę pamięci używaną w ten sposób? To znaczy, że musiałoby to zrobić około 800 MB różnicy. I to nie brzmi dobrze w tym scenariuszu.
  3. Istnieje kilka „starych” stron w zamianie używanych przez procesy, które już się zakończyły. Nie miałbym nic przeciwko, że gdybym mógł dowiedzieć się, ile kosztuje ta „bezpłatna” zamiana.
  4. Są strony w swapie, które zostały zamienione z powrotem do pamięci i są zamieniane na wypadek, gdyby nie zmieniły się w pamięci RAM i muszą zostać ponownie wymienione, jak wspomniano w /server//a/100636/98204 . Ale wartość SwapCached wynosi tylko 24 MB.

Dziwne jest to, że użycie wymiany powoli rośnie, podczas gdy suma danych wyjściowych skryptu jest mniej więcej taka sama. W ciągu ostatnich 3 dni liczba używanych swapów wzrosła z 1100 MB do obecnych 1230 MB, a suma wzrosła z 430 MB do obecnych 449 MB (ok.).

Serwer ma wystarczającą ilość wolnej (zdolnej) pamięci RAM, więc mogłem po prostu wyłączyć swap i włączyć go ponownie. Lub prawdopodobnie mógłbym ustawić swapiness na 0, więc zamiana przyda się tylko wtedy, gdy nie ma innej możliwości. Chciałbym jednak rozwiązać problem lub przynajmniej dowiedzieć się, co jest tego przyczyną.


Jak mówisz, powinieneś po prostu ustawić vm.swappiness = 0 (lub 1) i swapoff && swapon
HTTP500

Ale to nie rozwiązałoby problemu. Zakładam, że zamiana zacznie ponownie rosnąć, jeśli ustawię swapiny z powrotem na 60 lub w ogóle nie będzie używana, jeśli utrzymam ją na 0 lub 1 (chyba że serwer skończy się w pamięci)
Radek Hladík

Jeśli jest to serwer DB, powinien używać swap tylko w sytuacjach awaryjnych, dlatego zawsze należy ustawić go na 0 (lub 1).
HTTP500

To prawda i prawdopodobnie to zrobię, jeśli nie znajdę przyczyny tego problemu ... Z drugiej strony na serwerze jest wiele małych DB, które są używane bardzo sporadycznie i podobał mi się pomysł zamieniane przez system, gdy nie są w użyciu ... jednak przypuszczam, że MySQL będzie mógł poradzić na własną rękę ...
Radek HLADÍK

Mysql radzi sobie całkiem dobrze z zarządzaniem własnymi pamięciami podręcznymi, ale opiera się to na założeniach dotyczących tego, co tak naprawdę jest w pamięci, a co nie. Jeśli spróbujesz zgadnąć, używając pamięci wymiany, po prostu upośledzasz zdolność mysql do decydowania, co należy buforować, a co nie. Wyłącz zamianę. JEŚLI uderzysz w swap, to błąd w tuningu. Dostosuj rozmiary pamięci podręcznej, aby wymiana nigdy się nie zdarzyła, ale poza tym chcesz wykorzystać całą dostępną pamięć fizyczną.
mc0e,

Odpowiedzi:


9

Fedora 18 i nowsze mają smemw repozytoriach. Możesz pobrać skrypt Pythona i zainstalować ze źródła .

Oto przykładowe wyjście (nieco wycięte i anonimowe) z mojej maszyny:

# smem -s swap -t -k -n
  PID User     Command                         Swap      USS      PSS      RSS 
20917 1001     bash                               0     1.1M     1.1M     1.9M 
28329 0        python /bin/smem -s swap -t        0     6.3M     6.5M     7.4M 
 2719 1001     gnome-pty-helper               16.0K    72.0K    73.0K   516.0K 
  619 0        @sbin/mdadm --monitor --sca    28.0K    72.0K    73.0K   248.0K 

[big snip]

32079 42       gnome-shell --mode=gdm         41.9M     1.9M     2.0M     5.0M 
32403 1001     /opt/google/chrome/chrome -    43.1M   118.5M   119.4M   132.3M 
 4844 1002     /opt/google/chrome/chrome      48.1M    38.1M    41.9M    51.9M 
 5411 1002     /opt/google/chrome/chrome -    54.6M    33.4M    33.5M    36.8M 
 5624 1002     /opt/google/chrome/chrome -    72.4M    54.9M    55.5M    65.7M 
24328 1002     /opt/Adobe/Reader9/Reader/i    77.5M     1.9M     2.0M     5.2M 
 4921 1002     /opt/google/chrome/chrome -   147.2M   258.4M   259.4M   272.0M 
-------------------------------------------------------------------------------
  214 14                                       1.1G     1.1G     1.2G     1.7G 

Źródło zapewnia również, smemcapże będzie przechowywać wszystkie odpowiednie dane, aby smem można było uruchomić na nim później.

   To  capture  memory statistics on resource-constrained systems, the the
   smem source includes a utility named  smemcap.   smemcap  captures  all
   /proc entries required by smem and outputs them as an uncompressed .tar
   file to STDOUT.  smem can analyze the output using the --source option.
   smemcap is small and does not require Python.

1
Smem z repozytorium F17 nie działał (pokazał pustą listę), ale ten ze źródła działał i pokazuje prawie takie same liczby jak inne :-) mysql 358,1 mln z 392,6 mln ogółem, podczas gdy najlepsze pokazy 1191224k używane
Radek Hladík

4

Powinieneś sprawdzić ten skrypt na innym komputerze, ponieważ mój system pokazuje prawidłowe użycie wymiany:

# Your_script.sh
111280   Total Swap Used
# free
Swap:     33551716     120368   33431348

Bardzo blisko 111280 ~ = 120368.

Zobacz także ten skrypt:

dla proc w / proc / *; do cat $ proc / smaps 2> / dev / null | awk '/ Swap / {swap + = 2 $} END {print swap "\ t' readlink $proc/exe'"}'; zrobione | sort -n | awk '{total + = 1 $} / [0-9] /; END {print total "\ tTotal"}'

Z tego wątku:

/unix/71714/linux-total-swap-used-swap-used-by-processes


Wspomniany skrypt zwraca te same wyniki ... 364920 / usr / libexec / mysqld 400372 Total
Radek Hladík

Kiedy próbowałem skryptu na innym serwerze o bardzo niskim zużyciu wymiany (50 MB), w sumie zgłoszono około 72 MB :-) Będę musiał go później zasymulować na jakimś nieprodukcyjnym serwerze ...
Radek Hladík
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.