When an instance is extremely CPU-starved, increasing the thread pool size will not help because the rate at which new Hystrix commands are scheduled on threads is slower than the rate at which commands are being queued.
I confirmed this empirically by sreading 50 slow-responding Parts that were assigned to a single thread pool across 2 separate thread pools (and thus doubled the effective queue size) and observed that after splitting, there were zero "command could not be queued" errors.
When an instance is extremely CPU-starved, increasing the thread pool size will not help because the rate at which new Hystrix commands are scheduled on threads is slower than the rate at which commands are being queued.
I confirmed this empirically by sreading 50 slow-responding Parts that were assigned to a single thread pool across 2 separate thread pools (and thus doubled the effective queue size) and observed that after splitting, there were zero "command could not be queued" errors.