Issue Details (XML | Word | Printable)

Key: CORE-5727
Type: Improvement Improvement
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Vlad Khorsun
Reporter: Vlad Khorsun
Votes: 0
Watchers: 2

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

Make faster engine response on cancel\shutdown signals when scanning long list of pointer pages

Created: 28/Jan/18 10:01 AM   Updated: 06/Feb/18 09:09 PM
Component/s: Engine
Affects Version/s: 3.0.2, 4.0 Alpha 1, 2.5.8
Fix Version/s: 3.0.3, 4.0 Beta 1

QA Status: Cannot be tested
Test Details:
Tried to reproduce on 65 Gb (oltp-emul) and 500+ gb (real system) databases, repeat two times: with FileSystemCacheThreshold greater than and less than DefaultDBCachePages.
table in bot cases contained about 1600 PP. Linux page cache was flushed and cleared before each run of .sql

On Firebird where this fix was not applied (2.5.7, build: 27086) time of preparing query was very small, less than 700 ms. Can not compare such value with smth other.

Sent several letters to hvlad (last: 05-feb-2018 23:56).

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Vlad Khorsun added a comment - 28/Jan/18 10:06 AM
Currently there is two known cases when engine could not response fast enough on cancel attachment or shutdown signal:
1. when preparing query and evaluating cardinality of huge table with thousands of pointer pages,
2, when sweep looking for data page to cleanup but there is no such data page (after massive load of data, for example).

Pavel Zotov added a comment - 28/Jan/18 10:22 AM
Please, consider also inscrutable behaviour of SIMILAR TO operator.
See, for example, CORE-3858

I've repeated again "mistic statement" from there, and all the same: could not get reply from "gfix -shut full -force 0" for ~ 2 minutes on Windows 8.1, recent FB 4.0 build.

Vlad Khorsun added a comment - 28/Jan/18 09:49 PM

CORE-3858 have absolutely different reasons.

Pavel Zotov added a comment - 28/Jan/18 10:11 PM
Vlad, i know, of course. I mean: "engine could not response fast enough" - not only of those two reasons that you have mentioned above. Beside very poor performance, changing DB state to full shutdown is impossible during valuable time.