Bagaimana saya tahu proses apa yang menyebabkan kswapd digunakan?

23

Saya melihat kswapd menggunakan CPU 100% ... bagaimana saya bisa tahu atas nama proses kswapd mana yang banyak digunakan?

— Deshawn
sumber

1

Uhm. kswapd adalah prosesnya. Ini berjalan atas nama kernel.

— mailq

Lihat serverfault.com/questions/24124/…

— PT

2

@mailq ... ya, tapi bukankah itu menukar memori ruang pengguna? dan jika demikian, bagaimana cara mengetahui memori proses yang ditukar pada saat itu?

— Deshawn

18

kswapd mengelola ruang swap dalam menanggapi permintaan memori yang lebih besar daripada yang tersedia secara fisik untuk semua proses.

Ini adalah proses agnostik, hanya tertarik pada halaman apa yang diakses dan kapan (ini lebih kompleks dari ini tentu saja tetapi untuk menjaga hal-hal yang sederhana kita juga dapat melihatnya dengan cara ini).

Jadi pertanyaan sebenarnya adalah "proses apa yang memiliki beban terbesar pada memori yang menyebabkan kswapd perlu halaman sepanjang waktu".

Itu paling mudah dijawab menggunakan 'atas' dan beralih ke mode pengurutan penggunaan memori.

— Paul
sumber

Terima kasih!. Apakah skswapd menendang HANYA ketika halaman yang sebenarnya menyentuh melebihi fisik atau apakah itu menendang meskipun suatu proses telah mengalokasikan memori atau memetakan wilayah SHM tetapi tidak menggunakannya? Yaitu, apakah hanya ketika masalah terjadi atau apakah ia melakukan pembukuan dan menukar barang-barang masuk dan keluar meskipun ada memori fisik yang tersedia tetapi hanya karena beberapa proses telah menganggur, dll?

— Deshawn

Seperti yang saya pahami, kswapd dalam keadaan normal akan menghapus halaman apa saja dari memori utama yang tidak perlu ada di sana, karena setiap halaman yang dibebaskan adalah yang dapat digunakan untuk caching atau proses lainnya. Yaitu, lebih baik memiliki halaman lama yang tidak terpakai pada disk daripada harus mengeluarkan biaya yang lambat untuk memindahkannya sebagai tanggapan atas permintaan memori dari proses lain.

— Paul

Bahkan jika sebuah mesin perlu menggunakan banyak ruang swap, itu tidak harus mengambil CPU 100% untuk melakukannya. Ada yang aneh.

— Zaz

@Zaz Tidak begitu banyak menggunakan kekuatan pemrosesan CPU untuk melakukan swapping, itu adalah bahwa CPU ini 100% digunakan karena IOWAIT. Setiap kali memori perlu ditukar dari disk, CPU harus duduk di sana dan menunggu - IOWAIT, dan tidak melakukan hal lain (rata-rata).

— Paul

@ Paul: Apakah Anda yakin? topmengatakan kepada saya bahwa tidak ada waktu yang dihabiskan di IO menunggu, dan hampir 100% waktu dihabiskan dalam sistem. Info lebih lanjut: kswapd sering menggunakan CPU 100% saat swap sedang digunakan

— Zaz

9

Anda dapat skrip itu .. tetapi Anda juga bisa melakukannya melalui atas

Jalankan atas lalu tekan O diikuti oleh p lalu masuk

Sekarang semua proses diurutkan berdasarkan penggunaan swap dan Anda dapat melihat mana yang menggunakannya

— Mike
sumber

2

O memunculkan opsi filter untuk saya, menekan p lalu enter memberi saya "pembatas filter 'termasuk' tidak ada"

— Shadow

@Shadow Masalah yang sama, di sini perintah alternatif unix.stackexchange.com/questions/128953/…

— Björn

8

Jika Anda menggunakan Ubuntu 15.10 atau lebih tinggi, ini mungkin sebenarnya merupakan hasil dari bug , terutama jika sistem Anda adalah mesin virtual yang tidak memiliki partisi swap (misalnya, AWS EC2). Masalahnya ada pada distribusi lain , tetapi, pada saat penulisan, tidak jelas apakah perbaikan yang sama berfungsi secara universal.

Solusi sementara:

sudo ln -s /dev/null /etc/udev/rules.d/40-vm-hotadd.rules
sudo reboot

Perhatikan bahwa ini akan menonaktifkan RAM hotadding / CPU untuk mesin virtual Xen dan Hyper-V.

— Zenexer
sumber

Apakah ini muncul entah dari mana di sistem saya di Kubuntu 16.10 dengan solusinya sudah diaktifkan beberapa saat yang lalu.

— Juni

@ joete Ada beberapa masalah yang dapat menyebabkan perilaku ini; ini hanya terjadi pada umumnya.

— Zenexer

Ya. Saya telah menemukan bahwa echo 3 > /proc/sys/vm/drop_cachesmeringankannya setelah itu mulai terjadi. Saya sebelumnya memiliki perintah pada tugas cron sekarang dan tampaknya membantu, atau setidaknya membatasi durasi pembantaian OOM ketika saya jauh dari komputer.

— Juni

6

Tampaknya juga ada bug di kswapdsuatu tempat, semoga hanya pada kernel yang lebih tua.

Hampir setiap hari sekarang kswapd berjalan secara acak pada beberapa mesin di cluster yang lebih besar (dengan kernel yang tidak ada, meskipun). 100% CPU pada kedua proses kswapd. Tidak ada proses yang berjalan lainnya (kecuali ssh shell), banyak RAM gratis (lebih dari 700 MB) dan tidak ada SWAP yang digunakan sama sekali. Tanpa swapin, tanpa swapout juga.

Belum ada yang menjelaskan, mengapa mesin tertentu dipukul dan yang lain tidak. Tampaknya tidak sepenuhnya acak, karena biasanya mengenai lebih dari satu mesin dalam rentang waktu singkat. Sepertinya mesin, yang menganggur, serta mesin, yang berada di bawah tekanan tinggi, kurang (!) Kemungkinan terkena efeknya. Jadi itu harus melakukan sesuatu dengan beban kerja dan hanya mengenai jika mesin tidak menganggur atau sangat sibuk.

Jika masalah menyerang tidak ada yang membantu lagi. Membunuh semua proses (yang tidak menjadi tidak dapat diraih), melepas semua sistem file, tidak ada. kswapdmasih tetap pada CPU 100%. Saya curiga ada beberapa ras spinlock di kernel SMP, tetapi kemungkinan besar saya salah.

Mungkin melihat jawaban saya serverfault.com/questions/316995/#493257

Catatan:

Mem-boot ulang komputer yang terpengaruh sering gagal karena proses mematikan mulai tergantung di suatu tempat.
Tidak ada koneksi langsung ke Internet. Penyebab asing tidak mungkin.
Tampaknya tergantung pada jenis beban kerja proses mesin dari perspektif beban, karena kami memiliki mesin yang belum pernah terpengaruh (belum).
Maaf, saya tidak bisa lebih spesifik tentang apa yang kami lakukan dan mengapa.
Ya, saya berspekulasi. Karena ini efek yang sangat membingungkan, hari ini.

— Tino
sumber

Ini bersejarah. RedHat mengonfirmasi: Itu adalah masalah kernel 2.6.18-194.el5 dalam kombinasi dengan klien NFS. Itu sudah diperbaiki pada 2012 sudah. Lihat jawaban yang ditautkan dalam teks saya untuk informasi lebih lanjut. Jika Anda menekan ini hari ini, kemungkinan ada penyebab lain.

— Tino

1

Ini masih menjadi masalah di beberapa tempat. Saya telah melihat berton-ton ini. di sini , dan di sini adalah beberapa contoh.

— trueCamelType