-
Type:
Task
-
Resolution: Works as Designed
-
Priority:
Major - P3
-
None
-
Affects Version/s: WT2.9.0
-
Component/s: None
-
None
-
Storage 2017-02-13
Hi,
In my synthetic test for comparing performance of random update from many threads in 2.8.0 and 2.9.0 I see that 2.8.0 shows better results than 2.9.0, 2.8.0:
Threads count = 1, Total time = 408 usec Threads count = 2, Total time = 189 usec Threads count = 4, Total time = 113 usec Threads count = 8, Total time = 57 usec Threads count = 16, Total time = 91 usec Threads count = 24, Total time = 38 usec
2.9.0:
Threads count = 1, Total time = 1408 usec Threads count = 2, Total time = 968 usec Threads count = 4, Total time = 674 usec Threads count = 8, Total time = 452 usec Threads count = 16, Total time = 284 usec Threads count = 24, Total time = 261 usec
Test attached to this case. Flamegraphs(attached too) show that it is related to behaviour of eviction thread. I can not reproduce this delay in our production environment, so looks like it is not problem for us, but is it expected behaviour? And if so, can you please say what has changed?
- is related to
-
WT-3214 workload stuck due to eviction of dirty data
-
- Closed
-