You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A producer that could not seat a pull-serve marked the send done without
transferring, so the consumer learned of the failure only by waiting out
its transfer timeout; a consumer that could not seat a read failed it
silently.
The producer now waits for staging to free, bounded by the transfer
deadline, and reports a transfer failure when a request still cannot be
seated. A request larger than the staging can ever seat -- a fixed slot,
or the whole per-transfer pool -- fails at once. The misses while waiting
are not logged; the one failure message on each side carries the request,
the pages asked, and the pages free, so an exhausted pool is attributed
where it happens.
Measured on the setup of the previous commit: at 4 fixed slots the load
exhausted staging 1112 times across 139 requests, each visible only as a
consumer-side failure. With staging on demand none occurred.
Memory and performance results for on-demand staging itself are in the
commit that introduces it, "Stage disaggregation transfers on demand
instead of in fixed slots" (github.com//pull/722).
During shutdown a producer waiting for staging stops instead of sleeping
out its deadline, and the manager's destructor waits for every pull-serve
worker before tearing down the state they read.
0 commit comments