Bagaimana Cara Menguji Pembunuh Oom Dari Baris Perintah?

Pembunuh OOM atau Kehabisan Memori Pembunuh adalah proses yang
linux kernel bekerja ketika sistem sangat rendah pada memori. … Ini memaksimalkan penggunaan memori sistem dengan memastikan bahwa
memori yang dialokasikan untuk proses digunakan secara aktif.

Pertanyaan yang dijawab sendiri ini menanyakan:

• Bagaimana cara menguji oom-killer dari baris perintah?

Metode yang lebih cepat daripada 1/2 jam yang diperlukan untuk menjawab sendiri akan diterima.

Jawaban yang Diterima:

Kunci untuk memicu pembunuh OOM dengan cepat adalah untuk menghindari macet oleh akses disk. Jadi:

1. Hindari swapping, kecuali tujuan Anda secara khusus menguji perilaku OOM saat swap digunakan. Anda dapat menonaktifkan swap sebelum pengujian, lalu mengaktifkannya kembali setelahnya. swapon -s memberitahu Anda swap apa yang saat ini diaktifkan. sudo swapoff -a menonaktifkan semua swap; sudo swapon -a biasanya cukup untuk mengaktifkannya kembali.

2. Hindari menyelingi akses memori dengan akses disk non-swap. Metode berbasis globbing itu pada akhirnya menggunakan memori Anda yang tersedia (dengan cukup entri di sistem file Anda), tetapi alasannya membutuhkan begitu banyak memori adalah untuk menyimpan informasi yang diperolehnya dengan mengakses sistem file Anda. Bahkan dengan SSD, kemungkinan sebagian besar waktu dihabiskan untuk membaca dari disk, bahkan jika swap dimatikan. Jika tujuan Anda secara khusus untuk menguji perilaku OOM untuk akses memori yang diselingi dengan akses disk, metode itu masuk akal, bahkan mungkin ideal. Jika tidak, Anda dapat mencapai tujuan Anda lebih cepat.

Setelah Anda menonaktifkan swap, metode apa pun yang jarang dibaca dari disk fisik seharusnya cukup cepat. Ini termasuk tail /dev/zero (ditemukan oleh falstaff, dikomentari di atas oleh Doug Smythies). Meskipun dibaca dari perangkat karakter /dev/zero , "perangkat" itu hanya menghasilkan byte nol (yaitu, byte dari semua nol) dan tidak melibatkan akses disk fisik apa pun setelah simpul perangkat dibuka. Metode itu berhasil karena tail mencari garis tambahan dalam inputnya, tetapi aliran nol tidak berisi karakter baris baru, sehingga tidak pernah ada baris yang dibuang.

Jika Anda mencari satu baris dalam bahasa yang ditafsirkan yang mengalokasikan dan mengisi memori secara algoritmik, Anda beruntung. Dalam hampir semua bahasa yang ditafsirkan untuk tujuan umum, mudah untuk mengalokasikan banyak memori dan menulis ke sana tanpa menggunakannya. Inilah one-liner Perl yang tampaknya secepat tail /dev/zero (meskipun saya belum membandingkannya secara ekstensif):

perl -wE 'my @xs; for (1..2**20) { push @xs, q{a} x 2**20 }; say scalar @xs;'

Dengan swap dimatikan pada mesin lama dengan 4 GiB RAM, keduanya dan tail /dev/zero membutuhkan waktu sekitar sepuluh detik setiap kali saya menjalankannya. Keduanya masih harus bekerja dengan baik pada mesin yang lebih baru dengan lebih banyak RAM dari itu. Anda dapat membuat perl perintah jauh lebih pendek, jika tujuan Anda adalah singkat.

Perl one-liner itu berulang kali menghasilkan (q{a} x 2**20 ) memisahkan string yang cukup panjang–masing-masing sekitar satu juta karakter–dan menyimpannya di sekitar dengan menyimpannya dalam array (@xs ). Anda dapat menyesuaikan angka untuk pengujian. Jika Anda tidak menggunakan semua memori yang tersedia, one-liner menampilkan jumlah total string yang dibuat. Dengan asumsi pembunuh OOM membunuh perl –dengan perintah persis seperti yang ditunjukkan di atas dan tidak ada kuota sumber daya yang menghalangi, saya yakin dalam praktiknya akan selalu demikian–maka shell Anda akan menunjukkan kepada Anda Killed . Kemudian, seperti dalam situasi OOM apa pun, dmesg memiliki detailnya.

Terkait:Apa yang harus ada dalam daftar periksa DVT (Uji Verifikasi Desain)?

Meskipun saya menyukai metode itu, itu menggambarkan sesuatu yang berguna tentang menulis, mengkompilasi, dan menggunakan program C-seperti yang ada di jawaban Doug Smythies. Mengalokasikan memori dan mengakses memori tidak terasa seperti hal yang terpisah dalam bahasa yang ditafsirkan tingkat tinggi, tetapi di C Anda dapat memperhatikan dan, jika Anda memilih, menyelidiki detail tersebut.

Terakhir, Anda harus selalu memeriksa apakah pembunuh OOM sebenarnya yang mematikan program Anda . Salah satu cara untuk memeriksanya adalah dengan memeriksa dmesg . Berlawanan dengan kepercayaan populer, sebenarnya mungkin upaya untuk mengalokasikan memori gagal dengan cepat, bahkan di Linux. Sangat mudah untuk mewujudkannya dengan alokasi besar yang jelas akan gagal… tetapi bahkan itu bisa terjadi secara tidak terduga. Dan alokasi yang tampaknya masuk akal mungkin gagal dengan cepat. Misalnya, pada mesin uji saya, perl -wE 'say length q{a} x 3_100_000_000;' berhasil, dan perl -wE 'say length q{a} x 3_200_000_000;' cetakan:

Out of memory!
panic: fold_constants JMPENV_PUSH returned 2 at -e line 1.

Tidak ada yang memicu pembunuh OOM. Berbicara lebih umum:

• Jika program Anda menghitung terlebih dahulu berapa banyak memori yang dibutuhkan dan memintanya dalam satu alokasi, alokasi mungkin berhasil (dan jika ya, pembunuh OOM mungkin atau mungkin tidak mematikan program ketika cukup banyak memori yang digunakan), atau alokasi mungkin gagal.
• Memperluas array hingga sangat panjang dengan menambahkan banyak, banyak elemen ke dalamnya sering kali memicu pembunuh OOM dalam praktik sebenarnya, tetapi membuatnya melakukannya dengan andal dalam pengujian sangat rumit. Cara ini hampir selalu dilakukan–karena ini adalah cara yang paling efisien–adalah membuat setiap buffer baru dengan kapasitas x kali kapasitas buffer lama. Nilai umum untuk x termasuk 1,5 dan 2 (dan teknik ini sering disebut "penggandaan tabel"). Hal ini terkadang menjembatani kesenjangan antara berapa banyak memori yang sebenarnya dapat dialokasikan dan digunakan dan seberapa banyak yang diketahui oleh kernel terlalu banyak sehingga sulit untuk berpura-pura membagikannya.
• Alokasi memori dapat gagal karena alasan yang tidak ada hubungannya dengan kernel atau seberapa banyak memori yang sebenarnya tersedia, dan itu juga tidak memicu pembunuh OOM. Secara khusus, sebuah program mungkin gagal dengan cepat pada alokasi ukuran apa pun setelah berhasil melakukan sejumlah besar alokasi kecil. Kegagalan ini terjadi pada pembukuan yang dilakukan oleh program itu sendiri – biasanya melalui fasilitas perpustakaan seperti malloc() . Saya menduga inilah yang terjadi pada saya hari ini ketika, selama pengujian dengan bash array (yang sebenarnya diimplementasikan sebagai daftar tertaut ganda), bash keluar dengan pesan kesalahan yang mengatakan alokasi dari 9 byte gagal.

Pembunuh OOM jauh lebih mudah dipicu secara tidak sengaja daripada dipicu dengan sengaja.

Dalam upaya untuk secara sengaja memicu pembunuh OOM, salah satu cara mengatasi masalah ini adalah memulai dengan meminta terlalu banyak memori, dan secara bertahap mengecil, seperti yang dilakukan program C Doug Smythies. Cara lain adalah dengan mengalokasikan sejumlah besar potongan memori berukuran sedang, yang dilakukan oleh one-liner Perl yang ditunjukkan di atas:tidak ada string berkarakter jutaan (ditambah sedikit penggunaan memori tambahan di belakang layar) yang sangat melelahkan, tetapi jika digabungkan, semua pembelian satu megabita akan bertambah.