Java-buildpack: Tidak dapat memulai aplikasi java dengan versi buildpack b08a692

Dikonfirmasi. Kami juga melihat masalah ini,

Tolong bisakah Anda memposting kegagalan yang tepat dari log aplikasi.

Kalkulator memori buildpack Java telah ditingkatkan ke v3 oleh commit b08a692. v3 menghormati default OpenJDK untuk cache kode yang dicadangkan, yang pada Java 8 adalah 240 MB. Sepertinya inilah yang menyebabkan aplikasi gagal dimulai. Anda dapat mengganti nilai yang digunakan oleh kalkulator memori seperti pada contoh berikut:

cf set-env app-name JAVA_OPTS '-XX:ReservedCodeCacheSize=64m'

tetapi Anda harus memilih ukuran yang sesuai karena jika Anda membuatnya terlalu kecil, konsumsi CPU aplikasi dapat menjadi tinggi.

Karena melakukan https://github.com/cloudfoundry/Java-buildpack/commit/b08a69221a9ecfa61a9bfd568639f891b9313a19 , aplikasi kami juga gagal memuat/rusak dengan OutOfMemory:Metaspace . Tampaknya kalkulator memori (v3+) tidak lagi menggunakan ~10% memori untuk metaspace tetapi menetapkan ukuran metaspace maksimum menjadi ~56m.

Solusi: Gunakan rilis v3.14 (https://github.com/cloudfoundry/Java-buildpack.git#v3.14) alih-alih yang terbaru.

Kami melihat masalah serupa, tetapi disebabkan oleh CompressedClassSpace yang tidak mencukupi - tidak terlalu jauh, memberi kami 8385K , sementara kami sebenarnya membutuhkan lebih banyak seperti 8704K .

@markbigler Kalkulator memori v3 memperkirakan konsumsi metaspace berdasarkan jumlah file kelas dalam aplikasi. Jika ini tidak mencukupi, Anda dapat mengatur batas metaspace menggunakan, misalnya:

cf set-env app-name JAVA_OPTS '-XX:MaxMetaspaceSize=100m'

@ipsi Demikian pula untuk ruang kelas terkompresi. Anda dapat mengaturnya menggunakan, misalnya:

cf set-env app-name JAVA_OPTS '-XX:CompressedClassSpaceSize=20m'

masalah yang sama di sini, mendapatkan kesalahan kehabisan memori

Masalah yang sama di sini. Menggunakan versi lama dari buildpack untuk sementara menyelesaikannya:

cf push -b https://github.com/cloudfoundry/java-buildpack.git\#v3.12

Pertanyaan StackOverflow untuk topik ini: http://stackoverflow.com/questions/42576613/java-spring-application-cannot-start-up-on-cloudfoundry-outofmemoryerror-compre

terima kasih itu berhasil!

Kami melihat masalah serupa di sini, perhitungan kelas akan gagal untuk pelanggan yang menggunakan agen kami karena javaagent kami adalah biner asli untuk alasan kinerja. Saya ingin melihat kalkulator menjadi sedikit kurang agresif atau beberapa instruksi untuk memanipulasi fungsi kalkulator melalui ekstensi. Harus memberi tahu semua pelanggan kami untuk menentukan opsi Java tambahan secara manual adalah kurang optimal...

@akirasoft Terima kasih telah menjelaskan kasus penggunaan Anda. Bagaimana Anda ingin memengaruhi perilaku kalkulator? Misalnya, apakah masuk akal untuk menyesuaikan perkiraan jumlah kelas yang dimuat (yang diteruskan Java buildpack ke kalkulator memori) dan kemudian membiarkan kalkulator mendapatkan pengaturan memori berdasarkan perkiraan baru? Jika demikian, apakah javaagent Anda menambahkan jumlah kelas yang tetap atau apakah jumlah yang ditambahkan bergantung (linier?) pada jumlah kelas yang dimuat oleh aplikasi?

@glyn jejak kami akan menjadi beberapa ruang datar tambahan untuk menampung agen kami dan kemudian sedikit lebih banyak ruang secara proporsional berdasarkan kelas daripada yang diharapkan kalkulator Anda, katakan 1-3% tambahan, jika saya harus menebak. Secara umum menurut saya kalkulator ini agak terlalu agresif berdasarkan komentar lain di sini. Semuanya bekerja dengan baik selama sekitar satu tahun terakhir dengan kalkulator sebelumnya.

Sama disini. Aplikasi ini (https://github.com/EuregJUG-Maas-Rhine/site, Spring Boot) tidak dapat dijalankan lagi (CompressedClassSpace).

Saya juga memiliki masalah yang sama. Mengembalikan ke versi yang lebih lama juga memperbaikinya untuk saya.

Masalah yang sama dengan aplikasi saya juga. Kembali ke v3.13

Kami juga melihat OutOfMemoryErrors:

2017-03-06T09:20:39.44+0900 [App/0] OUT # java.lang.OutOfMemoryError: Compressed class space

mungkin heuristik v3 perlu disetel

@akirasoft "beberapa ruang datar tambahan" kemungkinan akan dibagi menjadi heap, metaspace, dan ruang kelas terkompresi (atau permgen di Java 7) dan bahkan mungkin memengaruhi cache kode yang dicadangkan dan konsumsi memori langsung, jadi itu tidak cukup untuk menambahkan konstanta ke formula tunggal untuk memperhitungkan kebutuhan agen. Apakah mungkin untuk membingkai konsumsi "ruang datar" agen dalam hal jumlah kelas yang dimuat yang setara? Lihat desain kalkulator memori v3 untuk detail tentang bagaimana perhitungan itu terjadi.

Kami sedang dalam proses membuat kalkulator memori mengalokasikan lebih banyak ruang metaspace dan ruang kelas terkompresi. Lihat komit c9867a6 untuk detailnya.

Kalkulator memori v3.2.0.RELEASE tersedia. Silakan coba lagi aplikasi Anda dan lihat apakah sekarang berfungsi.

@glyn kami berbicara melalui Slack tetapi semuanya terlihat jauh lebih baik sekarang, terima kasih atas perbaikannya!

Saya telah kembali ke buildpack v3.12, ini berfungsi dengan baik.

Karena telah dirujuk ke masalah yang lebih akurat #391, saya menutup masalah ini untuk saat ini.

Terima kasih bantuan semua orang.