5 ms·
running more threads than CPUs is useful whenever your workload is not 100% CPU-bound. a DB workload is likely IO-bound, so many threads will just be sittin' th
by igor47 8y ago
running more threads than CPUs is useful whenever your workload is not 100% CPU-bound. a DB workload is likely IO-bound, so many threads will just be sittin' there waiting to be woken up a lot of the time
- blattimwind 8y ago> no IO is performed
- Cyphus 8y agoA DB that performs no IO? Can you elaborate?
- stingraycharles 8y agoUsually that means a read-heavy workload where things fit in RAM.
- blattimwind 8y agoThat's a literal quote from the article. The benchmark was done entirely done in-memory.
- imtringued 8y agoThere is no such thing as no I/O. If you're latency bound by the round trip to main memory then SMT will still have a noticeable benefit. The most important thing it can't help with is if you are compute bound.
- BeeOnRope 8y agoNobody calls "trips to memory" I/O though. Yes SMT can have a benefit but the OP was asking about the case with more threads than logical cores, so SMT is already maxed out (assuming all threads are CPU bound).
- rbanffy 8y ago> SMT will still have a noticeable benefit YMMV. SMT usually halves the cache size usable by each thread. If your memory access is heavily local, enabling SMT can hurt your performance.
- duckerude 8y agoReferring to this sentence, I think: >To test CPU performance, I used a read-only in-memory sysbench OLTP benchmark, as it burns CPU cycles and no IO is performed by Percona Server.