Sistem menggantung ketika kehabisan memori

34

Saya mendapatkan eeePC 900a: ia memiliki flash 8GB sebagai disk dan hanya 1GB RAM. Distribusi Linux yang diinstal di sana adalah ArchLinux.

Ketika sistem kehabisan memori, itu menjadi sangat tidak responsif: dibutuhkan beberapa detik / menit untuk melakukan hal-hal seperti beralih ke TTY1 atau bahkan memindahkan pointer mouse. Kadang-kadang sepertinya sistem hanya membeku: tiga milik kita yang lalu saya biarkan sendiri dan tidak ada yang berubah sejauh ini.

Saya lebih suka menghindari membuat partisi swap / file pada eeePC ini karena disk sudah sekecil itu, dan juga karena banyak menulis di ruang swap akan mempersingkat masa pakai kartu flash. Selain itu saya pikir file swap / partisi hanya akan memindahkan masalah, daripada pasti memperbaikinya.

Bukankah kernel seharusnya mematikan beberapa aplikasi acak ketika kehabisan memori? Mengapa gagal (atau butuh waktu lama) dalam melakukan itu?

Beberapa bulan / tahun yang lalu saya sudah mencoba untuk melihat lebih jauh ke dalam ini, tetapi tidak dapat menemukan apa pun yang benar-benar berfungsi ...

linux memory freeze

— peoro
sumber

1

DE / WM apa yang Anda gunakan dalam pengaturan Anda, layanan / daemon apa yang Anda jalankan? Menggunakan lingkungan desktop yang penuh fletched dan menjelajah dengan Chromium atau Firefox misalnya memakan RAM Anda untuk makan siang. RAM 1GB seharusnya cukup untuk menjalankan Arch Linux itu sendiri, tetapi yang benar-benar penting adalah apa yang Anda letakkan di atasnya.

1

Saya menggunakan LXDE. Chromium adalah program yang biasanya mengambil sebagian besar RAM. Pokoknya ini bukan itu intinya. Bukan aku yang harus peduli tentang berapa banyak memori sistem saya menggunakan, itu sistem saya yang tidak boleh mati karena itu. Jika sistem saya kekurangan memori, gratis untuk mematikan aplikasi apa pun yang diinginkannya, saya hanya ingin itu tidak membeku !

— peoro

6

Maksudku, aku serius berpikir tentang menjalankan script seperti ini (dalam pseudocode): while(true){ if( $FREE_MEMORY<10MB ){ kill -9 $RANDOM_PID; } }. Ini pasti akan memperbaiki masalah saya. Tapi tunggu, bukankah seharusnya kernel melakukan itu (dan jauh lebih baik daripada skrip saya)? Mengapa tidak melakukan tugasnya?

— peoro

2

@ Marsin, itu hanya akan memindahkan masalah, tidak akan memperbaikinya. Bahkan jika saya memiliki memori 4GB (berkat beberapa swap), sistem saya dapat kehabisan memori (sehingga menggantung). Yang ingin saya hindari adalah sistem saya membeku ketika kehabisan RAM. Jika kernel saya tiba-tiba akan membunuh chromium segera setelah RAM saya selesai, saya akan senang bahkan dengan 1GB yang saya miliki sekarang.

— peoro

4

@Lee The "magic sysrq" adalah kombo kunci yang langsung menuju ke kernel. Ini akan sering bekerja walaupun keyboard dan mouse tidak responsif. Lihat en.wikipedia.org/wiki/Magic_SysRq_key

— Raman

14

Dimungkinkan untuk memanggil OOM-killer (kehabisan memori killer) secara langsung dengan kombinasi keyboard:

SysRq-F

Kunci SysRq biasanya digabungkan dengan kunci PrtSc pada keyboard.

OOM-killer membunuh beberapa proses (-es) dan sistem menjadi responsif lagi.

Terima kasih untuk saran tentang fitur ini dalam komentar di atas.

PS: Ini banyak membantu saya. Saya setuju dengan pendapat bahwa ini adalah saran paling berguna tentang masalah itu jika disebabkan oleh Chrome atau perangkat lunak apa pun yang serakah memori. Tetapi Anda perlu diingat bahwa pembunuh OOM dapat membunuh beberapa proses yang sangat penting, gunakan dengan hati-hati.

— Arkemlar
sumber

2

Saya punya kuncinya PrtScn|SysRq. Tapi menekan SysRq - Fhanya mendapat tangkapan layar

— Lee

2

Karena Anda pada dasarnya mengambil komentar saya di atas dan membuatnya menjadi jawaban, atribusi kecil akan menyenangkan. Saya tetap memilih Anda. :-)

— Raman

3

@ Lee Anda harus mengaktifkannya. Beberapa distro tidak memiliki sysrq ajaib yang diaktifkan secara default. Ini seharusnya membantu: google.ca/search?q=sysrq+enable

— Raman

2

@Raman Saya bertaruh 99% yang menemukan ini tidak dapat "mengaktifkannya" secara default karena mesin mereka sudah dibekukan ... mengapa tidak diaktifkan secara default?

— themihai

3

@ themihai karena banyak orang menganggapnya sebagai risiko keamanan - ini memberi Anda akses langsung ke kernel melalui akses fisik ke perangkat input, terlepas dari status aplikasi mis. layar kunci dan semacamnya.

— Raman

12

Keadaan alami dari hal-hal ini adalah bahwa data aplikasi ada dalam RAM, dan file ada di disk.
Keadaan ideal, dari segi kinerja, adalah data yang sering digunakan adalah RAM, dan data yang tidak diperlukan saat ini ada di disk.
Pada sistem normal, kernel melakukan dua hal untuk mencoba mencapai ideal ini:

Data aplikasi yang belum digunakan untuk sementara waktu dapat dipindahkan ke disk: ini adalah swap.
Data dari file yang telah digunakan baru-baru ini disimpan dalam RAM: ini adalah cache disk (untuk data dibaca dari disk) dan buffer disk (untuk data yang akan ditulis ke disk).

Pada sistem tipikal, sebagian besar RAM dikhususkan untuk cache dan buffer (50% adalah angka tipikal). Karena RAM adalah sumber daya yang terbatas, ini mungkin memerlukan pemindahan beberapa data aplikasi untuk swap (swap hanya diperlukan jika ada cara yang lebih baik untuk menggunakan RAM).

Pada sistem tanpa swap, ada titik di mana data aplikasi menggunakan hampir semua RAM, sehingga hampir tidak ada ruang tersisa untuk cache. Maka sistem cenderung lambat. Kernel tidak akan mulai mematikan aplikasi sampai benar-benar harus. Selama aplikasi hanya mengisi 99% dari memori yang tersedia, sistem terus berjalan, tetapi sangat lambat karena file data harus dimuat dan dimuat ulang dari disk sepanjang waktu. Dengan aplikasi yang sama berjalan, sistem akan lebih cepat dengan swap pada saat itu.

Untuk lebih lanjut tentang masalah ini, lihat diskusi lkml ini dan posting blog ini .

Saya tidak tahu cara langsung memberitahu kernel untuk memesan jumlah minimum RAM untuk cache disk. Anda dapat mengatur sebagian kecil RAM Anda sebagai ruang swap , bahkan mungkin dikompresi . Ada laporan sukses di bagian depan itu , meskipun saya tidak membuat jaminan dalam kasus khusus Anda.

— Gilles 'SANGAT berhenti menjadi jahat'
sumber

1

Terima kasih atas penjelasan dan tautannya, mereka membantu menjernihkan keraguan tentang swap. mengikuti jawaban @Marcin untuk pertanyaan saya, saya mengatur 256MB swap virtual terkompresi (compcache) di RAM saya. Namun ini tidak sepenuhnya menjawab pertanyaan saya: Saya mengerti bahwa sistem saya akan lambat ketika seluruh RAM hanya digunakan oleh aplikasi dan tidak ada yang di-cache; Masih saya tidak mengerti mengapa sistem ini hang selama beberapa menit / jam (mungkin selamanya?) Ketika saya benar-benar kehabisan RAM. Saya pikir kernel saya tidak melakukan tugasnya dalam mematikan aplikasi ketika kehabisan memori, jika 3 jam tidak cukup untuk beralih ke TTY1.

— peoro

Saya memiliki swap yang dinonaktifkan dengan memori fisik 32GB dan ketika perangkat lunak yang buruk hilang dengan alokasi memori (halo ld, Anda sampah), itu masih hang selama hampir satu menit, bangun cukup hanya untuk membiarkan saya memindahkan mouse yang sangat lamban untuk sesaat atau dua setiap beberapa detik. Penanganan OOM Linux adalah omong kosong. Jika saya beruntung, pembunuh OOM membunuh proses yang benar tanpa mengacaukan lingkungan desktop sepenuhnya. Dan saya penggemar Linux. Ini jauh lebih buruk dengan paging diaktifkan. Paging Linux adalah lelucon.

— doug65536

6

Ini adalah bug yang dikenal sejak 2007 - lihat Pembekuan sistem pada penggunaan memori tinggi .

Dalam situasi ini, Windows menampilkan dialog yang memperingatkan pengguna untuk menutup satu atau lebih aplikasi.

— Dan Dascalescu
sumber

2

Tampaknya "Tidak Ditugaskan" di Ubuntu. Mungkin DE harus memperingatkan pengguna atau bahkan membekukan aplikasi intensif memori?

— nkkollaw

1

@nbrogi - apa pun kecuali diam membeku. Tapi semoga berhasil meyakinkan Ubuntu devs untuk melakukan itu.

— Dan Dascalescu

6

Baru-baru ini saya menemukan solusi untuk masalah saya.

Karena Linux OOM killer tidak dapat melakukan tugasnya dengan baik, saya mulai menggunakan OOM Killer userspace: earlyoom . Ini ditulis dalam C, cukup dapat dikonfigurasi dan berfungsi seperti pesona bagi saya.

Saya juga mendengar tentang beberapa alternatif, seperti OOMD Facebook , yang dikembangkan untuk berjalan di server mereka, tetapi saya belum mencoba yang ini

— peoro
sumber