TMG Performance since last windows update

[LeMans844 0]

Hi all,

Just recently TMG performance has bombed, most noticeably opening exhibits but is actually quite slow at redrawing any of the gui.  No changes have been made, all I can link this with is last Windows (10) update.  Have gone through normal file maintenance.  Tested on a very small project & the problem is the same as on my main large project.

Anybody else seen this? - if anybody else is still using TMG............

 

Dave

[Jim Byram 0]

I've had no performance issues with TMG in years. I'm currently running Win10 1809 with last Tuesday's cumulative update (17763.503).

[LeMans844 0]

Hi Jim,

 

Thanks for response.

 

Using

OS Name    Microsoft Windows 10 Pro
Version    10.0.17763 Build 17763
Processor    Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz, 4001 Mhz, 4 Core(s), 8 Logical Processor(s)
Installed Physical Memory (RAM)    32.0 GB
Total Physical Memory    31.9 GB
Available Physical Memory    25.5 GB
Total Virtual Memory    36.7 GB
Available Virtual Memory    28.8 GB
Page File Space    4.75 GB

Name    NVIDIA GeForce GTX 1660
Adapter RAM    (1,048,576) bytes
Driver Version    26.21.14.3064
Resolution    3440 x 1440 x 59 hertz
Bits/Pixel    32

Has been fine on this PC since project moved to it some years ago

Just in the last few days its been really slow when opening the Media page.  And having noticed that you then start to realise everything else is also a bit slow.

Main project has just under 10K people & the external exhibit directory is some 11Gb containing 13,711 files in 481 sub directories.

Have tried tiny projects and they suffer the same issue, but they are pointing at the same exhibit directory which may or may not be relevant.

Dave

 

 

[Diane Hosler 0]

I've been using mine quite a bit the last few weeks with no problems, but I do use exhibits.

 

[LeMans844 0]

Hi Jim, Diane,

Oddly seems to be better today.  

Carried out routine maintenance (again) which included this time a backup of the project. I rarely do an internal TMG back up of the project as its is backed up on the fly to cloud, on PC shutdown to two external devices and once a week to a back up PC (which in turn is backed up to external device prior to this) so effectively I have a current backup, daily back ups, weekly backup and a two week old back up. I may be a little paranoid about data loss.

However there is some problem with the TMG Backup when you include the links to external files - OLE Exception error c0000005 or c00000fd which cause the backup to fail. This does not impact normal bau operation of TMG. This problem is also present with the project daily backups, I haven't checked older.
 

Dave

[John Cardinal 0]

Dave,

I recommend that you NOT include external exhibits in your TMG backups. You should have a separate backup regimen for those digital assets, perhaps integrated with backups for other images that are not exhibits. Including exhibits in a TMG backup increases the size of the backup SQZ file and increases the amount of time that TMG takes to write the backup file. Meanwhile, the exhibits don't change very often. Lastly, if you have a lot of exhibits, the image data---which doesn't compress much--can cause the SQZ file to exceed the maximum size of a ZIP file. (SQZ files are ZIP files in disguise.)

TMG always performs reasonably well for me. The only operations that are slow enough to annoy me are (A) opening the Master Place List, which is glacial, (B) importing GEDCOM files (which I do rarely as part of testing), and (C) exporting GEDCOM files (which I also do only rarely).

The only other performance issue I have seen is when there was a "ghost" instance of TMG running that was using a lot of CPU. That was affecting all the other programs running on my PC, but had a particularly nasty impact on TMG, which was so sluggish it was almost unusable. I do not know what caused it. I only remember it happening once. I killed the ghost TMG process after I noticed it, and that solved the problem. Users who don't have the skills to check what processes are running and manipulate them can solve the problem by rebooting.

John

[LeMans844 0]

Hi John yes - I don't really use internal TMG backups at all, it was just that this seemed to be identifying an issue that may (or may not) be related to an attempt to import into Family Historian to have a look at that.  I have read over the last few days a several pieces of advice which concurs with you.  I do have separate back up regimes. (ISP Cloud solution & SmartSync Pro for local processes.)

In step 3 of the backup process, under project items > Project data files you see "external exhibits", hovering over that it tells you it has found x links to  external exhibits and specifies a database project_I_.dbf.  I had presumed that this was backing up the links not the image itself.  But as I do not actively use the process I haven't really looked at it in any detail.  However if it is backing up the image then I agree this is totally pointless as they are external to the project and are backed up  as part of my data resiliency program.

But having found this OLE error am now a bit obsessed with identifying the object in question.  I did look at inserting OLE objects some time ago but can't remember why or where.

I don't think there is anything that would identify the object in your handy utility and I recreated a second site site (local, I don't have a published version) and that worked fine I also enabled thumbnails but the db they are stored in went over size limitation and broke.  Replaced it with backup copy and  reduced the thumbnail size to just 50.  Again this ran OK so in both cases each and every exhibit would have been touched.  I was hoping one or both would identify the problem object.

The performance issue opening the exhibits window seems better now. I had used performance manager to look at running process, and as this had been going over several days possibly ever since the last W10 update I was concerned something more fundamental was at work.  Nvidia graphics driver updated recently as well.  However all seems well now.   I can look at Family Historian using another project, I just have this OLE error nagging at me.

Dave

 

 

 

[Jim Byram 0]

The exhibit table (_I.dbf) is always backed up when a project is backed up. The popup was just telling you how many exhibit files would be added to the backup when the external exhibits option is selected. The count is based on how many links were found in the exhibit table.

C0000005 errors are difficult to diagnose; however, in this case, I believe that the error is coming from an issue with one of the exhibit files.

[LeMans844 0]

Yes, I had misinterpreted the message/functionality of the check box. John got me thinking on the rationale of not backing up images with TMG internal backup - "can cause the SQZ file to exceed the maximum size of a ZIP file."  Using 7-zip I zipped up a copy of the images directory and the compressed file is 10.0 GB (10,756,108,301 bytes to be accurate ) which is way bigger than a zip file can manage and I guess foxpro db are limited to 2Gb  So the error is more a file limitation than an error as such.  & as far as being related to failure to import into Family Historian a complete red herring.  

 

The uncompressed directory is 11.2 GB (12,026,769,408 bytes) so indeed the compression doesn't achieve very much at all.

[Michael Hannah 0]

On 5/20/2019 at 5:30 AM, LeMans844 said:

I rarely do an internal TMG back up of the project as its is backed up on the fly to cloud...

Dave, I am concerned about your comment about backing up TMG files "on the fly".  If you have some program backing up TMG files while TMG is running this will some day be a problem.  Such a backup scenario is the major cause of corruption of TMG projects.  However, if the backup does not occur while TMG is running but you wait until you exit TMG and then invoke the program to backup TMG files to the cloud, then that should be okay.

[LeMans844 0]

it doesn't attempt to copy the pjc until TMG closed.  What files are you particularly concerned about?

 

[Michael Hannah 0]

A TMG project consists of more than two dozen files, of which the .pjc file is only one and has very little actual data in it.  No program other than TMG should be touching any of these project files while that project is open in a running TMG program.  Corruption of any one of these files can potentially corrupt the usability of the entire project.  If the backup program is configured to not attempt to copy any of the project files until TMG is closed, then as I said before, that should be okay.

[chornung 0]

On 5/20/2019 at 10:32 AM, John Cardinal said:

I recommend that you NOT include external exhibits in your TMG backups. You should have a separate backup regimen for those digital assets, perhaps integrated with backups for other images that are not exhibits. Including exhibits in a TMG backup increases the size of the backup SQZ file and increases the amount of time that TMG takes to write the backup file.

Have been getting "Insufficient Stack Space" program errors - EXCEPT when de-selecting Project data files > External Exhibits, even to 2TB drive with 1.5TB free, so have accepted I need to back up external exhibit folder separately, per John's post. No problem.

Out of curiosity (and in attempt to avoid separate backups), I tried changing Compression level (last Backup Wizard screen) from Normal to Fast, Superfast and None, but still got same error each time. I know the resultant file would be huge, but can someone explain why "None" wouldn't avoid the apparently too-large SQZ file? Just trying to understand...

Or, does my "Insufficient stack space" error message indicate a different problem, since I still get it with the less/no compression options?

Thanks!         ~Carol Hornung [Desktop WIN10 Pro, Intel i7-6700, 32GB RAM, Vipre, no cloud backups running; TMG 9.05, File Mtce tools run]

[Michael Hannah 0]

Carol,

As others note, if you include external exhibits in your backup, all these exhibit files will be loaded into the one .sqz file.  The free space on your disk file is not the issue.  There is a max limit in the Operating System for the size of a single file, i.e. the .sqz file.  That limit is much less than your 1.5TB free space.  The options on compression affect how much smaller a single file loaded into the .sqz file can be made so that the total size of .sqz hopefully can be smaller than the sum of the sizes of all the files stored in that one file.  "None" says to do no compression, so the full sizes of all files are loaded into .sqz and thus would result in the largest .sqz file of all the options.  The problem appears to be that no matter what type of compression you choose, including all the external exhibit files within that one .sqz file makes it too large for the Operating System to handle.

As you have noted, the solution is to backup your external exhibits separately and not include them in the .sqz file.

Hope this makes things clearer,

[chornung 0]

Makes sense (now!). Thanks!!       ~Carol