Support configurable initial/minimum heap size relative to (/as a percentage of) calculated Xmx
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 55/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Lĩnh vực
- build-system, devops
Hướng nghiên cứu
Bắt đầu từ entry point memory_calculator và so sánh hành vi hiện tại của nó với ánh xạ memory_initials của 3.x trong config/open_jdk_jre.yml và tài liệu được liên kết. Công việc hoàn tất khi một tùy chọn có thể đặt kích thước heap ban đầu theo tỷ lệ phần trăm của heap tối đa được tự động tính toán mà không yêu cầu biết Xmx theo cách thủ công.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
In the 3.x line of the buildpack, config/open_jdk_jre.yml supported a memory_initials mapping, allowing the initial size of each memory region (heap, permgen, metaspace) to be configured as a percentage of its calculated maximum. (https://github.com/cloudfoundry/java-buildpack/blob/3.x/docs/jre-open_jdk_jre.md). This option no longer appears from v4.0 onward (2017), including the current Go-based v5.x buildpack.
Because -Xmx is only known at container start (it depends on the memory limit assigned to the app instance), we cannot set a matching or proportional -Xms value ourselves via JAVA_OPTS, because we'd need to know the calculated -Xmx ahead of time. In practice this means our JVMs start with a small default initial heap and grow it under load, causing avoidable heap-resize activity that didn't happen back when memory_initials was available.
Could memory_calculator support such an option again to set the initial heap size as a percentage of the calculated max heap? This would let us keep using the automatic memory calculation while avoiding heap growth pauses after startup.
- Ngôn ngữ chính
- Go
- Star
- 452
- Fork
- 2.5k
- Merge trung bình
- 1 ngày 5 giờ
- Pull request đã merge (30 ngày)
- 20
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của cloudfoundry/java-buildpack
-
v5.1.0 GA release planĐang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 68/100
cloudfoundry/java-buildpack#1423 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 52/100
cloudfoundry/java-buildpack#1364 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
elastic-otel-java supportĐang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 55/100
cloudfoundry/java-buildpack#1342 · 1 bình luận · 2 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 45/100
cloudfoundry/java-buildpack#1151 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của cloudfoundry/java-buildpack
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug needs-acceptance wg/developer-experience-ecosystem
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
vllm-project/semantic-router#4480 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
area/docs kind/documentation priority/backlog triage/accepted
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
lexfrei/cloudflare-tunnel-gateway-controller#943 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
keyxmakerx/Chronicle#967 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
DaoCloud/DaoCloud-docs#7446 ·
Maintainer thường phản hồi trong vòng 1 ngày