Terjemahan artikel disiapkan untuk siswa kursus Administrator Linux .
Sebelumnya, saya berbicara tentang cara menguji dan mengaktifkan penggunaan Hugepages di Linux.
Artikel ini hanya akan berguna jika Anda benar-benar memiliki tempat untuk menggunakan Hugepages. Saya telah bertemu banyak orang yang tertipu oleh prospek bahwa Hugepages secara ajaib akan meningkatkan produktivitas. Namun, pelukan adalah topik yang kompleks, dan jika digunakan secara tidak benar, ini dapat mengurangi kinerja.
Bagian 1: verifikasi bahwa hugepage termasuk di Linux (asli di sini )
Masalah:
Anda perlu memeriksa apakah HugePages diaktifkan di sistem Anda.
Solusi:
Ini sangat sederhana:
cat /sys/kernel/mm/transparent_hugepage/enabled
Anda akan mendapatkan sesuatu seperti ini:
always [madvise] never
Anda akan melihat daftar opsi yang tersedia ( selalu, madvise, tidak pernah ), sedangkan opsi aktif saat ini akan dilampirkan dalam tanda kurung (secara default, madvise ).
madvise berarti transparent hugepages hanya termasuk untuk wilayah memori yang secara eksplisit meminta hugepage dengan madvise (2) .
selalu berarti transparent hugepages selalu diaktifkan untuk semua proses. Ini biasanya meningkatkan kinerja, tetapi jika Anda memiliki kasus penggunaan di mana banyak proses mengkonsumsi sejumlah kecil memori, maka total beban memori dapat meningkat secara dramatis.
tidak pernah berarti transparent hugepages tidak akan disertakan bahkan ketika diminta menggunakan madvise. Lihat dokumentasi kernel Linux untuk informasi lebih lanjut .
Cara mengubah nilai default
Opsi 1 : Ubah sysfs secara langsung (setelah reboot, parameter akan kembali ke nilai default):
echo always >/sys/kernel/mm/transparent_hugepage/enabled echo madvise >/sys/kernel/mm/transparent_hugepage/enabled echo never >/sys/kernel/mm/transparent_hugepage/enabled
Opsi 2 : Ubah default sistem dengan mengkompilasi ulang kernel dengan konfigurasi yang dimodifikasi (opsi ini hanya disarankan jika Anda menggunakan kernel Anda sendiri):
Bagian 2: Keuntungan dan Kerugian dari HugePages
Kami akan mencoba menjelaskan secara selektif kelebihan, kekurangan, dan kemungkinan kesalahan saat menggunakan Hugepages. Karena artikel yang canggih secara teknologi dan pedantic cenderung sulit bagi orang-orang yang tertipu dengan menganggap Hugepages sebagai obat mujarab, saya akan mengorbankan akurasi demi kesederhanaan. Perlu diingat bahwa banyak topik sangat kompleks dan karenanya sangat disederhanakan.
Harap dicatat bahwa kita berbicara tentang sistem x86 64-bit yang berjalan di Linux, dan saya hanya berasumsi bahwa sistem tersebut mendukung hugepage transparan (karena bukan suatu kerugian bahwa hugepage tidak diganti), seperti yang terjadi di hampir semua negara modern Lingkungan Linux.
Pada tautan di bawah ini saya akan melampirkan lebih banyak deskripsi teknis.
Memori virtual
Jika Anda seorang programmer C ++, Anda tahu bahwa objek dalam memori memiliki alamat spesifik (nilai pointer).
Namun, alamat-alamat ini tidak mencerminkan alamat fisik dalam memori (alamat dalam RAM). Mereka adalah alamat dalam memori virtual. Prosesor memiliki modul MMU (unit manajemen memori) khusus yang membantu kernel memetakan memori virtual ke lokasi fisik.
Pendekatan ini memiliki banyak keunggulan, tetapi yang paling mendasar di antaranya:
- Kinerja (karena berbagai alasan);
- Isolasi program, yaitu, tidak ada program yang dapat membaca dari memori program lain.
Apa itu halaman?
Memori virtual dibagi menjadi beberapa halaman. Setiap halaman individu menunjuk ke memori fisik tertentu, itu dapat menunjuk ke suatu wilayah dalam RAM, atau dapat menunjuk ke alamat yang ditugaskan untuk perangkat fisik, seperti kartu video.
Sebagian besar halaman yang Anda berurusan dengan menunjuk ke RAM atau swap, yaitu, mereka disimpan di hard drive atau SSD Anda. Kernel mengontrol tata letak fisik setiap halaman. Jika halaman spoofed diakses, kernel menghentikan utas yang mencoba mengakses memori, membaca halaman dari hard drive / SSD ke dalam RAM, dan kemudian melanjutkan untuk menjalankan utas.
Proses ini transparan untuk streaming, artinya, tidak harus membaca langsung dari hard drive / SSD. Ukuran halaman normal adalah 4096 byte. Hugepages berukuran 2 megabyte.
Buffer Terjemahan Asosiatif (TLB)
Ketika suatu program mengakses halaman memori, prosesor pusat harus tahu dari mana halaman fisik untuk membaca data (mis., Memiliki peta alamat virtual).
Inti memiliki struktur data (tabel halaman) yang berisi semua informasi tentang halaman yang digunakan. Menggunakan struktur data ini, Anda dapat memetakan alamat virtual ke alamat fisik.
Namun, tabel halaman agak rumit dan berjalan lambat, jadi kami tidak bisa menganalisis seluruh struktur data setiap kali suatu proses mengakses memori.
Untungnya, prosesor kami memiliki TLB yang melakukan cache pemetaan alamat virtual dan fisik. Ini berarti bahwa terlepas dari kenyataan bahwa kami perlu menganalisis tabel halaman saat pertama kali kami mencoba mengaksesnya, semua panggilan halaman berikutnya dapat diproses dalam TLB, yang memastikan operasi cepat.
Karena diimplementasikan sebagai perangkat fisik (yang membuatnya cepat), kapasitasnya terbatas. Karenanya, jika Anda ingin mengakses lebih banyak halaman, TLB tidak akan dapat menyimpan pemetaan untuk semuanya, karena itu program Anda akan bekerja jauh lebih lambat.
Hugepages datang untuk menyelamatkan
Jadi apa yang bisa kita lakukan untuk menghindari TLB overflow? (Kami berasumsi bahwa program masih membutuhkan jumlah memori yang sama).
Di sinilah Hugepages muncul. Alih-alih 4096 byte, hanya membutuhkan satu entri di TLB, satu entri di TLB sekarang dapat mengarah ke 2 megabyte kekalahan. Kami akan menganggap bahwa TLB memiliki 512 entri, di sini tanpa Hugepages kami dapat mencocokkan:
4096 b⋅512=2 MB
Sedangkan dengan mereka kita dapat membandingkan:
2 MB⋅512=1 GB
Itulah mengapa Hugepages mengagumkan. Mereka dapat meningkatkan produktivitas tanpa upaya yang signifikan. Tetapi ada pemesanan yang signifikan.
Hugepages spoofing
Kernel secara otomatis melacak frekuensi penggunaan setiap halaman memori. Jika memori fisik (RAM) tidak cukup, kernel akan memindahkan halaman yang kurang penting (lebih jarang digunakan) ke hard drive untuk membebaskan sebagian RAM untuk halaman yang lebih penting.
Pada dasarnya, hal yang sama berlaku untuk Hugepages. Namun, kernel hanya dapat menukar seluruh halaman, bukan byte individual.
Misalkan kita memiliki program seperti ini:
char* mymemory = malloc(2*1024*1024); // Hugepage! // mymemory - // , // mymemory // ... // putchar(mymemory[0]);
Dalam hal ini, kernel perlu mengganti (baca) informasi sebanyak 2 megabita dari hard drive / SSD hanya agar Anda dapat membaca satu byte. Sedangkan untuk halaman reguler, hanya 4.096 byte yang perlu dibaca dari hard drive / SSD.
Karena itu, jika hugepage diganti, pembacaannya lebih cepat hanya jika Anda perlu mengakses seluruh halaman. Ini berarti bahwa jika Anda mencoba secara acak mengakses berbagai bagian memori dan hanya membaca beberapa kilobyte, Anda harus menggunakan halaman biasa dan tidak perlu khawatir tentang hal lain.
Di sisi lain, jika Anda perlu mengakses sebagian besar memori secara berurutan, hugepage akan meningkatkan produktivitas Anda. Namun demikian, Anda perlu memeriksa ini sendiri (dan bukan pada contoh perangkat lunak abstrak) dan melihat mana yang bekerja lebih cepat.
Alokasi memori
Jika Anda menulis dalam C, Anda tahu bahwa Anda dapat meminta sejumlah kecil (atau hampir sewenang-wenang) jumlah memori dari tumpukan menggunakan malloc() . Katakanlah Anda membutuhkan 30 byte memori:
char* mymemory = malloc(30);
Tampaknya bagi pemrogram Anda "meminta" 30 byte memori dari sistem operasi dan mengembalikan pointer ke beberapa memori virtual. Tetapi sebenarnya malloc () hanyalah fungsi C yang memanggil fungsi brk dan sbrk dari dalam untuk meminta atau membebaskan memori dari sistem operasi.
Namun, meminta lebih banyak dan lebih banyak memori untuk setiap alokasi tidak efisien; kemungkinan besar segmen memori telah dibebaskan (free()) , dan kita dapat menggunakannya kembali. malloc() mengimplementasikan algoritma yang cukup kompleks untuk menggunakan kembali memori yang dibebaskan.
Pada saat yang sama, semuanya terjadi tanpa disadari oleh Anda, jadi mengapa itu harus Anda perhatikan? Tetapi karena panggilan untuk free() tidak berarti bahwa memori akan segera dikembalikan ke sistem operasi .
Ada yang namanya fragmentasi memori. Dalam kasus ekstrim, ada segmen tumpukan di mana hanya beberapa byte yang digunakan, sementara semua di antaranya dibebaskan (free()) .
Perhatikan bahwa fragmentasi memori adalah topik yang sangat kompleks, dan bahkan perubahan kecil pada program dapat mempengaruhinya secara signifikan. Dalam kebanyakan kasus, program tidak menyebabkan fragmentasi memori yang signifikan, tetapi Anda harus ingat bahwa jika fragmentasi terjadi di area tumpukan tertentu, hugepage hanya dapat memperburuk situasi.
Aplikasi kustom hugepages
Setelah membaca artikel, Anda telah menentukan bagian mana dari program Anda yang dapat mengambil manfaat dari penggunaan hugepage dan mana yang tidak. Jadi haruskah hugepage dimasukkan sama sekali?
Untungnya, Anda dapat menggunakan madvise() untuk mengaktifkan hugepaging hanya untuk area memori di mana itu akan berguna.
Untuk memulai, verifikasi bahwa hugepage berfungsi dalam mode madvise (), menggunakan instruksi di awal artikel.
Kemudian, gunakan madvise() untuk memberi tahu kernel dengan tepat di mana harus menggunakan hugepages.
#include <sys/mman.h> // , size_t size = 256*1024*1024; char* mymemory = malloc(size); // hugepages… madvise(mymemory, size, MADV_HUGEPAGE); // … madvise(mymemory, size, MADV_HUGEPAGE | MADV_SEQUENTIAL)
Perhatikan bahwa metode ini hanya merupakan rekomendasi untuk kernel untuk manajemen memori. Ini tidak berarti bahwa kernel akan secara otomatis menggunakan hugepage untuk memori yang diberikan.
Lihat halaman madvise untuk lebih lanjut tentang manajemen memori dan madvise() , kurva belajar yang sangat curam untuk topik ini. Karena itu, jika Anda ingin benar-benar memahaminya, bersiaplah untuk membaca dan mengujinya selama beberapa minggu sebelum menghitung setidaknya beberapa hasil positif.
Apa yang harus dibaca?
Punya pertanyaan? Tulis di komentar!