[SERVER-17382] rc10/wiredTiger multi collection/DB bulk insert slow than rc8 in initial insertion phase Created: 25/Feb/15 Updated: 24/Apr/15 Resolved: 27/Mar/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | WiredTiger |
| Affects Version/s: | 3.0.0-rc10 |
| Fix Version/s: | 3.0.2, 3.1.1 |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | Rui Zhang (Inactive) | Assignee: | David Hows |
| Resolution: | Done | Votes: | 0 |
| Labels: | 28qa, cap-ss | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Backport Completed: | |||||||||
| Participants: | |||||||||
| Description |
|
re-test rc10 for
after debug, found out that rc10
Combine this with the way sysbench insert is designed (pin one thread one collection), it could amplify the impact in overall throughput. Run bulk insert with benchRun show insert throughput is similar between rc10 & rc8. I think the high number of very slow insert is still an issue. |
| Comments |
| Comment by Michael Cahill (Inactive) [ 02/Mar/15 ] | |||||||||||||||||||||||||||
|
fdoray, can you share details of the LTTng tracing? | |||||||||||||||||||||||||||
| Comment by Michael Cahill (Inactive) [ 02/Mar/15 ] | |||||||||||||||||||||||||||
|
Thanks for the extra information: as mentioned by darren.wood@10gen.com, this issue will be fixed by https://github.com/wiredtiger/wiredtiger/pull/1706 | |||||||||||||||||||||||||||
| Comment by François Doray [ 02/Mar/15 ] | |||||||||||||||||||||||||||
|
Slow inserts (>750 ms) spend most of their time in this call stack:
Manual observations reveal that the __evict_server thread runs for about 0.3ms just before the "query" thread stops its series of timers, so I guess it's that thread that allows the execution to continue. There is almost no CPU/disk usage during the execution of the timers... For inserts [500 ms, 750 ms], the main source of contention seems to be disk operations. See attached flame graph. [blockdevice] means that the thread is waiting for a request to the disk to be completed. These observations come from an LTTng trace, captured on Ubuntu 14.04. | |||||||||||||||||||||||||||
| Comment by Rui Zhang (Inactive) [ 25/Feb/15 ] | |||||||||||||||||||||||||||
|
long-run-rc10_benchRun.log.html show the slow insert in the first couple minutes. |