Bagaimana menemukan apa yang menggunakan swap linux atau apa yang ada di swap?


12

Saya memiliki server linux (Fedora 17) virtual dengan 28GB RAM dan 2GB swap. Server menjalankan DB DB yang diatur untuk menggunakan sebagian besar RAM.

Setelah beberapa waktu berjalan server mulai menggunakan swap untuk menukar halaman yang tidak dibutuhkan. Itu bagus karena swappiness saya ada di default 60 dan itu adalah perilaku yang diharapkan.

Yang aneh adalah bahwa angka di atas / meminfo tidak sesuai dengan info dari proses. Yaitu server melaporkan angka-angka ini:

/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

Jika saya menggunakan skrip dari /server//a/423603/98204 ini melaporkan angka yang masuk akal (beberapa MB ditukar dengan bash'es, systemd, dll) dan satu alokasi besar dari MySQL (saya menghilangkan banyak jalur output ):

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

Jadi jika saya mendapatkan output skrip dengan benar, total penggunaan swap harus 449264K = ca. 440MB dengan mysql menggunakan ca. 90% dari swap.

Pertanyaannya adalah mengapa ini sangat berbeda dari angka atas dan angka meminfo? Apakah ada cara bagaimana "membuang" informasi swap untuk melihat apa yang sebenarnya ada di dalamnya alih-alih menjumlahkan penggunaan swap dari semua proses?

Ketika menganalisis masalah ini, saya menemukan ide-ide yang berbeda tetapi semuanya tampaknya salah:

  1. Keluaran skrip tidak dalam KB. Bahkan jika itu akan di unit 512 atau 4KB itu tidak akan cocok. Sebenarnya rasionya (1200: 440) adalah sekitar 3: 1 yang merupakan angka "aneh".
  2. Ada beberapa halaman dalam swap yang entah bagaimana dibagikan antar proses seperti yang disebutkan dalam /server//a/477664/98204 . Jika ini benar, bagaimana saya dapat menemukan jumlah sebenarnya dari memori yang digunakan seperti ini? Maksud saya perlu membuat perbedaan 800MB CCA. Dan itu tidak terdengar benar dalam skenario ini.
  3. Ada beberapa halaman "lama" dalam swap yang digunakan oleh proses yang sudah selesai. Saya tidak keberatan jika saya bisa mengetahui berapa swap "gratis" ini.
  4. Ada halaman dalam swap yang telah ditukar kembali ke memori dan dalam swap kalau-kalau mereka tidak berubah dalam RAM dan perlu ditukar lagi seperti yang disebutkan dalam /server//a/100636/98204 . Tetapi nilai SwapCached hanya 24MB.

Yang aneh adalah bahwa penggunaan swap perlahan meningkat sementara jumlah output dari skrip kira-kira sama. Dalam 3 hari terakhir swap yang digunakan meningkat dari 1100MB menjadi 1230MB saat ini sementara jumlahnya meningkat dari 430MB menjadi 449MB saat ini (ca.).

Server memiliki cukup RAM (mampu) sehingga saya bisa mematikan swap dan menyalakannya kembali. Atau saya mungkin bisa mengatur swappiness ke 0 sehingga swap hanya akan digunakan jika tidak ada cara lain. Tapi saya ingin menyelesaikan masalah atau setidaknya mencari tahu apa penyebabnya.


Seperti yang Anda katakan, Anda harus mengatur vm.swappiness = 0 (atau 1) dan swapoff && swapon
HTTP500

Tapi itu tidak akan menyelesaikan masalah. Saya mengasumsikan bahwa swap akan mulai meningkat lagi jika saya mengatur swappines kembali ke 60 atau tidak akan digunakan sama sekali jika saya menyimpannya pada 0 atau 1 (kecuali server kehabisan memori)
Radek Hladík

Jika ini adalah DB Server, ia hanya boleh menggunakan swap dalam keadaan darurat sehingga Anda harus selalu mengaturnya ke 0 (atau 1).
HTTP500

Itu benar dan mungkin itulah yang akan saya lakukan jika saya tidak menemukan penyebab masalah ini ... Di sisi lain ada banyak DB kecil di server yang digunakan sangat sporadis dan saya menyukai ide mereka sedang ditukar oleh sistem ketika mereka sedang tidak digunakan ... Namun saya kira MySQL akan dapat menanganinya sendiri ...
Radek Hladík

Mysql melakukan pekerjaan yang cukup baik dalam mengelola cache-nya sendiri, tetapi itu didasarkan pada asumsi tentang apa yang sebenarnya ada dalam memori dan apa yang tidak. Jika Anda mencoba menebak dua kali dengan menggunakan memori swap, Anda hanya mengganggu kemampuan mysql untuk memutuskan apa yang perlu di-cache dan apa yang tidak. Matikan swap. JIKA Anda menekan swap, itu kegagalan tuning. Sesuaikan ukuran cache Anda sehingga swap tidak pernah terjadi, tetapi singkatnya, Anda ingin memanfaatkan semua memori fisik yang tersedia.
mc0e

Jawaban:


9

Fedora 18 ke atas ada smemdi repo. Anda dapat mengunduh skrip python dan menginstal dari sumber .

Berikut ini contoh keluaran (agak terpotong dan dianonimkan) dari mesin saya:

# 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 

Sumber juga menyediakan smemcapyang akan menyimpan semua data yang relevan sehingga smem dapat dijalankan nanti.

   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 dari repo F17 tidak berfungsi (menunjukkan daftar kosong) tetapi yang dari sumbernya bekerja dan menunjukkan angka yang hampir sama dengan yang lain :-) mysql 358.1M dari total 392.6M, sementara pertunjukan top 1191224k digunakan
Radek Hladík

4

Anda harus memeriksa skrip ini di komputer lain, karena sistem saya menunjukkan penggunaan swap yang benar:

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

Sangat dekat 111280 ~ = 120368.

Lihat juga skrip ini:

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

Dari utas ini:

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


Skrip yang disebutkan mengembalikan hasil yang sama ... 364920 / usr / libexec / mysqld 400372 Total
Radek Hladík

Ketika saya mencoba skrip di server lain dengan penggunaan swap yang sangat rendah (50MB) dilaporkan cca 72MB total :-) Saya akan perlu untuk mensimulasikannya di beberapa server nonproduksi nanti ...
Radek Hladík
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.