GreenSQLPerformance issues
Hello,
I installed that latest greensql on a Centos5 machine running the standard cent5 mysql library using some open source benchmarking tests I am getting some fairly bad numbers from going through greensql.
Going through greensql:
Invoked: osdb-my --dbuser root --dbpassword XXXXXXXXXXXXXXXXX --generate-files --size 40MB --datadir /tmp --dbhost 127.0.0.1 --dbport 3305
Compile-time options: none
Restrictions: none
create_tables() 0.01 seconds return value = 0
Creating data files:
/tmp/asap.hundred
/tmp/asap.tenpct
/tmp/asap.tiny
/tmp/asap.uniques
/tmp/asap.updates
create_data() 144.74 seconds return value = 0
Going through mysql:
Invoked: osdb-my --dbuser root --dbpassword XXXXXXXXXXXX --generate-files --size 40MB --datadir /tmp --dbhost 127.0.0.1 --dbport 3306
Compile-time options: none
Restrictions: none
create_tables() 0.00 seconds return value = 0
Creating data files:
/tmp/asap.hundred
/tmp/asap.tenpct
/tmp/asap.tiny
/tmp/asap.uniques
/tmp/asap.updates
create_data() 34.60 seconds return value = 0
Most of the time greensql-fw is taking up ~80% of the CPU and mysql is taking up ~17%. During the mysql only test mysql is taking up 99% of the cpu. I turned logging off and the time it took to going through greensql is ~136 Seconds instead of 144. This is obviously dis concerning as this is a 4X drop in performance.
Any ideas?
Hello kid
Your report looks very interesting. I need to further investigate it. Can you tell me if greensql worked in a firewall mode as discussed here: http://www.greensql.net/publications/greensql-performance-test ?
Thanks,
Yuli
Yuli,
The first time I had ran through I was using the default settings (in my initial posting) and I had whitelisted any commands that had showed up as being blocked. I just re-ran the benchmark with the database under learning mode. After that I turned it to only allowing commands that had been whitelisted. Performance had improved from the 144 seconds to 96 Seconds ( a little less than 3x slower than going directly to mysql is). The problem now is that I cannot consistently get the benchmark to complete successfully. I get either of the following errors:
mysql reports: 2013: Lost connection to MySQL server during query
or
mysql reports: 2014: Commands out of sync; you can't run this command now
or
Error in test create_data() at (10881)osdb-my.c:1120:
... query failed
mysql reports: 2006: MySQL server has gone away
OSDB_ERROR: ERR_DML, (no error text)
On all the mysqld related stuff I was able to successfully connect to mysql afterwards and no errors are reported in the mysql logs.
And a few times now I have had greensql-fw Seg fault in the middle of the benchmark:
[root@localhost greensql-console]# greensql-fw -p /etc/greensql/
Segmentation fault
[root@localhost greensql-console]# greensql-fw -p /etc/greensql/
Segmentation fault
The steps that I can take to reproduce the segfault is:
Drop the osdb database and recreate it;
Run the database benchmark through greensql.
re-run the benchmark through greensql again (most of the time it happens on the second or third time).
The config I am using for the osdb database is:
Blocking Mode: block unlisted in whitelist (after I had ran the benchmark with auto learn turned on)
All privileged actions are allowed.
Let me know if you need anything else.
Hi Kid
Thank you for reporting this bug. It turns to be very serious issue in the application functions.
With the help of the osdb I was able to reproduce this and fixed all bugs I found.
Please check the version from the sourceforge (using svn). If it works for you we will release it ASAP.
Thanks,
Yuli
PS. Here you can find directions how to get application using svn:
http://www.greensql.net/node/113
Hello,
Sorry it took so long to get back to you, been busy lately. I can confirm that the errors that I reported above have been fixed.
I can also report that the SVN version is also much faster than the current stable version. I am seeing the osdb test take ~72 seconds on my machine with a direct to mysql test taking ~35 seconds. This is with it running in either whitelist mode (after a run through in learning mode) and in Block based on risk calculations (with no whitelist in place).
Regards,
Kris