Skip to content
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

Closed
firebird-automations opened this issue Aug 22, 2008 · 12 comments
Closed

Comments

@firebird-automations
Copy link
Collaborator

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

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

assignee: Vlad Khorsun [ hvlad ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

It seems HEAD is not affected

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

Version: 2.5 Alpha 1 [ 10224 ] =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.1.2 [ 10270 ]

Fix Version: 2.0.5 [ 10222 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

Link: This issue is related to CORE1819 [ CORE1819 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Paulius Pazera (ppazera)

could somebody confirm that this fix still works in 2.1.2rc1/2? (see CORE2334)

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

This code was not changed (at least directly) since 2.1.1

@firebird-automations
Copy link
Collaborator Author

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

@firebird-automations
Copy link
Collaborator Author

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.

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

QA Status: No test

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Closed [ 6 ] => Closed [ 6 ]

QA Status: No test => Cannot be tested

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment