Java-buildpack: Tidak mungkin menjalankan aplikasi Spring Boot dengan konfigurasi default dan <512M

Dimungkinkan untuk menjalankan dengan kurang dari 512M dengan mengkonfigurasi kalkulator memori.
Manifes berikut berfungsi untuk saya (boot musim semi + webflux).

applications:
- name: myapp
  path: target/myapp-0.0.1-SNAPSHOT.jar
  memory: 256m
  env:
    JAVA_OPTS: '-XX:ReservedCodeCacheSize=32M -XX:MaxDirectMemorySize=32M'
    JBP_CONFIG_OPEN_JDK_JRE: '[memory_calculator: {stack_threads: 30}, jre: {version: 11.+}]'

Aplikasi vanilla webflux sebenarnya hanya berjalan dengan ram 60MB.

Saya penggemar berat kalkulator memori karena sebagian besar pengembang cenderung hanya peduli dengan ukuran tumpukan dan mendapatkan OOME yang tidak terduga (misalnya Metaspace) tetapi saya setuju bahwa kami dapat meningkatkannya.
Ukuran utas default (300?) di kalkulator akan terlalu besar untuk setidaknya webflux.

Untuk pemula, cukup sulit menemukan cara untuk menyesuaikan ukuran memori.
Contoh konfigurasi dengan usecase di README akan sangat membantu.

@making Saya telah memperbarui judul masalah ini untuk memperjelas bahwa ini tentang konfigurasi default yang kurang optimal untuk (setidaknya) aplikasi Boot. Tentu saja sangat mungkin untuk menjalankan aplikasi Boot dengan 256M dan konfigurasi khusus, tetapi konfigurasi memori default menurut saya sangat jauh dari akurat dan di situlah saya ingin kami membuat beberapa kemajuan, karena itu berdampak pada banyak pengguna.

Jumlah utas yang Anda sebutkan untuk aplikasi WebFlux memang menjadi poin yang sangat menarik, paket build dapat memberikan nilai tambah tambahan dengan mendeteksi jenis aplikasi apa itu. Ini mungkin rumit karena beberapa aplikasi MVC dapat menggunakan Reactive WebClient , tetapi saya yakin kita dapat melakukan sesuatu yang lebih pintar dan akurat.

Konfigurasi memori khusus Anda menyoroti IMO bahwa ada sesuatu yang salah dalam mekanisme konfigurasi otomatis. Seperti yang dijelaskan di https://github.com/cloudfoundry/java-buildpack-memory-calculator/issues/24 , jika saya menentukan secara eksplisit jumlah kelas (antara 8000 dan 10000) yang secara efektif digunakan oleh aplikasi Boot, parameter yang dihasilkan adalah -XX:ReservedCodeCacheSize=240M , di mana Anda menentukan -XX:ReservedCodeCacheSize=32M . Perbedaan ini sangat besar, bisakah kita membuat tebakan yang lebih terdidik?

Juga 8000 atau 10000 adalah jumlah kelas yang digunakan secara efektif oleh aplikasi Boot. Jika paket build menghitungnya dari jumlah kelas dalam aplikasi + dependensi, saya cenderung berpikir jumlah kelas yang ditentukan untuk kalkulator memori akan sangat tinggi (saya masih perlu memeriksa nilai yang saat ini ditebak tetapi paket build) karena sifat dari Spring Framework JAR.

Saya juga bertanya-tanya apakah kami memanfaatkan opsi memori wadah baru yang tersedia di Java 8 terbaru dan di Java 11. Mereka dirancang untuk Docker tetapi saya kira kami juga dapat mengambil manfaat dari ini di Cloud Foundry. Apakah Java runtime sadar bahwa kami berjalan dalam wadah meskipun CF tidak menggunakan Docker? Apakah kita memanfaatkan opsi seperti -XX:InitialRAMPercentage , -XX:MaxRAMPercentage atau -XX:MinRAMPercentage ?

Ini adalah masalah rumit @sdeleuze. Apakah java-buildpack menggunakan default java, yang kami anggap beberapa pemikiran masuk ke pengaturan java, memungkinkan aplikasi berfungsi, secara default, lebih seperti yang mereka lakukan ketika tidak berjalan di CF? Atau apakah java-buildpack mengubah default untuk membuat pengalaman awal lebih baik tetapi kemudian membiarkan pengguna mencari jawaban ketika aplikasi tidak berjalan seperti yang diharapkan tidak dalam CF?

Hari ini java-buildpack telah memilih untuk menggunakan default java dan Tomcat yang mempercayai nilai-nilai tersebut sebagai aplikasi umum saat ini. Saya pribadi lebih menyukai pendekatan itu daripada mengubah default Java yang dapat memengaruhi aplikasi dengan cara yang tidak terlalu terlihat/eksplisit bagi pengguna.

Sejauh properti baru berjalan, pemahaman saya tentang properti RAMPercentage adalah bahwa mereka secara otomatis menetapkan nilai tumpukan berdasarkan persentase ram yang tersedia. Tidak ada pemikiran untuk persyaratan memori non heap seperti ukuran cache kode, ukuran tumpukan utas, metaspace, overhead memori GC, dll. Pekerjaan itu masih tersisa sebagai latihan bagi pengguna untuk menebak berapa banyak memori non heap yang dibutuhkan aplikasi mereka. Saya menantikan suatu hari ketika Java dapat dengan mudah mengelola semua kumpulan memori dengan benar untuk menyimpan aplikasi dalam batasan memori dari sebuah wadah. Tapi saya curiga kita masih jauh dari itu.

Sebagai catatan tambahan, ini adalah konfigurasi JAVA_OPTS dan jre yang saya atur untuk aplikasi saya yang saya butuhkan untuk stabil dengan memori rendah dan kecepatan bukan faktor.

• Saya mengatur MaxMetaSize ke ditemukan melalui pembuatan profil.
  JAVA_OPTS

-Xss256K -Xms1M -XX:+UseSerialGC -Djava.compiler=none -XX:ReservedCodeCacheSize=2496k -XX:MaxDirectMemorySize=1M

konfigurasi jre

  stack_threads: 20