Tango database
- ← previous page
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- next page →
|
|
---|---|
finally I've cleaned my DB with duplicated rows. Also we've excluded mysql db files from TSM backup (replacing it by mysqldump) and I cannot see any higher spikes. Now the results of my tests with the innodb-patch look as follows which seems to be acceptable (max < 0.25 sec). |
|
|
---|---|
Hi Jan, Because you have everything already set-up, if I send you a patch file for the DB server with still MyISAM tables but with a specialized treatment for creation/update of attribute properties used for memorized attribute, will it be possible for you to run your test? Cheers Emmanuel |
|
|
---|---|
Hi Emmanuel, yes sure. I can switch back to myisam and perform the test. It would be good to have a patch for tango 8.1.2. (In other cases I can adopt it by myself) Cheers, Jan |
|
|
---|---|
Hi, I just started to run my test for myisam engine (without any patch) and I need longer tests but it seems that after removing duplicated rows from my db my test plots look much better. Comparing innodb with myisam:
Bests, Jan |
|
|
---|---|
Hi Jan, Sorry not to send you a real patch file! Could you add the following method in your DataBase class with the associated method declaration in the .h file
and in the method DataBase::db_put_device_attribute_property2() after the call to GetTime(before)
Thank's a lot for your help and your time Cheers Emmanuel |
|
|
---|---|
Hi Emmanuel, It is fine for me. I will do the test. Cheers, Jan |
|
|
---|---|
Hi Emmanuel, Your patch needs an improvment. When I run the test new rows are added to the property_attribute_device table (which is wrong). MySQL is clever enough to see if modification is done or not, i.e. mysql_affected_rows(…) return 0 if row has not been changed (but update has been executed). So it is better to check if the insert query should be executed in another way, e.g. by a select query. Cheers, Jan |
|
|
---|---|
Jan, What we have to do is : - Create the entry in the table for the first time the memorized attribute is written and then only update the stored value each time the attribute is written. What the change is doing (or try to do) is: - First UPDATE the value even if it does not exist yet. We do this first because as soon as the entry is created, it is the only db operation required - If the update hasn't modified anything in db (which means that the entry was not already created in DB) then create the entry with one INSERT The idea is to not do any SELECT This is not what you are experiencing? What are the new row(s) created? Cheers Manu |
|
|
---|---|
Hi Manu, the problem is that in newer versions of mysql if you call update query to set some value but the value is still the same (has not been changed ) then mysql_affected_rows(…) returns 0 (but in the patch you expect to be 1). After short run my tango db is four times bigger with additional duplicated rows for memorized attributes. Stackoverflow Cheers, Jan |
|
|
---|---|
Jan, Which version of MySQL are you using? I have 5.6.19 Manu |
- ← previous page
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- next page →