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
Copy file name to clipboardexpand all lines: pquery-go-expert.sh
+1-1
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@
9
9
# MULTI_THREADS is set to 3
10
10
# MULTI_THREADS_INCREASE is set to 3
11
11
# MULTI_THREADS_MAX is set to 9
12
-
# STAGE1_LINES is set to 7 # This was previously 13, which is better for stable systems, as it will allow reducer to continue towards auto pquery-go-expert.sh. Auto-ge (i.e. all other stages after stage 1, as can also be set/done by calling ~/ge) is good for non-sporadic issues as it will drop any uncessary lines after stage 1 in stage 2. However, it is not good for sporadic issues as this will leave regularly 5-10 lines in the testcase which are not needed, requiring one to lower the number of STAGE1_LINES and re-running reducer. The tradeoff however is that one needs to be more diligent in checking runs and regularly CTRL+C > ~/ge for trials which have reduced to a large number of lines. To reach some 'ideal' tradeoff between the two, for the moment 5 was chosen. Updated to 7 on 25/9/21 to better cater for tests which exactly require 5 lines. This will still require some trials (i.e. the non-sporadic ones) to be CTRL+C > ~/ge'd, and some trials (the sporadic ones) where STAGE1_LINES needs to be set lower. Ideally, at some point, an auto-restart-reducers script may be best where FORCE_SKIPV is tested and changes are made based on the result. Thinking about it, it may be better to include this functionality in reducer itself. The risk is that the issue does not reproduce even on 50 threads (auto-increased). To counter this, another type of STAGE V may be implemented; one which executes the testcase up to 10000 times. This is slow however, and then perhas the current system is best; rely on the skill of the engineer to see difference between sporadic/non-sporadic.
12
+
# STAGE1_LINES is set to 13 # This was previously 13, which is better for stable systems, as it will allow reducer to continue towards auto pquery-go-expert.sh. Auto-ge (i.e. all other stages after stage 1, as can also be set/done by calling ~/ge) is good for non-sporadic issues as it will drop any uncessary lines after stage 1 in stage 2. However, it is not good for sporadic issues as this will leave regularly 5-10 lines in the testcase which are not needed, requiring one to lower the number of STAGE1_LINES and re-running reducer. The tradeoff however is that one needs to be more diligent in checking runs and regularly CTRL+C > ~/ge for trials which have reduced to a large number of lines. To reach some 'ideal' tradeoff between the two, for the moment 5 was chosen. Updated to 7 on 25/9/21 to better cater for tests which exactly require 5 lines. This will still require some trials (i.e. the non-sporadic ones) to be CTRL+C > ~/ge'd, and some trials (the sporadic ones) where STAGE1_LINES needs to be set lower. Ideally, at some point, an auto-restart-reducers script may be best where FORCE_SKIPV is tested and changes are made based on the result. Thinking about it, it may be better to include this functionality in reducer itself. The risk is that the issue does not reproduce even on 50 threads (auto-increased). To counter this, another type of STAGE V may be implemented; one which executes the testcase up to 10000 times. This is slow however, and then perhas the current system is best; rely on the skill of the engineer to see difference between sporadic/non-sporadic.
13
13
# INPUTFILE is auto-optimized towards latest sql trace inc _out* handling
14
14
# The effect of FORCE_SKIPV=1 is that reducer will skip the verify stage, start reduction immediately, using 3 threads (MULTI_THREADS=3), and never increases the set amount of
15
15
# threads (result of using FORCE_SKIPV=1). Note that MULTI_THREADS_INCREASE is only relevant for non-FORCE_SKIPV runs, more on why this is changed then below.
0 commit comments