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
The issue:
- every new attachment need to read nbackup allocation table from disk (i.e. from a delta file)
- while reading, attachment holds SH lock on allocation table, so all readers share this lock and proceed in parallel
- when some other attachment need to allocate new page in delta file, it acquires EX lock on alloc table.
This lock request go to common queue AND blocks all next requests for the same lock despite of they level.
- when new attachments established very often, some of them will be put in queue after EX lock requests and
will wait until current SH owners finish they work (could be long enough if they are read whole allocation table)
and until blocked EX owner finish its work (write 2 or 3 pages in allocation table)
The improvement:
Start to read allocation table not acquiring alloc lock at all and acquire SH lock only when last page of allocation
table is read.
This is safe because allocation table is appended only and already full pages are never modified.
So, we can significantly reduce period of time when SH lock must be hold by new attachments.
Submitted by: @hvlad
The issue:
- every new attachment need to read nbackup allocation table from disk (i.e. from a delta file)
- while reading, attachment holds SH lock on allocation table, so all readers share this lock and proceed in parallel
- when some other attachment need to allocate new page in delta file, it acquires EX lock on alloc table.
This lock request go to common queue AND blocks all next requests for the same lock despite of they level.
- when new attachments established very often, some of them will be put in queue after EX lock requests and
will wait until current SH owners finish they work (could be long enough if they are read whole allocation table)
and until blocked EX owner finish its work (write 2 or 3 pages in allocation table)
The improvement:
Start to read allocation table not acquiring alloc lock at all and acquire SH lock only when last page of allocation
table is read.
This is safe because allocation table is appended only and already full pages are never modified.
So, we can significantly reduce period of time when SH lock must be hold by new attachments.
Commits: 6a80667 87ee6b8 FirebirdSQL/fbt-repository@cff9a16 FirebirdSQL/fbt-repository@eefc95a
The text was updated successfully, but these errors were encountered: