Mengapa tabel halaman saya menghabiskan banyak memori?


10

64-bit Windows 7 PC saya sangat lamban. Saya perhatikan di Task Manager bahwa penggunaan memori saya hampir 100% - namun penggunaan yang dilaporkan untuk setiap proses tidak menambahkan hingga total 6GB (Firefox menunjukkan sekitar 500MB, sisanya jauh lebih sedikit). Saya mengunduh RAMMap dan menemukan bahwa Page Table memakan banyak memori (2.5GB).

Tangkapan layar RAMMap

Saya mencari di Google dan tidak menemukan tempat - tampaknya tabel halaman dapat terfragmentasi. Jelas saya akan me-reboot mesin dan melihat apakah itu membantu. Tetapi apakah ada cara yang lebih baik untuk memperbaikinya?

EDIT: reboot, dan tabel halaman turun hingga 30MB.

EDIT 2: Setelah beberapa hari uptime, penggunaan tabel halaman merayap naik lagi. Saya mengikuti instruksi @ magicandre1981 dalam jawaban ini untuk menemukan sumber penggunaan tabel halaman. Sayangnya saya menggambar kosong - tabel halaman digunakan oleh "Tidak Diketahui"!

Tangkapan layar WPA

Adakah yang punya ide cemerlang?


Anda harus menentukan apa yang menggunakan file halaman Anda untuk memahami alasan penggunaan file halaman Anda (yaitu memori virtual Anda) tinggi.
Ramhound

1
Tidak, saya pikir ini adalah memori fisik yang digunakan, bukan virtual. Saya pikir tabel halaman adalah semacam referensi untuk manajer memori?
benshepherd

2
Seperti yang saya katakan dalam pertanyaan, tidak ada proses yang menggunakan memori. Saya mendapat kesan bahwa tabel halaman berbeda dengan file halaman .
benshepherd


1
Tabel halaman IS hal yang sangat berbeda dari file halaman. Lihat jawaban saya di bawah ini. Juga, sementara pagefile bisa terfragmentasi, tabel halaman ... yah, mereka selalu terfragmentasi (seperti yang tersebar di seluruh RAM) dan tidak masalah sedikitpun.
Jamie Hanrahan

Jawaban:


5

Saya perlu mengomentari komentar untuk pertanyaan, terutama kebingungan antara "tabel halaman" dan "file halaman". Ini bukan jawaban tetapi tidak sesuai dengan ruang yang diizinkan untuk komentar.

"Page table" memang sangat berbeda dengan pagefile. Memiliki n MB RAM yang digunakan untuk tabel halaman tidak berarti Anda menggunakan n MB ruang pagefile. Dan meskipun beberapa entri tabel halaman (PTEs, yang terdiri dari tabel halaman) merujuk ke konten pagefile, tidak semua melakukannya.

Tabel halaman adalah struktur dalam memori yang digunakan oleh MMU CPU untuk melakukan terjemahan alamat dari alamat virtual (sekali lagi, bukan pagefile) ke alamat fisik, dan oleh OS untuk melacak ruang alamat virtual dan membantu menyelesaikan kesalahan halaman. Tabel halaman terdiri dari entri tabel halaman (PTEs). Setiap PTE menempati 8 byte dan mendefinisikan 4K byte ruang alamat virtual - yaitu satu halaman virtual. Ada, kira-kira, satu PTE untuk setiap halaman ruang alamat virtual yang tidak bebas.

By the way, meskipun pagefile dapat mengalami baik fragmentasi eksternal dan internal (yang pertama biasanya tidak banyak masalah; yang terakhir dapat diperbaiki dengan membuatnya sekitar empat kali lebih besar dari yang seharusnya), tabel halaman tidak bisa. Mereka selalu terfragmentasi, dan tidak masalah sedikit pun.

Setiap PTE memiliki bit "valid". Untuk halaman "valid", alias "resident", PTE berisi nomor halaman fisik yang sesuai dengan nomor halaman virtual yang dikaitkan dengan PTE; ini digunakan langsung oleh MMU.

Untuk halaman "tidak valid" MMU memunculkan kesalahan halaman dan PTE kemudian memiliki banyak format dan interpretasi yang memungkinkan.

Catatan: Semua hal di atas berlaku untuk sistem operasi apa pun yang memungkinkan paging pada x86 / x64. Berikut ini sebagian besar khusus untuk Windows, tetapi banyak konsep yang berlaku untuk OS lain, dengan perbedaan dalam detail implementasi.

Untuk halaman di halaman cache, PTE masih berisi nomor halaman fisik. Untuk halaman yang hilang dari RAM dan ditulis ke pagefile, PTE memang berisi nomor pagefile dan offset di dalam pagefile tempat konten halaman ditulis. Konten PTE lain yang mungkin adalah referensi ke deskriptor alamat virtual , referensi ke "prototipe PTEs", referensi untuk meminta halaman nol , dll., Yang tidak akan saya bahas. Cukuplah untuk mengatakan bahwa hanya sebagian PTE yang merujuk ke lokasi di pagefiles.

Saya menyebutkan semua ini sebagian besar untuk menunjukkan bahwa pagefile dan tabel halaman, sementara terkait, jelas bukan hal yang sama.

Tabel halaman disusun dalam struktur pohon. Ada pohon yang berbeda seperti itu, atau kumpulan tabel halaman, untuk setiap proses - ini adalah apa yang memungkinkan setiap proses untuk menentukan contoh sendiri dari ruang alamat virtual. Tabel halaman di root pohon harus dalam RAM setiap saat. Yang lain bisa di-pageable; mereka bahkan tidak ada di mana mereka akan sesuai dengan wilayah besar (minimal 2 MB) ruang alamat virtual yang tidak ditentukan, atau gratis.

Entri tabel halaman dalam tabel di "daun" pohon sesuai dengan halaman ruang alamat virtual. PTEs dalam tabel tingkat yang lebih tinggi - yang lebih dekat ke root (dan root itu sendiri) - memberi tahu di mana tabel tingkat bawah berikutnya berada (jika ada sama sekali).

Angka yang ditunjukkan oleh RAMmap adalah memori fisik (RAM) yang ditempati oleh semua tabel halaman resident (in-RAM) untuk semua proses plus OS.

Yang penting di sini adalah bahwa sistem dalam OQ memiliki 2,5 GB RAM yang diikat dengan tabel halaman. Itu berarti, setidaknya, ada 2,5 GB tabel halaman yang ditentukan. Karena tabel halaman itu sendiri dapat di-page, ukuran virtual bisa jauh lebih besar daripada ukuran fisik, yang dapat ditunjukkan oleh semua RAMmap kepada kami. Tapi anggap itu "hanya" 2,5 GB. Pada delapan byte per PTE yaitu sekitar 320 juta PTEs. Karena setiap PTE mendefinisikan satu halaman - 4K byte - ruang alamat virtual, itu berarti bahwa lebih dari 1,2 terabyte ruang alamat virtual ditentukan oleh tabel halaman dalam memori .

Itu tidak mustahil tetapi itu agak banyak.

Sebagai referensi, pada atm sistem saya, saya memiliki sekitar 125 MB RAM dalam tabel halaman. Ini hanya menunjukkan sekitar 65 GB ruang alamat virtual. Penggunaan virtual saya yang sebenarnya jauh lebih tinggi (125 TB hanya untuk proses) tetapi itu karena sebagian besar tabel halaman tidak dalam RAM. "Halaman besar", hal lain yang tidak boleh saya bahas di sini, juga dapat membantu menjelaskan perbedaan rasio antara ukuran tabel halaman vs ukuran ruang alamat virtual yang digunakan.

Jadi: Untuk menemukan pelakunya, pertama saya akan mencari di Monitor Kinerja di bawah kategori Proses untuk proses dengan nilai penghitung "Virtual Bytes" yang tinggi.


4

Lenovo "RapidBoot Shield" adalah penyebabnya bagi saya.

Setelah seminggu tanpa reboot, "Page Table" saya menggunakan 4GB +. Ternyata setiap proses yang dihentikan menggunakan RAM 20K (4K pribadi, 16K Page Table) seperti yang ditunjukkan pada tab "Proses" di RamMap, dan ada ~ 200.000 di antaranya!

Reboot mengurangi daftar tetapi mulai tumbuh lagi. Itu direproduksi dengan membuka notepad, membunuhnya dan mengamati bahwa itu tetap dalam daftar proses RamMap.

Berdasarkan saran pada utas teknik ini saya mencopot pemasangan "RapidBoot Sheild", menyalakan ulang mesin dan kemudian proses tidak lagi bertahan ketika terbunuh. Masalah terpecahkan!



1

Saya bertanya kepada departemen TI saya tentang hal ini, dan mereka juga melakukan hal yang sama. Saya akhirnya menggunakan DriverEasy untuk memperbarui driver saya. Yang tampaknya membuat perbedaan, cukup aneh, adalah driver monitor. Sebelumnya saya punya driver standar Windows "Generic PnP Monitor". Tetapi ketika saya memperbarui itu ke model dan monitor saya yang benar, masalah itu sepertinya hilang.


1

Buka tab "Proses" di RamMap dan urutkan berdasarkan nama. Carilah jumlah tinggi yang mencurigakan dari proses yang sama. Di komputer saya, "SynTPEnh.exe" adalah biang keladinya (bagian dari driver touchpad). Setelah satu minggu uptime, ia mengumpulkan puluhan ribu entri dalam tabel halaman, masing-masing berukuran 32kb.

Ukuran tabel halaman saya adalah 1 GB, setelah reboot, hanya 50 MB.

masukkan deskripsi gambar di sini

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.