diff options
Diffstat (limited to 'sql-bench/Comments')
| -rw-r--r-- | sql-bench/Comments/Access.crash-me | 40 | ||||
| -rw-r--r-- | sql-bench/Comments/Adabas.crash-me | 36 | ||||
| -rw-r--r-- | sql-bench/Comments/Empress.crash-me | 102 | ||||
| -rw-r--r-- | sql-bench/Comments/FrontBase.benchmark | 59 | ||||
| -rw-r--r-- | sql-bench/Comments/Informix.crash-me | 26 | ||||
| -rw-r--r-- | sql-bench/Comments/interbase | 18 | ||||
| -rw-r--r-- | sql-bench/Comments/mysql.benchmark | 39 | ||||
| -rw-r--r-- | sql-bench/Comments/postgres.benchmark | 107 | ||||
| -rw-r--r-- | sql-bench/Comments/postgres.crash-me | 30 |
9 files changed, 0 insertions, 457 deletions
diff --git a/sql-bench/Comments/Access.crash-me b/sql-bench/Comments/Access.crash-me deleted file mode 100644 index f4a419aa159..00000000000 --- a/sql-bench/Comments/Access.crash-me +++ /dev/null @@ -1,40 +0,0 @@ -Access 97 tested through ODBC 1998.04.19, by monty@mysql.com - -Access 97 has a bug when on executes a SELECT follwed very fast with a -DROP TABLE or a DROP INDEX command: - -[Microsoft][ODBC Microsoft Access 97 Driver] The database engine couldn't lock table 'crash_q' because it's already in use by another person or process. (SQL-S1 -000)(DBD: st_execute/SQLExecute err=-1) - -Debugging SQL queries in Access 97 is terrible because most error messages -are of type: - -Error: [Microsoft][ODBC Microsoft Access 97 Driver] Syntax error in CREATE TABLE statement. (SQL-37000)(DBD: st_prepare/SQLPrepare err=-1) - -Which doesn't tell a thing! - --------------- - -Access 2000 tested through ODBC 2000.01.02, by monty@mysql.com - -crash-me takes a LONG time to run under Access 2000. - -The '1+NULL' and the 'OR and AND in WHERE' tests kills -Activestate Perl, build 521, DBI-DBC with an OUT OF MEMORY error. -The later test also kills perl/access with some internal errors. -To go around this one must run crash-me repeatedly with the --restart option. - -Testing of the 'constant string size' (< 500K) takes a LOT of memory -in Access (at least 250M on My computer). - -Testing of number of 'simple expressions' takes REALLY a lot of time -and memory; At some point I was up to 350M of used memory! - -To fix the above, I modified crash-me to have lower max limits in the -above tests. - -Benchmarks (under Win98): - -Running the connect-test will take up all available memory and this -will not be freed even after quitting perl! There is probably some -bug in the Access connect code that eats memory! diff --git a/sql-bench/Comments/Adabas.crash-me b/sql-bench/Comments/Adabas.crash-me deleted file mode 100644 index d36d05047cc..00000000000 --- a/sql-bench/Comments/Adabas.crash-me +++ /dev/null @@ -1,36 +0,0 @@ - -I did not spend much time for tuning crash-me or the limits file. In short, -here's what I did: - - - Put engine into ANSI SQL mode by using the following odbc.ini: - - [ODBC Data Sources] - test - - [test] - ServerDB=test - ServerNode= - SQLMode=3 - - - Grabbed the db_Oracle package and copied it to db_Adabas - - Implemented a 'version' method. - - Ran crash-me with the --restart option; it failed when guessing the - query_size. - - Reran crash-me 3 or 4 times until it succeeded. At some point it - justified its name; I had to restart the Adabas server in the - table name length test ... - - Finally crash-me succeeded. - -That's it, folks. The benchmarks have been running on my P90 machine, -32 MB RAM, with Red Hat Linux 5.0 (Kernel 2.0.33, glibc-2.0.7-6). -Mysql was version 3.21.30, Adabas was version 6.1.15.42 (the one from -the promotion CD of 1997). I was using X11 and Emacs while benchmarking. - -An interesting note: The mysql server had 4 processes, the three usual -ones and a process for serving me, each about 2 MB RAM, including a -shared memory segment of about 900K. Adabas had 10 processes running from -the start, each about 16-20 MB, including a shared segment of 1-5 MB. You -guess which one I prefer ... :-) - - -Jochen Wiedmann, joe@ispsoft.de diff --git a/sql-bench/Comments/Empress.crash-me b/sql-bench/Comments/Empress.crash-me deleted file mode 100644 index b60bf4f19a9..00000000000 --- a/sql-bench/Comments/Empress.crash-me +++ /dev/null @@ -1,102 +0,0 @@ -***************************************************************** -NOTE: -This is an old comment about how it was to run crash-me on empress -the first time. I think it was on Empress 6.0 -***************************************************************** - -start testing empress ... -added a nice line for the max join .... -strip the as out of the from field ... -that's working on empress .... - -at this moment with .... -max constant string size in where .... taking a lot of memory ... -at this moment (it's still growing just waiting till it stops ..) 99mb .. -sorry it started growing again ... -max 170 mb ... then it gives an error ... -Yes it crashed ..... -at max constant string size in where ... with IOT trap/Abort(core dumped) :-) -nice isn't it ... hope it saved the things .... -I outcommented the sig story because I could see how the script is running -and I wasn't sure if SIG{PIPE} ='DEFAULT' ... is working ... -restarting with limit 8333xxx ... couldn't see it any more ... -query is printed ...(200000 lines ..). mmm Nice IOT trap/Abort ... -and again ..and again ... -aha ... and now it's going further ... -max constant string string size in select: ... -taking 100 mb -crashing over and over again .... -max simple expressions ... -is taking ... 82 mb ... -mmmm this is taking very very very long .... after 10 minutes I will kill it and run it again ... I think he can't proces this query that fast ... and will crash any way ... -still growing very slow to the 90 mb ... -killed it ... strange is ... it don't react on ctrl-c ... but kill 15 does work -mmm still bussy with killing his self ... memory is growing to 128 mb ... -sorry .. 150 mb .. and then the output .. -maybe something for the extra things for crash-me ... -if debug .... -if length $query > 300 ... just print $errstr .. else print $query + $errstr .. -at this moment he is still bussy printing .... -first clear all locks ... with empadm test lockclear ... else it will give me -the error with a lock ... -restarting at 4194297 .... mmm a bit high I think ... -after 5 minutes I will kill it ... -mmm have to kill it again ... took 30 mb ..now growing to 42 mb .. -restarting at 838859 ... hope this will crash normaly ... :-) -I will give it again 5 minutes to complete ... -taking 12 mb .... will kill it ... after 4 minutes .... -restarting at 167771 ... taking 6 mb ... give it again 5 minutes .... - will kill it again ... else it becomes to late tonight ... -mmm started with 33xxxx and it crashes ...:-) yes ... -can't we build in a function which will restart his self again ... -mmmm this is really boring .. start it over and over again ... -WHO .... NICE >>>> -Restarting this with high limit: 4097 -................. -*** Program Bug *** setexpr: unknown EXPR = 1254 (4e6) -isn't it ... starting it again ... -finally finished with 4092 .... -now max big expression ..... -directly taking .. 85 mb ... give it again 5 minutes ... -mmm I am going to kill it again ... mmm it grows to 146 mb ... -restarting with 1026 ... taking 25 mb .. -won't give him that long ... because it will crash any way (just a ques) .. -killed it ... -restarting at 205 ... hope this will work .... -won't think so ... give it 2 minutes ... taking 12 mb ... -killed it ...restarting at ... 40 ... yes it crashes ... - 7 is crashing ... 1 ....is good .. finaly ... a long way ... -now max stacked expressions .... -taking 80 mb ... mmmm what sort of test is this ...it looks more like a harddisk test .. but it crashes .. nice ... -mmm a YACC overflow ... that's a nice error ... -but it goes on ... yep it didn't crashed just an error ... - mmm -my patch for the join didn't work ... let's take a look what goes wrong ... -saw it ... forgot some little thing .. mm not .. them ... another little typo -mmm again a really nice bug ... -Restarting this with high limit: 131 -... -*** Program Bug *** xflkadd: too many read locks -them the lock forgotten .... -mmmm bigger problem ... -with empadm test lockinfo ... gives ... -*** System Problem *** no more clients can be registered in coordinator - -*** User Error *** '/usr/local/empress/rdbms/bin/test' is not a valid database -that's really really nice .... -hmmm after coordclear ... it's fine again ... -strange ... - after restarting it again the script ... it is going further .... -the overflow trick is nice and working good ... -now I have table 'crash_q' does not exist for every thing ... -normal ...???? mmm went after all good .. so I think it's normal ... -mmmm a lot of table 'crash_q' does not exist ... again ... -sometimes when the overflow is there ... I restart it and it is saying ... -restarting at xxxx that's not good ... but hey ... what the hack ... -maybe that's good because if one test run's more then 200 times .... -it won't exceeds that test ... -.... -yes finally the end of crash-me ... -at last ... crash-me safe: yes ... -yep don't think so he .... - diff --git a/sql-bench/Comments/FrontBase.benchmark b/sql-bench/Comments/FrontBase.benchmark deleted file mode 100644 index 03386a4d883..00000000000 --- a/sql-bench/Comments/FrontBase.benchmark +++ /dev/null @@ -1,59 +0,0 @@ -# This file describes how to run benchmarks and crash-me with FrontBase - -Installed components: - -- FrontBase-2.1-8.rpm - (had to run with rpm -i --nodeps; the rpm wanted libreadline.so.4.0, - but only libreadline.so.4.1 was available) - -- DBD-FB-0.03.tar.gz - (perl Makefile.Pl; - make; - make test; - make install;) - -- DBI-1.14.tar.gz - (perl Makefile.Pl; - make; - make test; - make install;) - -- Msql-Mysql-modules-1.2215.tar.gz - (perl Makefile.Pl; - make; - make test; - make install;) - -After installations: - -- cd /etc/rc.d - FBWeb start - FrontBase start - -- cd /usr/local/mysql/sql-bench -- FBExec & -- FrontBase test - -crash-me: - -There were a lot of troubles running the crash-me; FrontBase core -dumped several tens of times while crash-me was trying to determine -the maximum values in different areas. - -The crash-me program itself was also needed to be tuned quite a lot -for FB. There were also some bugs/lacking features in the crash-me -program, which are now fixed to the new version. - -After we finally got the limits, we runned the benchmarks. - -benchmarks: - -Problems again. Frontbase core dumped with every part of the -benchmark (8/8) tests. After a lot of fine-tuning we got the -benchmarks to run through. The maximum values had to be dropped -down a lot in many of the tests. - -The benchmarks were run with the following command: - -perl run-all-tests --server=frontbase --host=prima ---cmp=frontbase,mysql --tcpip --log diff --git a/sql-bench/Comments/Informix.crash-me b/sql-bench/Comments/Informix.crash-me deleted file mode 100644 index 557db012dd8..00000000000 --- a/sql-bench/Comments/Informix.crash-me +++ /dev/null @@ -1,26 +0,0 @@ -***************************************************************** -NOTE: -I, Monty, pulled this comment out from the public mail I got from -Honza when he published the first crash-me run on Informix -***************************************************************** - -Also attached are diffs from server-cfg and crash-me -- some of -them are actual bugs in the code, some add extensions for Informix, -some of the comment-outs were necessary to finish the test. Some of -the problematic pieces that are commented out sent Informix to -veeeery long load 1 on the machine (max_conditions for example), so -could be considered crashes, but I'd prefer that someone checks the -code before giving out such a conclusion. - -Some of the code that is commented out failed with some other SQL -error message which might mean a problem with the sequence of commands -in crash-me. Interesting thing, some of the tests failed for the -first time but in the next or third run went OK, so the results are -results of more iterations (like column doesn't exist in the first -try but the second pass goes OK). - -I'd like to hear your comments on the bug fixes and Informix specific -code before we go into debugging the problems. - -Yours, - Honza Pazdziora diff --git a/sql-bench/Comments/interbase b/sql-bench/Comments/interbase deleted file mode 100644 index addaf74b63f..00000000000 --- a/sql-bench/Comments/interbase +++ /dev/null @@ -1,18 +0,0 @@ -Running crash-me on Interbase: -I -- got opensource version of interbase 6.0.1 - (both mode, classic and superserver), -- set up DBD::InterBase from cpan, -- created database "test" and set sql_dialect for that database to 3 -- executed crash-me for both interbase's models (classic and superserver). - -There were some problems during the execution: -1) Sometimes client side got SIGSEGV , At that moment server side - writes - gds__alloc: non-positive size allocation request - to log file. - This problem has both models. I am not shure if it's interbase or - DBD:InterBase problem (though DBD::InterBase made all nesessary - tests during the installation without any problem) - -2) In "superserver" mode ibserver several times died (and ibguard restarted it) diff --git a/sql-bench/Comments/mysql.benchmark b/sql-bench/Comments/mysql.benchmark deleted file mode 100644 index 9c28e8e506b..00000000000 --- a/sql-bench/Comments/mysql.benchmark +++ /dev/null @@ -1,39 +0,0 @@ -# This file describes how to run MySQL benchmarks with MySQL -# - -# The test was run on a Intel Xeon 2x 550 Mzh machine with 1G memory, -# 9G hard disk. The OS is Suse 6.4, with Linux 2.2.14 compiled with SMP -# support -# Both the perl client and the database server is run -# on the same machine. No other cpu intensive process was used during -# the benchmark. - -# -# -# First, install MySQL from RPM or compile it according to the -# recommendations in the MySQL manual -# - -# Start MySQL - -bin/safe_mysqld -O key_buffer=16M & - -# -# Now we run the test that can be found in the sql-bench directory in the -# MySQL 3.23 source distribution with and without --fast -# -# Note that if you want to make a results that is comparead to some database, -# You should add "--cmp=databasename" as an extra option to the test -# -$CMP=--cmp=pg - -run-all-tests --comment="Intel Xeon, 2x550 Mhz, 1G, key_buffer=16M" $CMP -run-all-tests --comment="Intel Xeon, 2x550 Mhz, 1G, key_buffer=16M" --fast $CMP - -# If you want to store the results in a output/RUN-xxx file, you should -# repeate the benchmark with the extra option --log --use-old-result -# This will create a the RUN file based of the previous results -# - -run-all-tests --comment="Intel Xeon, 2x550 Mhz, 1G, key_buffer=16M" --log --use-old-result $CMP -run-all-tests --comment="Intel Xeon, 2x550 Mhz, 1G, key_buffer=16M" --fast --log --use-old-result $CMP diff --git a/sql-bench/Comments/postgres.benchmark b/sql-bench/Comments/postgres.benchmark deleted file mode 100644 index c52a53699e0..00000000000 --- a/sql-bench/Comments/postgres.benchmark +++ /dev/null @@ -1,107 +0,0 @@ -# This file describes how to run MySQL benchmark suite with PostgreSQL -# -# WARNING: -# -# Don't run the --fast test on a PostgreSQL 7.1.1 database on -# which you have any critical data; During one of our test runs -# PostgreSQL got a corrupted database and all data was destroyed! -# When we tried to restart postmaster, It died with a -# 'no such file or directory' error and never recovered from that! -# -# Another time vacuum() filled our system disk with had 6G free -# while vaccuming a table of 60 M. -# -# WARNING - -# The test was run on a Intel Xeon 2x 550 Mzh machine with 1G memory, -# 9G hard disk. The OS is Suse 7.1, with Linux 2.4.2 compiled with SMP -# support -# Both the perl client and the database server is run -# on the same machine. No other cpu intensive process was used during -# the benchmark. -# -# During the test we run PostgreSQL with -o -F, not async mode (not ACID safe) -# because when we started postmaster without -o -F, PostgreSQL log files -# filled up a 9G disk until postmaster crashed. -# We did however notice that with -o -F, PostgreSQL was a magnitude slower -# than when not using -o -F. - -# -# First, install postgresql-7.1.2.tar.gz - -# Adding the following lines to your ~/.bash_profile or -# corresponding file. If you are using csh, use īsetenvī. - -export POSTGRES_INCLUDE=/usr/local/pg/include -export POSTGRES_LIB=/usr/local/pg/lib - -PATH=$PATH:/usr/local/pg/bin -MANPATH=$MANPATH:/usr/local/pg/man - -# -# Add the following line to /etc/ld.so.conf: -# - -/usr/local/pg/lib - -# and run: - -ldconfig - -# untar the postgres source distribution, cd to postgresql-* -# and run the following commands: - -CFLAGS=-O3 ./configure -gmake -gmake install - -mkdir /usr/local/pg/data -chown postgres /usr/local/pg/data -su - postgres -/usr/local/pg/bin/initdb -D /usr/local/pg/data -/usr/local/pg/bin/postmaster -o -F -D /usr/local/pg/data & -/usr/local/pg/bin/createdb test -exit - -# -# Second, install packages DBD-Pg-1.00.tar.gz and DBI-1.18.tar.gz, -# available from http://www.perl.com/CPAN/ - -export POSTGRES_LIB=/usr/local/pg/lib/ -export POSTGRES_INCLUDE=/usr/local/pg/include/postgresql -perl Makefile.PL -make -make install - -# -# Now we run the test that can be found in the sql-bench directory in the -# MySQL 3.23 source distribution. -# -# We did run two tests: -# The standard test - -run-all-tests --comment="Intel Xeon, 2x550 Mhz, 512M, pg started with -o -F" --user=postgres --server=pg --cmp=mysql - -# When running with --fast we run the following vacuum commands on -# the database between each major update of the tables: -# vacuum anlyze table -# vacuum table -# or -# vacuum analyze -# vacuum - -# The time for vacuum() is accounted for in the book-keeping() column, not -# in the test that updates the database. - -run-all-tests --comment="Intel Xeon, 2x550 Mhz, 512M, pg started with -o -F" --user=postgres --server=pg --cmp=mysql --fast - -# If you want to store the results in a output/RUN-xxx file, you should -# repeate the benchmark with the extra option --log --use-old-result -# This will create a the RUN file based of the previous results - -run-all-tests --comment="Intel Xeon, 2x550 Mhz, 512M, pg started with -o -F" --user=postgres --server=pg --cmp=mysql --log --use-old-result -run-all-tests --comment="Intel Xeon, 2x550 Mhz, 512MG, pg started with -o -F" --user=postgres --server=pg --cmp=mysql --fast --log --use-old-result - -# Between running the different tests we dropped and recreated the PostgreSQL -# database to ensure that PostgreSQL should get a clean start, -# independent of the previous runs. diff --git a/sql-bench/Comments/postgres.crash-me b/sql-bench/Comments/postgres.crash-me deleted file mode 100644 index c693817cc91..00000000000 --- a/sql-bench/Comments/postgres.crash-me +++ /dev/null @@ -1,30 +0,0 @@ -***************************************************************** -NOTE: -This is an old comment about how it was to run crash-me on postgreSQL -the first time. I think it was on pg 6.2 -***************************************************************** - -mmm memory use of postgres is very very much ... -at this moment I am testing it ... -and the tables in join: is taking 200MB memory ... -I am happy to have 400mb swap ... so he can do have it ... -but other programs will give some errors ... -just a second ago ... vim core dumped .. XFree crashed full ... to the prompt -the menu bar of redhat disappeared .... -at this momemt the max is 215 mb memore postgres is taking ... - -the problem with postgres is the following error: -PQexec() -- Request was sent to backend, but backend closed the channel before r -esponding. This probably means the backend terminated abnormally before or whil -e processing the request - -I think we can solve this with a goto command ... to go back again ... after -the connect again ... -postgres is taking 377 mb .... mmm allmost out of memory ... 53mb left .. -mmm it's growing ... 389 mb ..393 mb ... 397 mb .. better can wait for the out of memory ... i think 409 412 max ... - -ps added some nice code for the channel closing ... -it must now do again the query when the error is the above error ... -hopes this helps ... -after crashing my X again ... -I stopped testing postgres |