Java-buildpack: Menyetel Variabel Lingkungan Glibc (misalnya MALLOC_ARENA_MAX)

Ini adalah masalah lain yang kami diskusikan @nebhale.

Setelah melihat beberapa masalah memori Java baru-baru ini, saya menemukan dua artikel berikut dari Heroku (haruskah saya menyebutnya "Yang tidak dapat disebutkan namanya"? : P):

Menyetel Perilaku Memori glibc
Menguji Penggunaan Memori Cedar-14

Yang menunjukkan bahwa menyetel MALLOC_ARENA_MAX dapat membantu masalah memori dalam aplikasi. Tampaknya itu juga menyebabkan masalah bagi Hadoop , meskipun itu mungkin kesalahan mereka sendiri untuk memantau VMEM (serius, kawan, mengapa?!).

Dalam pengujian saya sendiri, saya perhatikan bahwa pengaturan MALLOC_ARENA_MAX tampaknya membantu memperlambat pertumbuhan memori, meskipun _tidak_ mencegahnya sepenuhnya.

Ada implikasi kinerja dari pengaturan MALLOC_ARENA_MAX (Saya selalu menyetelnya ke 2 , seperti yang disarankan oleh Heroku), tetapi hasilnya seperti ini:

• Utas baru dibuat, meminta arena
• Jika < MALLOC_ARENA_MAX blok sedang digunakan (default pada 8 * cpu_count ), dapatkan satu.
• Jika >, bagikan yang sudah ada
• Ketika malloc ing memori baru, jika memiliki penggunaan eksklusif arena, tidak perlu mengunci.
• Jika dibagikan, harus dikunci, sehingga mengakibatkan perebutan memori. Sebelum glibc memperkenalkan arena, semua utas bersaing untuk memori yang sama.
• Saat utas keluar, glibc menandai arena sebagai "gratis", tetapi _tidak_ mengembalikannya ke OS.

Itu pemahaman saya dalam hal apapun. Jadi saya pikir sebagian besar aplikasi Java di CF pada dasarnya tidak terpengaruh karena alasan berikut:

• Jumlah terbatas dari thread-thrashing. Jika menjadi perhatian utama, dapat mengonfigurasi wadah untuk memiliki min_threads = max_threads . Sebagian besar utas berumur panjang dan memproses banyak permintaan.
• Java tidak melakukan malloc pada basis per-utas - itu mallocs ruang tumpukan saat memulai, dan kemudian menulisnya sesuai kebutuhan. Sejauh yang saya tahu, setelah utas berjalan, seharusnya tidak perlu melakukan level OS malloc , artinya kami tidak akan pernah memiliki pertikaian level OS untuk memori (yang ditarik ke runtime Java ).
  
  
  
  • NIO dan hal-hal seperti ByteBuffer s mungkin menghasilkan panggilan malloc - tidak yakin tentang itu.
  
  

Dengan semua itu, setelah menggali lebih dalam tentang ini, sepertinya pengaturan MALLOC_ARENA_MAX mungkin baru saja menyembunyikan masalah yang lebih dalam, dan saya tidak yakin apakah saya akan menyarankan pengaturannya secara default. Tampaknya tidak mempengaruhi kinerja secara negatif, tetapi kedua aplikasi yang saya uji secara efektif tidak berkinerja baik berdasarkan desain, jadi jangan anggap itu sebagai Injil.

Saya awalnya berpikir bahwa mungkin ada masalah memori di sini, tapi saya tidak begitu yakin lagi. Saya pikir skenario berikut adalah apa yang akan terjadi jika ada kebocoran memori:

MALLOC_ARENAS_MAX tidak terbatas

• Thread meminta arena
• Benang mendapat arena
• Benang memenuhi arena, tidak pernah membebaskan memori
• Thread meminta arena baru
• Ulangi sampai cgroup OOM killer nya.

MALLOC_ARENAS_MAX disetel ke 2

• Thread meminta arena
• Benang mendapat arena
• Benang memenuhi arena, tidak pernah membebaskan memori
• Thread meminta arena baru, tetapi tidak ada lagi yang tersedia.
• Thread malah menulis ke arena "utama" (atau tumpukan program asli dalam kasus ini), yang tidak terbatas. Diberi waktu yang cukup, cgroup OOM killer hits.

(Keputusan alokasi sebenarnya jauh lebih kompleks - ini sangat disederhanakan. Lihat Memahami glibc malloc untuk penjelasan mendalam).

Ini akan menjelaskan mengapa saya melihat ruang heap yang dilaporkan oleh pmap (yang _bukan_ Java Heap!) naik dan naik di salah satu pengujian saya - ada kebocoran memori di suatu tempat dalam kode asli, arena mendapat terisi, dan setelah penuh, itu harus kembali menggunakan tumpukan asli.

Dengan semua itu, beberapa kelonggaran untuk memori asli yang digunakan oleh masing-masing utas mungkin harus dibuat. Jika cukup kecil, mungkin bisa tetap berada di bagian "asli" kalkulator. Jika tidak, karena relatif terhadap jumlah utas yang digunakan, mungkin perlu dihitung entah bagaimana.

Terlepas dari keputusan untuk mengaturnya, saya _do_ berpikir bahwa mendokumentasikannya akan sangat berguna (bersama dengan bagaimana kaitannya dengan Java, dll), seperti menyediakan tautan ke variabel lingkungan konfigurasi glibc lainnya. Menemukan informasi ini _tidak_ semudah yang saya inginkan. Saya pikir ini juga harus didokumentasikan untuk buildpack lain juga - Ruby dan Go, khususnya, lebih cenderung melihat masalah dengan arena memori - perhatikan bahwa contoh Heroku semuanya berbicara tentang Ruby.