77 lines
3.8 KiB
Diff
77 lines
3.8 KiB
Diff
Fix a 100% CPU worker spin in zstd-nginx-module 0.1.1 (tokers), triggered when a
|
|
compressible response is flushed mid-stream while being zstd-compressed.
|
|
|
|
Trigger: nginx injects an empty flush buffer via
|
|
ngx_http_send_special(r, NGX_HTTP_FLUSH) whenever the body is flushed without
|
|
new data -- `proxy_buffering off`, an upstream sending "X-Accel-Buffering: no",
|
|
Server-Sent Events / long-poll, FastCGI buffering off, or PHP flush()/ob_flush()
|
|
-- on a content type in zstd_types, to a client advertising
|
|
"Accept-Encoding: zstd" (Chrome 123+ and Firefox 126+ do by default).
|
|
|
|
Root cause: in ngx_http_zstd_filter_compress(), ZSTD_compressStream() returns a
|
|
*size hint* (the recommended next input size), not the amount of pending output,
|
|
so it is almost always > 0. The module misreads rc > 0 as "more output pending",
|
|
flips COMPRESS -> FLUSH and re-enters. ZSTD_flushStream() then returns 0 having
|
|
produced no bytes, the action is restored to COMPRESS, and ctx->flush is never
|
|
cleared (it is only cleared on the output-producing path). COMPRESS <-> FLUSH
|
|
then toggles forever: the worker pins one core at 100%, never returns to the
|
|
event loop (so a configuration reload cannot reap it) and survives until killed.
|
|
|
|
Fix: when a flush or end completes (ZSTD returned 0) without producing output,
|
|
clear ctx->flush / the GZIP_BUFFERED flag and stop instead of looping. No buffer
|
|
is manufactured -- a zero-length data buffer would be rejected by
|
|
ngx_http_write_filter ("zero size buf in writer"); the already-compressed data
|
|
has been emitted on the output-producing path, so there is nothing left to send.
|
|
|
|
Upstream tokers/zstd-nginx-module is effectively unmaintained (0.1.1 is the
|
|
latest tag, 2023-10-23), so this is carried as a local patch.
|
|
|
|
Verified against vanilla nginx 1.31.2 + module 0.1.1: unpatched pins a worker at
|
|
100% CPU (state R) on an unbuffered flushed response and never recovers; patched
|
|
keeps the worker idle (state S) and the streamed response decodes to a complete,
|
|
valid zstd frame (zstd -t: FRAME OK).
|
|
|
|
--- a/filter/ngx_http_zstd_filter_module.c 2026-06-30 20:51:33.329153852 +0000
|
|
+++ b/filter/ngx_http_zstd_filter_module.c 2026-06-30 21:05:09.666179333 +0000
|
|
@@ -460,6 +460,40 @@
|
|
}
|
|
|
|
if (ngx_buf_size(ctx->out_buf) == 0) {
|
|
+
|
|
+ if (rc == 0 && (ctx->flush || ctx->last)) {
|
|
+ /*
|
|
+ * twiy/raweb fix for the zstd-nginx-module 0.1.1 worker CPU spin.
|
|
+ *
|
|
+ * A flush or end has just completed (ZSTD_flushStream()/
|
|
+ * ZSTD_endStream() returned 0) but produced no output: the zstd
|
|
+ * stream buffer was already drained, so there is nothing left to
|
|
+ * emit downstream. Clear the pending flush bookkeeping here instead
|
|
+ * of looping; do NOT manufacture a buffer (a zero-length data buf
|
|
+ * is rejected by ngx_http_write_filter with "zero size buf in
|
|
+ * writer").
|
|
+ *
|
|
+ * Without this an empty flush buffer -- injected by nginx via
|
|
+ * ngx_http_send_special(NGX_HTTP_FLUSH): proxy_buffering off,
|
|
+ * "X-Accel-Buffering: no", SSE, FastCGI flush, PHP flush() --
|
|
+ * wedges the worker at 100% CPU forever. ZSTD_compressStream()
|
|
+ * returns a non-zero *size hint* (recommended next input size, not
|
|
+ * pending output) that is misread as "redo", flipping
|
|
+ * COMPRESS->FLUSH; ZSTD_flushStream() then returns 0 with no
|
|
+ * output; ctx->flush is only cleared on the output-producing path
|
|
+ * below, which is never reached, so COMPRESS<->FLUSH toggles
|
|
+ * indefinitely.
|
|
+ */
|
|
+
|
|
+ r->connection->buffered &= ~NGX_HTTP_GZIP_BUFFERED;
|
|
+ ctx->flush = 0;
|
|
+
|
|
+ if (ctx->last) {
|
|
+ ctx->done = 1;
|
|
+ return NGX_OK;
|
|
+ }
|
|
+ }
|
|
+
|
|
return NGX_AGAIN;
|
|
}
|
|
|