Issue Details (XML | Word | Printable)

Key: CORE-2050
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Vlad Khorsun
Reporter: Alexander Peshkov
Votes: 0
Watchers: 3
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Performance regression - too many semop() system calls

Created: 22/Aug/08 09:07 AM   Updated: 13/Mar/09 08:30 AM
Component/s: Engine
Affects Version/s: 2.0.4, 2.1.1
Fix Version/s: 2.0.5, 2.1.2

Time Tracking:
Not Specified

Environment: posix
Issue Links:
Relate
 

Planning Status: Unspecified


 Description  « Hide
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.

 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Vlad Khorsun added a comment - 02/Sep/08 06:56 PM
It seems HEAD is not affected

Paulius Pazera added a comment - 13/Mar/09 06:48 AM
could somebody confirm that this fix still works in 2.1.2rc1/2? (see CORE-2334)

Vlad Khorsun added a comment - 13/Mar/09 07:00 AM
This code was not changed (at least directly) since 2.1.1

Paulius Pazera added a comment - 13/Mar/09 07:21 AM
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


Alexander Peshkov added a comment - 13/Mar/09 08:30 AM
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.