[JAVA-137] SimplePool._get() "busy" wait suffers under heavy load. Created: 23/Jul/10 Updated: 24/Jul/10 Resolved: 24/Jul/10 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | None |
| Affects Version/s: | 1.4 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Steve Reed | Assignee: | Eliot Horowitz (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
mongo java driver 1.4 default settings for max connections, etc. |
||
| Description |
|
After investigating an issue where a service was using 100% of available CPU yet not accomplishing much, I saw that most threads had the following at the top of the java stack trace: at java.lang.Thread.sleep(Thread.java) Our software was running with a few (maybe ~2x) more threads than connections, and was doing a fair mix of read and write in mongo. Our reads are typically cursoring over many objects. When we write to mongo we always call resetError() and getLastError() to verify the write. I read through the 1.4 java driver code and saw that for every DBMessage created (in our case, many thousands per second), the thread enters what I consider a busy wait (despite a 15 millisecond Thread.sleep()) while it waits for a ByteEncoder. This ended up accounting for a significant percentage of our overall CPU load. Have you considered using wait() and notify()? Or different ByteEncoder creation/allocation strategies (such as ThreadLocal)? |
| Comments |
| Comment by Eliot Horowitz (Inactive) [ 24/Jul/10 ] |
|
you should try 2.0 |