Adding a column to the filecache is super time consuming (depending on db) #22747

Closed
butonic opened this Issue Mar 1, 2016 · 56 comments

Comments

Projects
None yet
9 participants
@butonic
Member

butonic commented Mar 1, 2016

The resulting ALTER TABLE for the added checksum column in OC9 will create a temp table with the same columns as the filecache, add the colum, COPY the table content and finally rename it and delete the original table. Big installations will experience a very long downtime as we have seen today with a huge activity table change when updating to oc 8.2.2.

In this case mysql 5.5 was used. In the documentation for it I see no way around copying the contents: http://dev.mysql.com/doc/refman/5.5/en/alter-table.html#idm140603778401088 It seems this has still not changed with mysql 5.7: http://dev.mysql.com/doc/refman/5.7/en/innodb-create-index-overview.html#idm140023654764880 although it should be less of a performance hog.

cc @MorrisJobke @DeepDiver1975 @karlitschek

@butonic butonic added the performance label Mar 1, 2016

@butonic butonic added this to the 9.0-current milestone Mar 1, 2016

@butonic butonic added the db:mysql label Mar 1, 2016

@butonic

This comment has been minimized.

Show comment
Hide comment
@butonic

butonic Mar 1, 2016

Member

Postgres may omit rebuilding the table if no default value is specified: http://www.postgresql.org/docs/9.5/static/sql-altertable.html#AEN72358

Member

butonic commented Mar 1, 2016

Postgres may omit rebuilding the table if no default value is specified: http://www.postgresql.org/docs/9.5/static/sql-altertable.html#AEN72358

@karlitschek

This comment has been minimized.

Show comment
Hide comment
@karlitschek

karlitschek Mar 1, 2016

Member

yes. this is actually the wanted behavior. we want to simulate the upgrade because we actually touch the real table. the reason is that we had a ton of bugs before triggered by combinations of specific db types and servers with specific limitations. certain sometimes broken entries in the table, size limitations ir the combination of all if that.
so we destroyed user data in the past.
the fix is to copy the table first and test it. it is accepted that this takes some times but is better then destroying the database.
experienced admin can skip this if they tested the upgrade manually befores

Member

karlitschek commented Mar 1, 2016

yes. this is actually the wanted behavior. we want to simulate the upgrade because we actually touch the real table. the reason is that we had a ton of bugs before triggered by combinations of specific db types and servers with specific limitations. certain sometimes broken entries in the table, size limitations ir the combination of all if that.
so we destroyed user data in the past.
the fix is to copy the table first and test it. it is accepted that this takes some times but is better then destroying the database.
experienced admin can skip this if they tested the upgrade manually befores

@MorrisJobke

This comment has been minimized.

Show comment
Hide comment
@MorrisJobke

MorrisJobke Mar 1, 2016

Member

the fix is to copy the table first and test it. it is accepted that this takes some times but is better then destroying the database.

It's not our code that copies the table. It's mysql that copies the table. We run the upgrade simulation steps -> that itself triggers a copy of the same table in mysql (1) and apply the schema update (ALTER TABLE) which itself will copy the table internally(2). Then we run the same on the actual code (3+4).

This means we copy the whole table 4 times instead of 1 time. This totally kills bigger installations on mysql.

I guess we either need a way to figure out why mysql copies the table sometimes when a column is added (I guess this is the case when the whole table doesn't fit in memory).

Member

MorrisJobke commented Mar 1, 2016

the fix is to copy the table first and test it. it is accepted that this takes some times but is better then destroying the database.

It's not our code that copies the table. It's mysql that copies the table. We run the upgrade simulation steps -> that itself triggers a copy of the same table in mysql (1) and apply the schema update (ALTER TABLE) which itself will copy the table internally(2). Then we run the same on the actual code (3+4).

This means we copy the whole table 4 times instead of 1 time. This totally kills bigger installations on mysql.

I guess we either need a way to figure out why mysql copies the table sometimes when a column is added (I guess this is the case when the whole table doesn't fit in memory).

@MorrisJobke

This comment has been minimized.

Show comment
Hide comment
@MorrisJobke

MorrisJobke Mar 1, 2016

Member

@karlitschek @DeepDiver1975 You asked me about this. It seems that I was wrong here. Today I noticed that the complete activity table was copied while running the alter table statement to add two columns (owncloud/activity@0470887).

Member

MorrisJobke commented Mar 1, 2016

@karlitschek @DeepDiver1975 You asked me about this. It seems that I was wrong here. Today I noticed that the complete activity table was copied while running the alter table statement to add two columns (owncloud/activity@0470887).

@MorrisJobke

This comment has been minimized.

Show comment
Hide comment
@MorrisJobke

MorrisJobke Mar 1, 2016

Member

We should re-evaluate the add of the column to the file cache because this could add a serious problem.

Ref #21997

@karlitschek @DeepDiver1975 Sorry - I did a mistake by stating that this will not be a problem. 😢

Member

MorrisJobke commented Mar 1, 2016

We should re-evaluate the add of the column to the file cache because this could add a serious problem.

Ref #21997

@karlitschek @DeepDiver1975 Sorry - I did a mistake by stating that this will not be a problem. 😢

@MorrisJobke

This comment has been minimized.

Show comment
Hide comment
@MorrisJobke

MorrisJobke Mar 1, 2016

Member

@PVince81 @nickvergessen I remind that Frank said that you tested this and it worked fine. What exactly was the test scenario?

Member

MorrisJobke commented Mar 1, 2016

@PVince81 @nickvergessen I remind that Frank said that you tested this and it worked fine. What exactly was the test scenario?

@PVince81

This comment has been minimized.

Show comment
Hide comment
@PVince81

PVince81 Mar 1, 2016

Member

I think @karlitschek tested it himself and it was fast.

Member

PVince81 commented Mar 1, 2016

I think @karlitschek tested it himself and it was fast.

@DeepDiver1975

This comment has been minimized.

Show comment
Hide comment
@DeepDiver1975

DeepDiver1975 Mar 1, 2016

Member

adding sev1 - this needs to be sorted out

Member

DeepDiver1975 commented Mar 1, 2016

adding sev1 - this needs to be sorted out

@MorrisJobke

This comment has been minimized.

Show comment
Hide comment
@MorrisJobke

MorrisJobke Mar 1, 2016

Member

I updated my description above - it's a ratio of 1 to 4.

Member

MorrisJobke commented Mar 1, 2016

I updated my description above - it's a ratio of 1 to 4.

@PVince81

This comment has been minimized.

Show comment
Hide comment
@PVince81

PVince81 Mar 1, 2016

Member

To clarify: this report is NOT about simulated update.
It's about the ALTER TABLE that happens afterwards.

Member

PVince81 commented Mar 1, 2016

To clarify: this report is NOT about simulated update.
It's about the ALTER TABLE that happens afterwards.

@DeepDiver1975

This comment has been minimized.

Show comment
Hide comment
@DeepDiver1975

DeepDiver1975 Mar 1, 2016

Member

http://dev.mysql.com/doc/refman/5.7/en/alter-table.html - see 'Storage, Performance, and Concurrency Considerations'

Member

DeepDiver1975 commented Mar 1, 2016

http://dev.mysql.com/doc/refman/5.7/en/alter-table.html - see 'Storage, Performance, and Concurrency Considerations'

@MorrisJobke

This comment has been minimized.

Show comment
Hide comment
@MorrisJobke

MorrisJobke Mar 1, 2016

Member

I think @karlitschek tested it himself and it was fast.

The question is how big was the table and how much memory was available. This happened on an instance with 177M entries in the activity table.

Member

MorrisJobke commented Mar 1, 2016

I think @karlitschek tested it himself and it was fast.

The question is how big was the table and how much memory was available. This happened on an instance with 177M entries in the activity table.

@MorrisJobke

This comment has been minimized.

Show comment
Hide comment
@MorrisJobke

MorrisJobke Mar 1, 2016

Member

To clarify: this report is NOT about simulated update.
It's about the ALTER TABLE that happens afterwards.

Correct.

Member

MorrisJobke commented Mar 1, 2016

To clarify: this report is NOT about simulated update.
It's about the ALTER TABLE that happens afterwards.

Correct.

@DeepDiver1975

This comment has been minimized.

Show comment
Hide comment
@DeepDiver1975

DeepDiver1975 Mar 1, 2016

Member

Reading the docs the behavior is depending on the mysql version

Member

DeepDiver1975 commented Mar 1, 2016

Reading the docs the behavior is depending on the mysql version

@MorrisJobke

This comment has been minimized.

Show comment
Hide comment
@MorrisJobke

MorrisJobke Mar 1, 2016

Member

This was a mariadb 5.5.48 on RHEL 7.

Member

MorrisJobke commented Mar 1, 2016

This was a mariadb 5.5.48 on RHEL 7.

@DeepDiver1975

This comment has been minimized.

Show comment
Hide comment
@DeepDiver1975

DeepDiver1975 Mar 1, 2016

Member

looks like the behavior can be influenced by setting ALGORITHM=INPLACE in the command.
InnoDB is supporting this

Member

DeepDiver1975 commented Mar 1, 2016

looks like the behavior can be influenced by setting ALGORITHM=INPLACE in the command.
InnoDB is supporting this

@MorrisJobke

This comment has been minimized.

Show comment
Hide comment
@MorrisJobke

MorrisJobke Mar 1, 2016

Member

looks like the behavior can be influenced by setting ALGORITHM=INPLACE in the command.

@butonic Didn't you say that this does not work in innodb?

Member

MorrisJobke commented Mar 1, 2016

looks like the behavior can be influenced by setting ALGORITHM=INPLACE in the command.

@butonic Didn't you say that this does not work in innodb?

@DeepDiver1975

This comment has been minimized.

Show comment
Hide comment
@DeepDiver1975

DeepDiver1975 Mar 1, 2016

Member

http://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl.html

'The online DDL feature enhances many types of ALTER TABLE operations to avoid table copying, blocking of DML operations while DDL is in progress, or both. '

Member

DeepDiver1975 commented Mar 1, 2016

http://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl.html

'The online DDL feature enhances many types of ALTER TABLE operations to avoid table copying, blocking of DML operations while DDL is in progress, or both. '

@DeepDiver1975

This comment has been minimized.

Show comment
Hide comment
@DeepDiver1975

DeepDiver1975 Mar 1, 2016

Member

online ddl is inplace since 5.5

Member

DeepDiver1975 commented Mar 1, 2016

online ddl is inplace since 5.5

@karlitschek

This comment has been minimized.

Show comment
Hide comment
@karlitschek

karlitschek Mar 1, 2016

Member

Sorry for the misunderstanding. I see now that this is about the alter table command itself and not our code.

Member

karlitschek commented Mar 1, 2016

Sorry for the misunderstanding. I see now that this is about the alter table command itself and not our code.

@karlitschek

This comment has been minimized.

Show comment
Hide comment
@karlitschek

karlitschek Mar 1, 2016

Member

I indeed did a test on my local machine with some automatically generated data. obviously not a real production environment. And in this case this was surprisingly fast to add a column to an existing huge table. basically instant. I used a a new mariadb. The latest that comes with Ubuntu 15.10

Member

karlitschek commented Mar 1, 2016

I indeed did a test on my local machine with some automatically generated data. obviously not a real production environment. And in this case this was surprisingly fast to add a column to an existing huge table. basically instant. I used a a new mariadb. The latest that comes with Ubuntu 15.10

@karlitschek

This comment has been minimized.

Show comment
Hide comment
@karlitschek

karlitschek Mar 1, 2016

Member

I don't see an alternative to the current approach. It was always clear that we have long db migrations again once we touch the filecache table. This was expected. The only alternative would be to put the checksum into a new table and join them. This would mean fast migration and slower during operation. We would have two heavy load tables then instead of one plus the join overhead. -> Not an option.
Let's explore if online ddl can help in new mysql/mariadb versions. Otherwise we have to live with long running db migrations.
By the way. it was the plan of the new updater to make it possible to do the db alter tables asynchronously before the real update. unfortunately this wasn't done for 9.0

Member

karlitschek commented Mar 1, 2016

I don't see an alternative to the current approach. It was always clear that we have long db migrations again once we touch the filecache table. This was expected. The only alternative would be to put the checksum into a new table and join them. This would mean fast migration and slower during operation. We would have two heavy load tables then instead of one plus the join overhead. -> Not an option.
Let's explore if online ddl can help in new mysql/mariadb versions. Otherwise we have to live with long running db migrations.
By the way. it was the plan of the new updater to make it possible to do the db alter tables asynchronously before the real update. unfortunately this wasn't done for 9.0

@nickvergessen

This comment has been minimized.

Show comment
Hide comment
@nickvergessen

nickvergessen Mar 1, 2016

Contributor

What we could also do is to give the ALTER TABLE command to the customers before the update.
So they can modify the table in the night before the update, where usage is low.

Our updater then does not need to create the table anymore and therefor is faster.

Contributor

nickvergessen commented Mar 1, 2016

What we could also do is to give the ALTER TABLE command to the customers before the update.
So they can modify the table in the night before the update, where usage is low.

Our updater then does not need to create the table anymore and therefor is faster.

@karlitschek

This comment has been minimized.

Show comment
Hide comment
@karlitschek

karlitschek Mar 1, 2016

Member

@nickvergessen Yes. This is what I meant earlier. :-)

Member

karlitschek commented Mar 1, 2016

@nickvergessen Yes. This is what I meant earlier. :-)

@nickvergessen

This comment has been minimized.

Show comment
Hide comment
@nickvergessen

nickvergessen Mar 1, 2016

Contributor

@nickvergessen Yes. This is what I meant earlier. :-)

And what I meant is, that although the updater is not capable to do that, we can still achieve this manually, so the update is faster and we don't need to do big changes now anymore.

Contributor

nickvergessen commented Mar 1, 2016

@nickvergessen Yes. This is what I meant earlier. :-)

And what I meant is, that although the updater is not capable to do that, we can still achieve this manually, so the update is faster and we don't need to do big changes now anymore.

@DeepDiver1975

This comment has been minimized.

Show comment
Hide comment
@DeepDiver1975

DeepDiver1975 Mar 1, 2016

Member

looks like the behavior can be influenced by setting ALGORITHM=INPLACE in the command.

What about adding the algorithm statement to the sqls we are generating?
Worth a try?

Member

DeepDiver1975 commented Mar 1, 2016

looks like the behavior can be influenced by setting ALGORITHM=INPLACE in the command.

What about adding the algorithm statement to the sqls we are generating?
Worth a try?

@MorrisJobke

This comment has been minimized.

Show comment
Hide comment
@MorrisJobke

MorrisJobke Mar 1, 2016

Member

What about adding the algorithm statement to the sqls we are generating?
Worth a try?

I think so.

Member

MorrisJobke commented Mar 1, 2016

What about adding the algorithm statement to the sqls we are generating?
Worth a try?

I think so.

@butonic

This comment has been minimized.

Show comment
Hide comment
@butonic

butonic Mar 1, 2016

Member

@DeepDiver1975 No, ALGORITHM=INPLACE cannot be used when adding columns. It will produce an error. See the 5.7 documentation on DDL:

Concurrent DML but Table Copy Still Required

Some other ALTER TABLE operations allow concurrent DML but still require a table copy. However, the table copy for these operations is faster than it was in MySQL 5.5 and prior.

  • Adding, dropping, or reordering columns.

And from the mysql .7 ALTER TABLE documentation:

As of MySQL 5.7.4, ALTER TABLE upgrades MySQL 5.5 temporal columns to 5.6 format for ADD COLUMN, CHANGE COLUMN, MODIFY COLUMN, ADD INDEX, and FORCE operations. This conversion cannot be done using the INPLACE algorithm because the table must be rebuilt, so specifying ALGORITHM=INPLACE in these cases results in an error. Specify ALGORITHM=COPY if necessary.

Member

butonic commented Mar 1, 2016

@DeepDiver1975 No, ALGORITHM=INPLACE cannot be used when adding columns. It will produce an error. See the 5.7 documentation on DDL:

Concurrent DML but Table Copy Still Required

Some other ALTER TABLE operations allow concurrent DML but still require a table copy. However, the table copy for these operations is faster than it was in MySQL 5.5 and prior.

  • Adding, dropping, or reordering columns.

And from the mysql .7 ALTER TABLE documentation:

As of MySQL 5.7.4, ALTER TABLE upgrades MySQL 5.5 temporal columns to 5.6 format for ADD COLUMN, CHANGE COLUMN, MODIFY COLUMN, ADD INDEX, and FORCE operations. This conversion cannot be done using the INPLACE algorithm because the table must be rebuilt, so specifying ALGORITHM=INPLACE in these cases results in an error. Specify ALGORITHM=COPY if necessary.

@butonic

This comment has been minimized.

Show comment
Hide comment
@butonic

butonic Mar 1, 2016

Member

I really think the only thing we can do is plan migrating large installations in advance. Any Ideas welcome.

Member

butonic commented Mar 1, 2016

I really think the only thing we can do is plan migrating large installations in advance. Any Ideas welcome.

@karlitschek

This comment has been minimized.

Show comment
Hide comment
@karlitschek

karlitschek Mar 1, 2016

Member

@nickvergessen Sure. With some manual hacking like: somehow extract the alter tables commands and prevent that they are executed during upgrade.
What I meant is that we should do this nice as a step in the upgrade process.
But you are right. We COULD do this also manually today.

Member

karlitschek commented Mar 1, 2016

@nickvergessen Sure. With some manual hacking like: somehow extract the alter tables commands and prevent that they are executed during upgrade.
What I meant is that we should do this nice as a step in the upgrade process.
But you are right. We COULD do this also manually today.

@PVince81

This comment has been minimized.

Show comment
Hide comment
@PVince81

PVince81 Mar 1, 2016

Member

So, is there anything to do in the scope of 9.0 before the freeze ?

It seems that we're out of quick workarounds or do you guys want to keep looking ?
(apart from just creating the column manually in the DB before running the upgrade)

Member

PVince81 commented Mar 1, 2016

So, is there anything to do in the scope of 9.0 before the freeze ?

It seems that we're out of quick workarounds or do you guys want to keep looking ?
(apart from just creating the column manually in the DB before running the upgrade)

@butonic

This comment has been minimized.

Show comment
Hide comment
@butonic

butonic Mar 1, 2016

Member

For big installations subsequent user migrations might allow a better handling of this scenario.

IMO we should mention the long duration / space requirements in the release notes.

Member

butonic commented Mar 1, 2016

For big installations subsequent user migrations might allow a better handling of this scenario.

IMO we should mention the long duration / space requirements in the release notes.

@PVince81

This comment has been minimized.

Show comment
Hide comment
@PVince81

PVince81 Mar 1, 2016

Member

Tagging as release note, @carlaschroder

Need confirmation from you guys for adding this to the release notes for now with an upcoming fix later.

Member

PVince81 commented Mar 1, 2016

Tagging as release note, @carlaschroder

Need confirmation from you guys for adding this to the release notes for now with an upcoming fix later.

@cmonteroluque

This comment has been minimized.

Show comment
Hide comment
@cmonteroluque

cmonteroluque Mar 1, 2016

Contributor

yes, 9.0.1 as the updater goes forward...

Contributor

cmonteroluque commented Mar 1, 2016

yes, 9.0.1 as the updater goes forward...

@cmonteroluque cmonteroluque modified the milestones: 9.0.1-next-maintenance, 9.0-current Mar 1, 2016

@PVince81

This comment has been minimized.

Show comment
Hide comment
@PVince81

PVince81 Mar 9, 2016

Member

So if I understand well, we need to adjust the updater to give estimates ?
Assigned @VicDeo

Member

PVince81 commented Mar 9, 2016

So if I understand well, we need to adjust the updater to give estimates ?
Assigned @VicDeo

@VicDeo

This comment has been minimized.

Show comment
Hide comment
@VicDeo

VicDeo Mar 9, 2016

Member

er, I wouldn't touch that with a 10 foot pole because it might kill kittens...
But there IS a way to speedup ALTER TABLE for MySQL in particular.
Something like that

CREATE TABLE new_table LIKE old_table;
ALTER TABLE new_table ADD new_column _datatype_;
INSERT INTO new_table SELECT *, NULL FROM old_table;
DROP TABLE old_table;
RENAME TABLE new_table TO old_table;
Member

VicDeo commented Mar 9, 2016

er, I wouldn't touch that with a 10 foot pole because it might kill kittens...
But there IS a way to speedup ALTER TABLE for MySQL in particular.
Something like that

CREATE TABLE new_table LIKE old_table;
ALTER TABLE new_table ADD new_column _datatype_;
INSERT INTO new_table SELECT *, NULL FROM old_table;
DROP TABLE old_table;
RENAME TABLE new_table TO old_table;
@MorrisJobke

This comment has been minimized.

Show comment
Hide comment
@MorrisJobke

MorrisJobke Mar 10, 2016

Member

But there IS a way to speedup ALTER TABLE for MySQL in particular.

Why should this be faster?

Member

MorrisJobke commented Mar 10, 2016

But there IS a way to speedup ALTER TABLE for MySQL in particular.

Why should this be faster?

@VicDeo

This comment has been minimized.

Show comment
Hide comment
@VicDeo

VicDeo Mar 14, 2016

Member

@MorrisJobke It's my own recipe but something that I found online. This should be measured to say for sure. The main reason is a lack of a temporary table I guess.

Member

VicDeo commented Mar 14, 2016

@MorrisJobke It's my own recipe but something that I found online. This should be measured to say for sure. The main reason is a lack of a temporary table I guess.

@VicDeo

This comment has been minimized.

Show comment
Hide comment
@VicDeo

VicDeo Mar 14, 2016

Member

A planned workaround is asking user to run ALTER TABLE query on his own in case database platform is MySQL/Postrge and number of entries in filecache table exceeds a certain threshold.

Member

VicDeo commented Mar 14, 2016

A planned workaround is asking user to run ALTER TABLE query on his own in case database platform is MySQL/Postrge and number of entries in filecache table exceeds a certain threshold.

@MorrisJobke

This comment has been minimized.

Show comment
Hide comment
@MorrisJobke

MorrisJobke Mar 15, 2016

Member

A planned workaround is asking user to run ALTER TABLE query on his own in case database platform is MySQL/Postrge and number of entries in filecache table exceeds a certain threshold.

How does this speed up the process? What is this threshold?

Member

MorrisJobke commented Mar 15, 2016

A planned workaround is asking user to run ALTER TABLE query on his own in case database platform is MySQL/Postrge and number of entries in filecache table exceeds a certain threshold.

How does this speed up the process? What is this threshold?

@VicDeo

This comment has been minimized.

Show comment
Hide comment
@VicDeo

VicDeo Mar 15, 2016

Member

@MorrisJobke

How does this speed up the process?

This is a workaround and not the solution.

What is this threshold?

I think it's something like ~300k (and more) filecache entries. What's your opinion?

Member

VicDeo commented Mar 15, 2016

@MorrisJobke

How does this speed up the process?

This is a workaround and not the solution.

What is this threshold?

I think it's something like ~300k (and more) filecache entries. What's your opinion?

@VicDeo

This comment has been minimized.

Show comment
Hide comment
@VicDeo

VicDeo Mar 15, 2016

Member

some benchmarks that I've done on solidgear docker instance by bumping version and adding checksum filed to filecache (and droping the column on the next iteration)
MySQL 5.1 (chosen intentionally because 5.5 is faster)

num of filecache entries time, seconds
1 000 3-6s
10 000 ~ 8s
100 000 170-180
300 000 ~ 1300
Member

VicDeo commented Mar 15, 2016

some benchmarks that I've done on solidgear docker instance by bumping version and adding checksum filed to filecache (and droping the column on the next iteration)
MySQL 5.1 (chosen intentionally because 5.5 is faster)

num of filecache entries time, seconds
1 000 3-6s
10 000 ~ 8s
100 000 170-180
300 000 ~ 1300
@butonic

This comment has been minimized.

Show comment
Hide comment
@butonic

butonic Mar 18, 2016

Member

There is official documentation on how to improve bulk insert performance: http://dev.mysql.com/doc/refman/5.5/en/optimizing-innodb-bulk-data-loading.html

Basically disabling index updates and uniqueness checks. Be aware that enabling them after the insert operation causes a rebuild of the index. It will still be faster than updating the index on every insert, however.

Member

butonic commented Mar 18, 2016

There is official documentation on how to improve bulk insert performance: http://dev.mysql.com/doc/refman/5.5/en/optimizing-innodb-bulk-data-loading.html

Basically disabling index updates and uniqueness checks. Be aware that enabling them after the insert operation causes a rebuild of the index. It will still be faster than updating the index on every insert, however.

@VicDeo

This comment has been minimized.

Show comment
Hide comment
@VicDeo

VicDeo Mar 18, 2016

Member

@butonic it's not possible to disable indexes completely for innodb storage and altering is not the same with bulk insert.

The only profit I see is DB copying speedup: #23395

Here are four test results on the same container (Schema change was nothing but adding/droping checksum column to filecache table with 300 000 entries in it):
Time of occ upgrade completion (including schema check) in seconds

operation 8.2.3 8.2.3 + #23395
add column 1417 1131
drop column 1360 1085

this doesn't speed up the migration of original DB, but a test migration performance tweak

Member

VicDeo commented Mar 18, 2016

@butonic it's not possible to disable indexes completely for innodb storage and altering is not the same with bulk insert.

The only profit I see is DB copying speedup: #23395

Here are four test results on the same container (Schema change was nothing but adding/droping checksum column to filecache table with 300 000 entries in it):
Time of occ upgrade completion (including schema check) in seconds

operation 8.2.3 8.2.3 + #23395
add column 1417 1131
drop column 1360 1085

this doesn't speed up the migration of original DB, but a test migration performance tweak

@guruz

This comment has been minimized.

Show comment
Hide comment
@guruz

guruz Mar 18, 2016

Contributor

Why not have a new table for the checksum?
With a nice index from fileId->(checksumType,checkSum)
That way you also save space for directories or files that don't have a checksum

Contributor

guruz commented Mar 18, 2016

Why not have a new table for the checksum?
With a nice index from fileId->(checksumType,checkSum)
That way you also save space for directories or files that don't have a checksum

@nickvergessen

This comment has been minimized.

Show comment
Hide comment
@nickvergessen

nickvergessen Mar 18, 2016

Contributor

But we would need to left join the column all the time, which is even worse for huge installations

Contributor

nickvergessen commented Mar 18, 2016

But we would need to left join the column all the time, which is even worse for huge installations

@MorrisJobke

This comment has been minimized.

Show comment
Hide comment
@MorrisJobke

MorrisJobke Mar 21, 2016

Member

Why not have a new table for the checksum?

Because it's too late.

Member

MorrisJobke commented Mar 21, 2016

Why not have a new table for the checksum?

Because it's too late.

@VicDeo

This comment has been minimized.

Show comment
Hide comment
@VicDeo

VicDeo Mar 21, 2016

Member

@PVince81 @DeepDiver1975 So, what finally needs to be done?

Add the following to update notification in Web UI for stable8.2 && MySQL && oc_filecache ahs more than 200k entries?:

According to your filecache table size upgrade might take too long. You can execute the following query on your database to speedup the upgrade process: ALTER TABLE oc_filecache ADD COLUMN checksum varchar(255) DEFAULT NULL AFTER permissions; `

Member

VicDeo commented Mar 21, 2016

@PVince81 @DeepDiver1975 So, what finally needs to be done?

Add the following to update notification in Web UI for stable8.2 && MySQL && oc_filecache ahs more than 200k entries?:

According to your filecache table size upgrade might take too long. You can execute the following query on your database to speedup the upgrade process: ALTER TABLE oc_filecache ADD COLUMN checksum varchar(255) DEFAULT NULL AFTER permissions; `

@PVince81

This comment has been minimized.

Show comment
Hide comment
@PVince81

PVince81 Mar 22, 2016

Member

Sounds good to me. @karlitschek @DeepDiver1975 @butonic @MorrisJobke what do you think ?

Member

PVince81 commented Mar 22, 2016

Sounds good to me. @karlitschek @DeepDiver1975 @butonic @MorrisJobke what do you think ?

@karlitschek

This comment has been minimized.

Show comment
Hide comment
@karlitschek

karlitschek Mar 22, 2016

Member

we discussed this and we don't want to have a new table for the. we optimize for production speed instead of upgrade speed

Member

karlitschek commented Mar 22, 2016

we discussed this and we don't want to have a new table for the. we optimize for production speed instead of upgrade speed

@karlitschek

This comment has been minimized.

Show comment
Hide comment
@karlitschek

karlitschek Mar 22, 2016

Member

I think we should add a warning to the web ui and the cli if you have more then 200k. Please check the original updater 2.0 issue for the right place in the flow where we have the hint about the length of the upgrade.
We should use this text instead:

You have an ownCloud installation with over 200.000 files so the upgrade might take a while. The recommendation is to use the command-line instead of the web interface for big ownCloud servers. Hint: You can speed up the upgrade by executing this SQL command manually: ALTER TABLE oc_filecache ADD COLUMN checksum varchar(255) DEFAULT NULL AFTER permissions; `

Not. Please show the hint only if using mysql.
Please show the CLI hint only in the web ui.

Does this make sense?

Member

karlitschek commented Mar 22, 2016

I think we should add a warning to the web ui and the cli if you have more then 200k. Please check the original updater 2.0 issue for the right place in the flow where we have the hint about the length of the upgrade.
We should use this text instead:

You have an ownCloud installation with over 200.000 files so the upgrade might take a while. The recommendation is to use the command-line instead of the web interface for big ownCloud servers. Hint: You can speed up the upgrade by executing this SQL command manually: ALTER TABLE oc_filecache ADD COLUMN checksum varchar(255) DEFAULT NULL AFTER permissions; `

Not. Please show the hint only if using mysql.
Please show the CLI hint only in the web ui.

Does this make sense?

@VicDeo

This comment has been minimized.

Show comment
Hide comment
@VicDeo

VicDeo Mar 23, 2016

Member

@karlitschek shouldn't this notice be added to 8.2 in order to be displayed before any action takes place?

Member

VicDeo commented Mar 23, 2016

@karlitschek shouldn't this notice be added to 8.2 in order to be displayed before any action takes place?

@karlitschek

This comment has been minimized.

Show comment
Hide comment
@karlitschek

karlitschek Mar 23, 2016

Member

I think 9.0.x is fine

Member

karlitschek commented Mar 23, 2016

I think 9.0.x is fine

@nickvergessen

This comment has been minimized.

Show comment
Hide comment
@nickvergessen

nickvergessen Mar 23, 2016

Contributor

But the update to 9.0.x is the one causing the troubles?! 😕

Contributor

nickvergessen commented Mar 23, 2016

But the update to 9.0.x is the one causing the troubles?! 😕

@MorrisJobke

This comment has been minimized.

Show comment
Hide comment
@MorrisJobke

MorrisJobke Mar 23, 2016

Member

But the update to 9.0.x is the one causing the troubles?!

And then already the new 9.0.x code is available before the upgrade step has run. So this should be fine ;)

Member

MorrisJobke commented Mar 23, 2016

But the update to 9.0.x is the one causing the troubles?!

And then already the new 9.0.x code is available before the upgrade step has run. So this should be fine ;)

@VicDeo VicDeo referenced this issue Mar 24, 2016

Merged

[Stable9] release notes #23572

2 of 2 tasks complete

@cmonteroluque cmonteroluque modified the milestones: 9.0.2-current-maintenance, 9.0.1 Apr 11, 2016

@PVince81

This comment has been minimized.

Show comment
Hide comment
@PVince81

PVince81 Apr 19, 2016

Member

So if I understand well the warning has been added 9.0.1, closing hence.

Please reopen if you think there is something left to do.

Member

PVince81 commented Apr 19, 2016

So if I understand well the warning has been added 9.0.1, closing hence.

Please reopen if you think there is something left to do.

@PVince81 PVince81 closed this Apr 19, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment