You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
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.