Conversation
Under sustained load the provider1 event loop was being preempted by sidecar containers sharing the same cores, inflating tail latency and producing multi-second scheduler jitter spikes even when total CPU utilisation was moderate. Defaults to cores 0-3 for provider1 and 4-5 for everything else on a 6-core host; both are env-overridable so smaller/larger hosts can adapt without editing the compose file. Measured on one production node during a live load window: - avg request latency 2429ms -> 1987ms (-18%) - >10s outliers eliminated - 3-10s bucket cut ~58% - share of sub-1s responses ~1.75x Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
No updates since Nothing is lost — Converting to draft disables auto-merge, so PRs with auto-merge enabled are excluded from this entirely. |
|
No updates since Nothing is lost — Converting to draft disables auto-merge, so PRs with auto-merge enabled are excluded from this entirely. |
|
No updates since Nothing is lost — Converting to draft disables auto-merge, so PRs with auto-merge enabled are excluded from this entirely. |
|
No updates since Nothing is lost — Converting to draft disables auto-merge, so PRs with auto-merge enabled are excluded from this entirely. |
|
No updates since Nothing is lost — Converting to draft disables auto-merge, so PRs with auto-merge enabled are excluded from this entirely. |
|
No updates since Nothing is lost — Converting to draft disables auto-merge, so PRs with auto-merge enabled are excluded from this entirely. |
|
No updates since Nothing is lost — Converting to draft disables auto-merge, so PRs with auto-merge enabled are excluded from this entirely. |
|
No updates since Nothing is lost — Converting to draft disables auto-merge, so PRs with auto-merge enabled are excluded from this entirely. |
|
No updates since Nothing is lost — Converting to draft disables auto-merge, so PRs with auto-merge enabled are excluded from this entirely. |
|
No updates since Nothing is lost — Converting to draft disables auto-merge, so PRs with auto-merge enabled are excluded from this entirely. |
|
No updates since Nothing is lost — Converting to draft disables auto-merge, so PRs with auto-merge enabled are excluded from this entirely. |
|
No updates since Nothing is lost — Converting to draft disables auto-merge, so PRs with auto-merge enabled are excluded from this entirely. |
|
No updates since Nothing is lost — Converting to draft disables auto-merge, so PRs with auto-merge enabled are excluded from this entirely. |
|
No updates since Nothing is lost — Converting to draft disables auto-merge, so PRs with auto-merge enabled are excluded from this entirely. |
|
No updates since Nothing is lost — Converting to draft disables auto-merge, so PRs with auto-merge enabled are excluded from this entirely. |
|
No updates since Nothing is lost — Converting to draft disables auto-merge, so PRs with auto-merge enabled are excluded from this entirely. |
|
No updates since Nothing is lost — Converting to draft disables auto-merge, so PRs with auto-merge enabled are excluded from this entirely. |
Summary
cpusetto every service indocker-compose.provider.ymlPROVIDER1_CPUSET,SHARED_CPUSET) so hosts with different core counts can adapt without editing the compose fileWhy
Under sustained load the provider1 event loop was being preempted by sidecar containers competing for the same cores, inflating tail latency and producing multi-second scheduler jitter spikes even when total CPU utilisation across the box was moderate.
%stealwas reporting 0% but Redis--intrinsic-latencyon the affected node showed 3× the worst-case jitter of a peer node, consistent with in-guest scheduler contention rather than pure noisy-neighbour steal.Measured impact (single production node during a live load window)
Rollout
docker compose up -don each hostPROVIDER1_CPUSET/SHARED_CPUSETin its env before compose-upTest plan
docker compose configparses cleanly on a provider hostdocker inspect provider1 --format '{{.HostConfig.CpusetCpus}}'returns0-3🤖 Generated with Claude Code