FirebirdSQL / oltp-emul

2 stars 0 forks source link

Debian/Ubuntu: Executable isql is not firebird related #1

Open mikini opened 5 years ago

mikini commented 5 years ago

On Debian/Ubuntu the isql executable in default $PATH (/usr/bin/isql) is from the unixodbc package (ubuntu/debian) and the isql from the firebird package (ubuntu/debian) has been renamed to isql-fb to avoid conflict.

On an Ubuntu 16.04 system:

$ dpkg -S $(which isql)
unixodbc: /usr/bin/isql
$ dpkg -S $(which isql-fb)
firebird2.5-super: /usr/bin/isql-fb
$ 

This means that using the src/1run_oltp_emul.sh script from the repository configured with $fbc=/usr/bin is failing of non-obvious reasons when it executes the unixodbc isql which takes different arguments than isql-fb:

...
Script that verifies finish of DB building process is NOT EMPTY.
...
db_build_finished_ok=|0|
Result: database needs to be REBUILT.

Database: >/web/db/oltp25_test.fdb< -- DOES exist but
process of creation its objects was not completed.
...
Error log /var/tmp/logs.oltp25/tmp_build_25.err is NOT EMPTY!
...
Additional info / advice:
Check SQL script at line that was specified in error message.

Script is terminated.

Even worse, a user cannot configure the script or environment to use the binaries directly from /usr/bin as the script is hardcoded to call the executables by absolute paths as $fbc/isql and $fbc/fbsvcmgr, respectively.

If the script just used the isql and fbsvcmgr in $PATH a user would be able to modify the path externally to satisfy oltp-emul.

Instead one has to do tricks like the below and point $fbc to ~/oltp-emul/bin to make the benchmark run:

$ mkdir ~/oltp-emul/bin
$ cd ~/oltp-emul/bin
$ ln -sv /usr/bin/fbsvcmgr .
'./fbsvcmgr' -> '/usr/bin/fbsvcmgr'
$ ln -sv /usr/bin/isql-fb isql
'isql' -> '/usr/bin/isql-fb'
$
pavel-zotov commented 5 years ago

Hello Mikkel!

Sorry for my too late reply. I will try to fix this, perhaps by introducing new optional parameter into oltpNN_config.nix files. Why do you use FB from POSIX repository ? I'm afraid that you will encounter many crashes of FB while running this test: LI-V2.5.4.26856 was issued 30-mar-2015, four years ago. Many bugs were found and fixed since this date in 2.5.x.

PS. Please feel free to discuss or ask any questions related to this test by e-mail: p519446@yandex.ru Best regards, Pavel Zotov.

pavel-zotov commented 5 years ago

Fix completed, please get recent version of test again. Note on new config parameter: 'clu' and comments for it. I checked FB 2.5.4 installed from Ubuntu repo, and used following values in oltp25_config.nix: fbc = /usr/bin clu = isql-fb

mikini commented 5 years ago

Nice, thanks. I see it as a part of a5286bf891e8976f1b65cffb4ad78d5ab2c64867. I'll do some testing when time permits. Currently we coped with some benchmark numbers from a proprietary tool but we are blind regarding test conditions and functions and thus unsure how to interpret comparisons between systems properly.

Does you note about differing firebird.conf paths affect running the suite on Ubuntu/Debian? When attempted I saw it halt after ~4 minutes when I expected a default test_time of 180 plus warm_time of 30. Didn't go deep into analysing the output so maybe some basic rquirement was still not satisfied after doing the isql-fb trick.

pavel-zotov commented 5 years ago

unsure how to interpret comparisons between systems properly. This test shows as 'overall performance score' average number of transactions that completed successfully (i.e. without any exception) per one minute during phase. One transaction always correspond here to one business action, i.e. this can be both trivial and complex set of actions. It is not the same as in TPC-C because they take in account only one kind of business action. Namely: only client order, first operation in a business chain. Because of this, in order to have results that can be considered as reliable, you have to: 1) use not empty database; rather, it must have pretty big size, as in real life; 2) give database to be 'warmed-up', i.e. give all sessions to work for minutes in order to get some part ot DB into OS and Firebird page cache; 3) assign to value not less than 180 minutes.

pavel-zotov commented 5 years ago

Does you note about differing firebird.conf paths affect running the suite on Ubuntu/Debian? Can you clarify, please: do you mean that test .sh files somehow change environment variable PATH ? (sorry, my english is very far from ideal...)

mikini commented 5 years ago

Hi Pavel. Thanks for the hints for running oltp-emul. You seem to do fine, I probably didn't express myself clearly enough. The interpretation difficulties I mentioned was for the alternative benchmarker we used instead of it. I never got actual results out of oltp_emul. So the conf question was mostly to try to identify whether wrong conf file locations might have been the reason that I didn't see the test run to end.

Regarding the use of the Ubuntu package; in GNU/Linux (*NIX, POSIX or however you prefer to refer to such a system) it is normally regarded as a good, secure and robust practise to use a distribution's packages if at all possible. This is done to reduce the probability of upgrades causing issues and to have the distribution's approach to software installation applied to as much as the system as possible to reduce interference between installed software. In production systems we actually doesn't use the package from the official Ubuntu repositories (2.5.4.26856) because it is such an old timer. Firebird is not frequently used and thus has less focus by Canonical. Instead we use the Ubuntu PPA (Personal Package Archive) of a single developer Popa Adrian Marius which provides 2.5.6.27020 for xenial (16.04).

At the moment I don't think we'll have the time to deep dive into doing a full oltp_emul test, sadly. But I'll promise to test the $clu config var on my system and report back.

pavel-zotov commented 5 years ago

whether wrong conf file locations might have been the reason that I didn't see the test run to end.

If you speak about firebird.conf then default value of DefaultDBCachePages, LockHashSlots and LockMemSize definitely can be a reason of test show very poor performance. If you will use standard FB_HOME path ('/opt/firebird/') then test (before start ISQL sessions) will check presense there of FileSystemCacheThreshold parameter and compare its value with mon$database.mon$page_buffers. If your FileSystemCacheThreshold became less than mon$database.mon$page_buffers then test will stop with asking you to increase FileSystemCacheThreshold. But if firebird.conf lives in other folder then test will not search for it and its execution will go further.

But I'll promise to test the $clu config var on my system and report back.

OK, please feel free to ask any questions about test. Better on e-mail than here - i will be noticed about your message immediately in this case.

hmoffatt commented 4 years ago

clu = isql-fb is working fine for me on Debian. I think you can close this.

hmoffatt commented 4 years ago

I spoke too soon. There are two places in oltp_isql_run_worker.sh which refer to $fbc/isql rather than using $isql_name, so the final report is not generated. Here is a patch:

diff --git a/src/oltp_isql_run_worker.sh b/src/oltp_isql_run_worker.sh
index c71d013..d84536e 100644
--- a/src/oltp_isql_run_worker.sh
+++ b/src/oltp_isql_run_worker.sh
@@ -302,7 +302,7 @@ add_html_table() {
     ### call isql for get SQLDA and parse column names and types ###
     ################################################################
     #set -x
-    $fbc/isql $dbconn $dbauth -i $sql_temp 1>$tmp_sqlda 2>$sql_err
+    $isql_name $dbconn $dbauth -i $sql_temp 1>$tmp_sqlda 2>$sql_err
     #set +x

     if [[ -s "$sql_err" ]]; then
@@ -413,7 +413,7 @@ add_html_table() {
     ######################################
     ### call isql for show report data ###
     ######################################
-    $fbc/isql $dbconn $dbauth -i $sql_temp 1>$sql_log 2>$sql_err
+    $isql_name $dbconn $dbauth -i $sql_temp 1>$sql_log 2>$sql_err

     while read line; do
         # this leaves one trailing space, do NOT: fld_name=${line:0:31}