New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Performance regression - too many semop() system calls [CORE2050] #2486
Comments
Modified by: @AlexPeshkoffassignee: Vlad Khorsun [ hvlad ] |
Commented by: @hvlad It seems HEAD is not affected |
Modified by: @hvladVersion: 2.5 Alpha 1 [ 10224 ] => |
Modified by: @hvladstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 2.1.2 [ 10270 ] Fix Version: 2.0.5 [ 10222 ] |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
Commented by: Paulius Pazera (ppazera) could somebody confirm that this fix still works in 2.1.2rc1/2? (see CORE2334) |
Commented by: @hvlad This code was not changed (at least directly) since 2.1.1 |
Commented by: Paulius Pazera (ppazera) do you remember approximately how many semop() calls were before and after the fix, and how did it compare with v1.5? I'm asking because 2.1.2rc1 performed worse than another test build with semop() fix somebody made for us in August 2008. Thus I did strace and I see 250 semop() calls in v1.5.5 versus 10906 semop() calls in 2.1.2rc1.5snapshot. Thus I wonder if that's normal or something happened |
Commented by: @AlexPeshkoff Paulius, I remember that test a little. Problems took place when number of semop() calls in it became about 1 million. When explicit unlock() in index add code was removed, the number of semop() calls became MUCH smaller (but who remebers explicit digit) and the problems have gone. On my mind current 10000 can't seriously affect performance cause number of them is less than for example number of read(). BTW, total number of system calls in 2.1.2 is less than in 1.5. I.e. if we have problems with performance this is not due to too many system calls. |
Modified by: @pavel-zotovQA Status: No test |
Modified by: @pavel-zotovstatus: Closed [ 6 ] => Closed [ 6 ] QA Status: No test => Cannot be tested |
Submitted by: @AlexPeshkoff
Is related to CORE1819
Class BtrPageGCLock always explicitly releases locks taken to protect index pages from garbage collection instead of AST use. This leads to abnormally intensive flow of semop() system calls, causing performance problems when inserting records in a table with too many indices.
Commits: 5eff6e9 c14a633
The text was updated successfully, but these errors were encountered: