While upgrading Umbraco from 7.15.2 to Umbraco 8.1.4, we are facing issues with long migration time and timeouts.
Our situation is
cmsContentVersion table has ~940K rows
cmsPropertyData table has ~10 million rows.
When we were following the recommended steps for migration to Umbraco8, we were getting timeout errors. We then updated the timeout settings and after more than 12 hours its still running. This is resulting in hug DB size increase too.
When we looked into the migration code, we found out where its taking time. Please take a look at below screenshot:
Looks like its loading all the >940K records from "cmsContentVersion" in memory and updating records into "cmsPropertyData". We think because it runs in a transaction, it is also resulting in big increse in DB size.
Is there any better way to accomplish this step? (may be doing this in stored procedure?)
There was not much difference after running the script in the given link to clean the audit trail and version history.
It has only come down by few thousands.
I'm working on some changes to improve the speed of upgrades. If you'd be interested in testing them, there's a modified version of Umbraco.Core.dll from 8.1.4 here.
If it works for you, I'd appreciate a copy of the log file from the upgrade so that I can see where there's still room for improvement.
I have tried running the modified Umbraco.Core.dll for migration.
The log file is updated only for the first 5 minutes and last log statement is 'ALTER TABLE [cmsPropertyData] ADD [versionId2] INTEGER NULL'.
It keeps running and had to stop it after more than 12 hrs.
Is it by any chance going into the foreach loop?
Is it a configuration setting to say that it is not a compact server?
How odd. The IsSqlCe test is based on the connection string's providerName, so that shouldn't be an issue. Can you check what it's actually running with something like
SELECT sqltext.TEXT, req.session_id, req.status, req.start_time, req.command, req.cpu_time, req.total_elapsed_time
FROM sys.dm_exec_requests req
CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS sqltext
The query it should be running for SQL Server is still fairly unpleasant and slow, but it shouldn't be taking hours.
UPDATE cmsPropertyData SET versionId2=cmsContentVersion.id FROM cmsContentVersion INNER JOIN cmsPropertyData ON cmsContentVersion.versionId = cmsPropertyData.versionId
Reassuring that it's not using the SQL CE version, though strange that it's taking so long. My test database has 8.5 million rows in cmsPropertyData and only takes a couple of minutes to run that query.
You could do the change of the versionId column manually before starting the migration, and the migration should then quietly skip that bit. That might let you experiment with indexes to speed it up.
This SQL should be what the migration runs, though you might need to drop an index or two first:
ALTER TABLE cmsPropertyData ADD [versionId2] [int] NULL
UPDATE cmsPropertyData SET versionId2=cmsContentVersion.id FROM cmsContentVersion INNER JOIN cmsPropertyData ON cmsContentVersion.versionId = cmsPropertyData.versionId
ALTER TABLE cmsPropertyData DROP COLUMN [versionId]
sp_rename 'cmsPropertyData.versionId2', 'versionId', 'COLUMN'
It finishes the given query in SSMS very fast, like in 3 mins. But this keeps running for hours from the application.
As a workaround, i'm running the alter, update and rename query from SSMS before migration and then start Umbraco migration, now it is not getting stuck at the update query.
I will let you know once the whole migration process is done. Thanks.
{"@t":"2019-10-03T14:21:55.0051163Z","@mt":"Database configuration failed","@l":"Error","@x":"System.NotSupportedException: Surrogate pairs are not supported.\r\n at Umbraco.Core.Strings.DefaultShortStringHelper.CleanCodeString(String text, CleanStringType caseType, Char separator, String culture, Config config)\r\n at Umbraco.Core.Strings.DefaultShortStringHelper.CleanString(String text, CleanStringType stringType, String culture, Nullable`1 separator)\r\n at Umbraco.Core.Strings.DefaultShortStringHelper.CleanStringForUrlSegment(String text, String culture)\r\n at Umbraco.Core.StringExtensions.ToUrlSegment(String text, String culture)\r\n at Umbraco.Core.Strings.DefaultUrlSegmentProvider.GetUrlSegment(IContentBase content, String culture)\r\n at Umbraco.Core.Strings.ContentBaseExtensions.<>c__DisplayClass0_0.<GetUrlSegment>b__0(IUrlSegmentProvider p)\r\n at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()\r\n at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable`1 source, Func`2 predicate)\r\n at Umbraco.Core.Strings.ContentBaseExtensions.GetUrlSegment(IContentBase content, IEnumerable`1 urlSegmentProviders, String culture)\r\n at Umbraco.Web.PublishedCache.NuCache.PublishedSnapshotService.GetDto(IContentBase content, Boolean published) in d:\\a\\1\\s\\src\\Umbraco.Web\\PublishedCache\\NuCache\\PublishedSnapshotService.cs:line 1356\r\n at Umbraco.Web.PublishedCache.NuCache.PublishedSnapshotService.<RebuildMemberDbCacheLocked>b__82_1(IMember m) in d:\\a\\1\\s\\src\\Umbraco.Web\\PublishedCache\\NuCache\\PublishedSnapshotService.cs:line 1581\r\n at System.Linq.Enumerable.WhereSelectArrayIterator`2.MoveNext()\r\n at System.Linq.Buffer`1..ctor(IEnumerable`1 source)\r\n at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)\r\n at Umbraco.Web.PublishedCache.NuCache.PublishedSnapshotService.RebuildMemberDbCacheLocked(IScope scope, Int32 groupSize, IEnumerable`1 contentTypeIds) in d:\\a\\1\\s\\src\\Umbraco.Web\\PublishedCache\\NuCache\\PublishedSnapshotService.cs:line 1542\r\n at Umbraco.Web.PublishedCache.NuCache.PublishedSnapshotService.Rebuild() in d:\\a\\1\\s\\src\\Umbraco.Web\\PublishedCache\\NuCache\\PublishedSnapshotService.cs:line 1393\r\n at Umbraco.Web.Migrations.PostMigrations.PublishedSnapshotRebuilder.Rebuild() in d:\\a\\1\\s\\src\\Umbraco.Web\\Migrations\\PostMigrations\\PublishedSnapshotRebuilder.cs:line 27\r\n at Umbraco.Core.Migrations.PostMigrations.RebuildPublishedSnapshot.Migrate()\r\n at Umbraco.Core.Migrations.MigrationPlan.Execute(IScope scope, String fromState, IMigrationBuilder migrationBuilder, ILogger logger)\r\n at Umbraco.Core.Migrations.Upgrade.Upgrader.Execute(IScopeProvider scopeProvider, IMigrationBuilder migrationBuilder, IKeyValueService keyValueService, ILogger logger)\r\n at Umbraco.Core.Migrations.Install.DatabaseBuilder.UpgradeSchemaAndData(MigrationPlan plan)","SourceContext":"Umbraco.Core.Migrations.Install.DatabaseBuilder","ProcessId":14792,"ProcessName":"iisexpress","ThreadId":7,"AppDomainId":2,"AppDomainAppId":"LMW3SVC2ROOT","MachineName":"SLBLR-LT-209","Log4NetLevel":"ERROR","HttpRequestNumber":7,"HttpRequestId":"c6965a3d-c7ee-4be3-83ae-84250fb34d59"}
Could you please share your source code repository or the branch name, so that we could debug and find out the error ?
It looks like you're back into unmodified code with that error, though. The cache is trying to generate clean versions of member names in the same way that document names get cleaned to generate URLs (I don't think we ever use a URL for a member anywhere, but the cache doesn't know that). I'd guess that the most likely reason for surrogate pairs in a member name is someone including emoji.
Thanks Steve for the hint about emojis. I also got the "Surrogate pairs are not supported" error. I removed the emojis from content, and then I successfully upgraded from Umbraco 7 to 8.
Thanks Steve. We were able to locate the emoji in UmbracoNode table and finished with the migration. Will your performance changes be pushed to the main Umbraco repository and be part of any upcoming release ?
I have same problem using 8.5.3 .. the forloop query takes hours and then timeouts.
To the point tho "The query it should be running for SQL Server is still fairly unpleasant and slow, but it shouldn't be taking hours." - Personally from experience running loops where you send the query to the server from code each time, I would expect it to take hours, it's not a great way of doing it!
I think this has been fixed in one of the latest versions - I've actually manage to upgrade mine in the last few weeks finally. Why would you upgrade to 8.4.2. .. go for the latest version and should be good.
We write essays, coursework, lab reports, research papers, term papers, thesis papers, book and film reviews, https://jetessayswriter.com/ annotated bibliographies, etc. Just pick which type of work you want us to help you write, and we’ll match you to an expert.
Umbraco 8 upgrade taking long time
Hello,
While upgrading Umbraco from 7.15.2 to Umbraco 8.1.4, we are facing issues with long migration time and timeouts.
Our situation is
When we were following the recommended steps for migration to Umbraco8, we were getting timeout errors. We then updated the timeout settings and after more than 12 hours its still running. This is resulting in hug DB size increase too.
When we looked into the migration code, we found out where its taking time. Please take a look at below screenshot:
Looks like its loading all the >940K records from "cmsContentVersion" in memory and updating records into "cmsPropertyData". We think because it runs in a transaction, it is also resulting in big increse in DB size.
Is there any better way to accomplish this step? (may be doing this in stored procedure?)
Thoughts?
Thanks
Pavan
Hi Pavan,
You can delete Version History and this should clear lot of your unused records.
This link will help you to reduce the records. https://our.umbraco.com/forum/core/general/74365-remove-audit-trail-and-version-history
Hope this helps to solve your issue.
Cheers,
Shaishav
Hi Shaishav,
There was not much difference after running the script in the given link to clean the audit trail and version history. It has only come down by few thousands.
I'm working on some changes to improve the speed of upgrades. If you'd be interested in testing them, there's a modified version of Umbraco.Core.dll from 8.1.4 here.
If it works for you, I'd appreciate a copy of the log file from the upgrade so that I can see where there's still room for improvement.
Hi Steve Megson,
I have tried running the modified Umbraco.Core.dll for migration. The log file is updated only for the first 5 minutes and last log statement is 'ALTER TABLE [cmsPropertyData] ADD [versionId2] INTEGER NULL'. It keeps running and had to stop it after more than 12 hrs.
Is it by any chance going into the foreach loop?
Is it a configuration setting to say that it is not a compact server?
How odd. The
IsSqlCe
test is based on the connection string'sproviderName
, so that shouldn't be an issue. Can you check what it's actually running with something likeThe query it should be running for SQL Server is still fairly unpleasant and slow, but it shouldn't be taking hours.
It shows that the above query is running
Reassuring that it's not using the SQL CE version, though strange that it's taking so long. My test database has 8.5 million rows in cmsPropertyData and only takes a couple of minutes to run that query.
You could do the change of the versionId column manually before starting the migration, and the migration should then quietly skip that bit. That might let you experiment with indexes to speed it up.
This SQL should be what the migration runs, though you might need to drop an index or two first:
It finishes the given query in SSMS very fast, like in 3 mins. But this keeps running for hours from the application. As a workaround, i'm running the alter, update and rename query from SSMS before migration and then start Umbraco migration, now it is not getting stuck at the update query. I will let you know once the whole migration process is done. Thanks.
Hi Steve Megson,
We are now getting an error in PostMigrations.
Could you please share your source code repository or the branch name, so that we could debug and find out the error ?
Here's my repository: https://github.com/stevemegson/Umbraco-CMS/tree/v8/migration-performance
It looks like you're back into unmodified code with that error, though. The cache is trying to generate clean versions of member names in the same way that document names get cleaned to generate URLs (I don't think we ever use a URL for a member anywhere, but the cache doesn't know that). I'd guess that the most likely reason for surrogate pairs in a member name is someone including emoji.
Thanks Steve for the hint about emojis. I also got the "Surrogate pairs are not supported" error. I removed the emojis from content, and then I successfully upgraded from Umbraco 7 to 8.
Thanks Steve. We were able to locate the emoji in UmbracoNode table and finished with the migration. Will your performance changes be pushed to the main Umbraco repository and be part of any upcoming release ?
Hi Steve, Were you able to upgrade your Umbraco installation to v8?
I was stuck at the version migrations aswell and I ran your SQL Script to edit the version and it looks that worked but now it get stuck at
Any ideas?
// Herman
Hi Cimplex, I am struck on the same step. Did you find any solution? Thanks
I have same problem using 8.5.3 .. the forloop query takes hours and then timeouts. To the point tho "The query it should be running for SQL Server is still fairly unpleasant and slow, but it shouldn't be taking hours." - Personally from experience running loops where you send the query to the server from code each time, I would expect it to take hours, it's not a great way of doing it!
Hi Steve,
We have quite a big site that is being migrated from v7 to v8. We are migrating to v8.4.2
Our process is taking very long time and stuck at the above SQL statement. Please can you suggest how to fix it?
Cheers,
Shaishav
I think this has been fixed in one of the latest versions - I've actually manage to upgrade mine in the last few weeks finally. Why would you upgrade to 8.4.2. .. go for the latest version and should be good.
We write essays, coursework, lab reports, research papers, term papers, thesis papers, book and film reviews, https://jetessayswriter.com/ annotated bibliographies, etc. Just pick which type of work you want us to help you write, and we’ll match you to an expert.
is working on a reply...
This forum is in read-only mode while we transition to the new forum.
You can continue this topic on the new forum by tapping the "Continue discussion" link below.