Saya menjawab tag linux . Jawaban saya hanya khusus untuk Linux .
Ya, halaman besar lebih rentan terhadap fragmentasi. Ada dua tampilan memori, yang proses Anda (virtual) dan yang dikelola kernel (nyata). Semakin besar halaman apa pun, semakin sulit untuk mengelompokkan (dan menyimpannya) dengan tetangganya, terutama ketika layanan Anda berjalan pada sistem yang juga harus mendukung orang lain yang secara default mengalokasikan dan menulis ke memori yang jauh lebih banyak daripada mereka. sebenarnya berakhir menggunakan.
Pemetaan kernel dari alamat (nyata) yang diberikan bersifat pribadi. Ada alasan yang sangat bagus mengapa userspace melihatnya sebagai kernel yang mempresentasikannya, karena kernel harus dapat overcommit tanpa membingungkan userspace. Proses Anda mendapatkan ruang alamat "Disneyfied" yang bagus dan berdekatan tempat untuk bekerja, tanpa mengetahui apa yang sebenarnya dilakukan kernel dengan memori di belakang layar.
Alasan Anda melihat kinerja yang menurun pada server yang berjalan lama kemungkinan besar karena blok yang dialokasikan yang belum dikunci secara eksplisit (misalnya mlock()
/ mlockall()
atau posix_madvise()
) dan tidak dimodifikasi dalam beberapa saat telah dikeluarkan , yang berarti layanan Anda tergelincir ke disk ketika harus membaca mereka. Mengubah perilaku ini membuat proses Anda menjadi tetangga yang buruk , itulah sebabnya banyak orang meletakkan RDBMS mereka di server yang sama sekali berbeda dari web / php / python / ruby / apa pun. Satu-satunya cara untuk memperbaikinya, secara waras, adalah mengurangi persaingan untuk blok yang berdekatan.
Fragmentasi hanya benar-benar terlihat (dalam kebanyakan kasus) ketika halaman A ada dalam memori dan halaman B telah pindah untuk bertukar. Secara alami, memulai kembali layanan Anda tampaknya akan 'menyembuhkan' ini, tetapi hanya karena kernel belum memiliki kesempatan untuk membatalkan proses '(sekarang) blok-blok yang baru dialokasikan dalam batas rasio overcommit-nya.
Bahkan, memulai kembali (katakanlah) 'apache' di bawah beban tinggi kemungkinan akan mengirim blok yang dimiliki oleh layanan lain langsung ke disk. Jadi ya, 'apache' akan meningkat untuk waktu yang singkat, tetapi 'mysql' mungkin menderita .. setidaknya sampai kernel membuat mereka menderita secara sama ketika hanya ada kekurangan memori fisik yang cukup.
Tambahkan lebih banyak memori, atau pisahkan malloc()
konsumen yang menuntut :) Bukan hanya fragmentasi yang perlu Anda perhatikan.
Cobalah vmstat
untuk mendapatkan gambaran umum tentang apa yang sebenarnya disimpan di mana.