Ini adalah pos lama, bagaimanapun, saya masih akan mengambil kebebasan untuk meletakkan pikiran saya di sini.
Mulai dari bawah, Linux akan membagi memori menjadi beberapa halaman (biasanya 4K per halaman pada sistem x86_64). Setelah itu, memori virtual dibuat, yang pemetaannya dilakukan dengan memori fisik menggunakan MMU (Memory Management Unit).
Proses dialokasikan memori dari area memori virtual, jadi harap dicatat, ketika Anda melihat / proc / meminfo, Anda akan melihat VMalloc * sebagai detail memori virtual.
Katakanlah Anda memiliki proses yang meminta memori (katakanlah 300MB - browser web). Proses ini akan dialokasikan 300MB dari memori virtual, namun, tidak perlu memori dipetakan (yang dipetakan ke memori fisik). Ada konsep "Copy on Write" untuk manajemen memori, di mana, jika proses Anda benar-benar menggunakan memori yang dialokasikan dari memori virtual (yaitu melakukan beberapa penulisan pada memori), hanya kemudian dipetakan ke memori fisik. Ini membantu kernel untuk bekerja dengan baik di lingkungan multi-proses secara efisien.
Apa itu cache?
Banyak memori yang digunakan oleh proses dibagikan. Katakanlah pustaka glibc digunakan oleh hampir semua proses. Apa gunanya menyimpan banyak salinan glibc dalam memori, ketika setiap proses dapat mengakses lokasi memori yang sama dan melakukan pekerjaan itu. Sumber daya yang sering digunakan tersebut disimpan dalam cache sehingga ketika memproses permintaan, sumber daya tersebut dapat dirujuk ke lokasi memori yang sama. Ini membantu mempercepat proses, karena membaca glibc (dll.) Lagi & lagi dari disk akan menghabiskan waktu.
Di atas adalah untuk pustaka bersama per katakan, serupa juga berlaku untuk membaca file juga. Jika Anda membaca file besar (katakanlah 100-200MB) untuk pertama kalinya, itu akan memakan banyak waktu. Namun, ketika Anda mencoba dan melakukan baca yang sama lagi, itu akan lebih cepat. Data di-cache dalam memori, dan membaca ulang tidak dilakukan untuk semua blok.
Apa itu buffer?
Sejauh menyangkut buffer, ketika suatu proses melakukan file I / O, itu bergantung pada buffer kernel untuk menulis data ke disk. Proses, meminta kernel untuk melakukan pekerjaan. Jadi, atas nama proses, kernel menulis data ke "buffer" -nya, dan memberi tahu proses bahwa penulisan dilakukan. Dengan cara async, kernel akan terus menyinkronkan data ini dalam buffer ke disk. Dengan cara ini, proses bergantung pada kernel untuk memilih waktu yang tepat untuk menyinkronkan data ke disk, dan proses dapat terus bekerja di depan. Ingat, ini adalah I / O umum yang dilakukan proses normal. Namun, proses khusus, yang perlu mengkonfirmasi bahwa I / O benar-benar dilakukan pada disk dapat menggunakan mekanisme lain untuk melakukan I / O pada disk. Beberapa utilitas opensource adalah libaio. Juga, ada cara untuk memanggil sinkronisasi eksplisit ke FD yang dibuka dalam konteks proses Anda,
Apa itu kesalahan halaman?
Pertimbangkan sebuah contoh, ketika Anda memulai proses (misalkan browser web), yang binernya sekitar 300MB. Namun, 300MB biner peramban web yang lengkap tidak mulai berfungsi secara instan. Proses terus bergerak dari fungsi-ke-fungsi dalam kodenya. Seperti yang dikatakan sebelumnya, Memori Virtual akan dikonsumsi 300MB, tidak semua memori dipetakan ke memori fisik (RSS - memori penduduk akan lebih sedikit, lihat output atas). Ketika eksekusi kode mencapai titik, di mana memori tidak benar-benar dipetakan secara fisik, kesalahan halaman akan menjadi masalah. Kernel akan memetakan memori ini ke fisik, kaitkan halaman memori dengan proses Anda. Kesalahan halaman semacam itu disebut "Minor Page Faults". Demikian pula, ketika suatu proses melakukan kesalahan file I / O halaman utama dinaikkan.
Kapan dan mengapa Swap Out terjadi?
Situasi 1:
Sejalan dengan rincian di atas, mari kita pertimbangkan skenario ketika jumlah memori yang baik menjadi memori yang dipetakan. Dan sekarang sebuah proses dimulai, yang membutuhkan memori. Seperti dibahas di atas, kernel harus melakukan pemetaan memori. Namun, tidak tersedia cukup RAM fisik untuk memetakan memori. Sekarang, kernel akan lebih dulu melihat ke dalam cache, ia akan memiliki beberapa halaman memori lama yang tidak digunakan. Ini akan menyiram halaman-halaman itu ke partisi yang terpisah (disebut SWAP), membebaskan beberapa halaman, dan memetakan halaman yang dibebaskan ke permintaan baru yang datang. Karena penulisan disk jauh lebih lambat daripada RAM solid-state, proses ini membutuhkan banyak waktu, dan karenanya memperlambat terlihat.
Situasi 2:
Katakanlah Anda melihat banyak memori bebas yang tersedia di sistem. Bahkan kemudian Anda melihat bahwa ada banyak swap-out yang terjadi. Mungkin ada masalah kemungkinan fragmentasi memori. Pertimbangkan sebuah proses, yang membutuhkan 50 MB memori yang berdekatan dari kernel. (perlu diingat berdekatan). Jelas, kernel akan mengalokasikan halaman secara acak untuk proses yang berbeda, dan membebaskan sebagian dari mereka. Namun, ketika kita menuntut memori yang berdekatan, itu harus mencari potongan yang memuaskan proses permintaan. Jika tidak bisa mendapatkan memori seperti itu, itu harus melakukan swap-out dari beberapa halaman memori lama dan kemudian mengalokasikan yang berdekatan. Bahkan dalam kasus seperti itu SWAP akan terjadi. Mulai Kernel ver 2.6 dan di atas, masalah fragmentasi tersebut telah berkurang secara signifikan. Namun, jika sistem berjalan untuk waktu yang lama, masalah seperti itu masih bisa datang.
Lihat contoh ini ( output vmstat )
2016-10-29 03:55:32 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
2016-10-29 03:55:32 r b swpd free buff cache si so bi bo in cs us sy id wa st
2016-10-30 03:56:04 19 23 2914752 4692144 3344908 12162628 1660 1 8803 12701 4336 37487 14 7 40 38 0
2016-10-30 03:56:34 3 20 2889296 4977580 3345316 12026752 2109 2 8445 14665 4656 36294 12 7 46 34 0
2016-10-30 03:57:04 1 11 3418868 4939716 3347804 11536356 586 4744 2547 9535 3086 24450 6 3 59 33 0 <<<-----
2016-10-30 03:57:34 3 19 3456252 5449884 3348400 11489728 3291 13371 6407 17957 2997 22556 6 4 66 24 0
2016-10-30 03:58:04 7 6 4194500 5663580 3349552 10857424 2407 12240 3824 14560 2295 18237 4 2 65 29 0
2016-10-30 03:58:34 2 16 4203036 5986864 3348908 10838492 4601 16639 7219 18808 2575 21563 6 4 60 31 0
2016-10-30 03:59:04 3 14 4205652 6059196 3348760 10821448 6624 1597 9431 4357 1750 20471 6 2 60 31 0
2016-10-30 03:59:34 2 24 4206968 6053160 3348876 10777216 5221 2067 10106 7377 1731 19161 3 3 62 32 0
2016-10-30 04:00:04 0 13 4205172 6005084 3348932 10785896 6236 1609 10330 6264 1739 20348 4 2 67 26 0
2016-10-30 04:00:34 4 11 4206420 5996396 3348976 10770220 6554 1253 10382 4896 1964 42981 10 5 58 27 0
2016-10-30 04:01:04 6 4 4177176 5878852 3348988 10825840 8682 765 10126 2716 1731 32949 8 4 69 19 0
@ 2016-10-30 03:57:04, kita melihat bahwa masih ada jumlah RAM gratis yang baik. Namun, itupun swap out terjadi. Kami memeriksa pohon proses pada saat ini, dan kami tidak melihat proses apa pun yang muncul yang menuntut jumlah memori yang tinggi (lebih dari memori bebas). Kecurigaan yang jelas adalah Situasi 2 yang dijelaskan di atas. Kami memeriksa buddyinfo dan zoneinfo log di atas (Gunakan echo m> / proc / sysrq-trigger untuk memeriksa ini, hasilnya masuk ke syslogs).
Untuk sistem normal kita, perbandingan info zona berlaku seperti ini. Dan grafik untuk cache / free / mem rendah juga disebutkan di bawah ini
Melihat info, jelas bahwa ada fragmentasi memori di simpul 0 & simpul 1 normal (Node itu adalah mesin berbasis NUMA, maka beberapa node (lihat numactl untuk memeriksa info untuk sistem Anda)).
Fragmentasi memori juga merupakan alasan mengapa penggunaan swap dapat meningkat bahkan ketika memori bebas ada.
