OPcache restarts under ZTS: php-src fix up for review (php/php-src#24276), and what it changes for worker mode
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ó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 15/100
Hướng nghiên cứu
The issue depends on the upstream php-src change in php/php-src#24276 and asks FrankenPHP to choose how to handle it. Start with zend_accel_schedule_restart_hook and rebootAllThreads() in the Go SAPI code, and with the frankenphp_opcache_restarts metric docs. Done means a decision on whether worker threads are restarted, and the warnings and docs updated to match, which needs maintainer agreement first.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Prepared with an AI assistant (Claude), which also ran the reproduction and the tests on my machine; I reviewed the result. The text below is AI-generated (quoted).
Following the discussion in #2564, #2621 and #2634 (the fix belongs in php-src): php/php-src#24276 is a fix for GH-8739, i.e. OPcache restarts (OOM, hash overflow,
opcache_reset()) wiping SHM while other threads still use it. Nothing needs to change in FrankenPHP for it to work; this issue is to let you know, to ask for testing on your side, and to point out one behaviour change in worker mode that you may want to handle.What the php-src change does. Under ZTS each thread is counted as an OPcache reader from RINIT to the end of the request, and the process keeps the
fcntl()reader lock while any thread is counted, so the restart only runs once no thread uses SHM: instead of theF_GETLKprobe described in #2621, the restarting thread takes an exclusive lock that the kernel refuses while any process holds the reader lock. Related: php/php-src#24272 (a thread finishing its request released other threads' SHM write lock), php/php-src#24273 and php/php-src#24333 (tracing JIT bugs that showed up while testing restarts).Results with FrankenPHP 1.13.0 (AArch64 Linux, Docker; a generated app of 2520 classes, 32 threads, 32M SHM filled under load, then files touched every 5 s to force OOM restarts): PHP-8.4 crashes in 5/5 runs (
zend_mm_heap corrupted,opline->handler == NULL); with the fix 0/10 runs (40 restarts), also withopcache.jit=function, and 146 restarts without a crash in 45 minutes with threads scaling between 8 and 64. Requests/s unchanged within noise.Worker mode: a restart waits for the workers. OPcache RINIT and
post_deactivaterun once per worker lifetime, and a worker keeps using classes from SHM between requests, so with the fix a worker is a reader for its whole life. A scheduled restart therefore waits until all worker threads have been restarted, and until then OPcache stays disabled for new requests (opcache_get_status()['restart_pending']is true; nothing crashes). Not counting workers would bring the crash back. In our worker-mode runs (workers plus classic requests) the restart was still pending at the end of each run, 5/5.If the fix lands, some options for FrankenPHP, for you to judge:
- restart only the worker threads when
zend_accel_schedule_restart_hookfires, asynchronously and throttled; classic threads would not need a reboot, since OPcache carries the restart out by itself at the next request start once no thread uses SHM, which may avoid the reboot loop that led to #2564. One caveat: a thread that starts while the restart is still pending runs without OPcache for that request, and for a worker that is its whole life. So stopping all worker threads first and then starting them again (asrebootAllThreads()does) works better than rebooting them one by one, e.g. with the per-thread reboot used formax_requests;- or only document it, e.g. next to
frankenphp_opcache_restarts;- the warning logged by the hook and the docs of the metric ("other threads may still reference the old memory", "can crash the process") would no longer apply to PHP versions with the fix, and the
opcache_reset()override would no longer be needed in classic mode.Testing. If you can run the PR on your workloads or on the reproducer from #2621, feedback on php/php-src#24276 would help the review there. The branch applies to PHP-8.4 and merges into PHP-8.5.
Unrelated to the races in #2714 (inheritance cache and script hash publication, php/php-src#23637 and php/php-src#24319): this PR does not touch those.
- Ngôn ngữ chính
- Go
- Star
- 11.4k
- Fork
- 494
- Merge trung bình
- 2 ngày 23 giờ
- Pull request đã merge (30 ngày)
- 28
Chuẩn bị môi trường
- Có Dockerfile hoặc 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 php/frankenphp
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
php/frankenphp#2671 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Include frankenphp version in logsCó thể đã có người làm @ousamabenyounes đã nhận 87 ngày trước. Đang mởenhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
php/frankenphp#2483 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
suggestion about compile.mdCó thể làm lại được Pull request cho issue này đã bị đóng mà không được merge. Đang mởenhancement
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 68/100
php/frankenphp#601 · 5 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 8/100
php/frankenphp#2714 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 28/100
php/frankenphp#2713 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của php/frankenphp
Issue tương tự
-
bug frontend grammar sev-3
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 63/100
-
connector docs good first issue
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
soma-intelligence/open-health-sync#134 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug frontend
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Maintainer thường phản hồi trong vòng 3 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
oss/0 pending team/container-integrations
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
DataDog/datadog-agent#58323 ·
Maintainer thường phản hồi trong vòng 1 ngày