It takes too long to connect to PDM in CREO

[CHASEONHO]

Hi,

There is an issue with PDM performance.

It takes 5 ~ 40 minutes from CREO to PDM connection depending on the individual.

(Generally, it takes a long time to be working with a large assembly.)

The cause of the issue is presumably due to differences in client workspace size, DRM environment, and PC spec.

In order to improve performance, we have done the following:

1. Configure PDM Optimization with WCA

2. Remove workspace and clear cache after work

We are reviewing the following items to improve performance.

1. Configure additional vault

Can you please share a solution for a similar issue that you have solved?

Or Please check with us for further considerations to further improve performance.

Thanks.

Warm Regards,

SeonHo Cha

[BenLoosli]

Not enough information to offer anything specific.

What is your internet connection speed, 100MB, 1GB, or something else?

Where is your server located in relation to your workstations? Same building, Local campus, on the cloud?

How much memory do your workstations have? 16GB is about the minimum for medium assemblies, 32GB for large ones.

Is your vault local?

Do you limit the number of files in a vault folder and have them automatically rollover to a new folder/

Are you putting items in the DB as BLOBs? (Big performance hit if you do!)

[CHASEONHO]

We on PDMLINK 11 030 CPS 13

            CREO 3.0 M150

            SQL2012

Servers and clients exist on the same network.

Server specifications
DB and PDMLINK are installed together.
Windows 2012 R2
128 GB RAM

Client specification
Windows 7/10 64bit
32-64 GB RAM

I don't know if it goes straight into BLOBS.
However, the storage is configured with the following settings.
wt.fv.forceContentToVault = true
wt.fv.useVaultsForAllContent-false

P.S. Setting dm_network_threads to 6 makes some clients run faster.

Thanks.

[BenLoosli]

What are your settings for these? 

wt.fv.useFvFileThreshold

wt.fv.fvFileThreshold

I think the system default for the second one is 50,000, but doesn't hurt to explicitly set it.

The first one should be set to true to force the vaults to rollover to a new vault when it hits the threshold limit (+/-10%).

[CHASEONHO]

We did not set the items below.
wt.fv.useFvFileThreshold

wt.fv.fvFileThreshold

This is because the default value of 50000 is considered sufficient.
Does it matter if I don't specify the above values?

Do I need to perform a revaulting schedule after specifying the above values?

[mdebower]

We just had very similar symptoms and opened a technical support case with PTC.   The solution it seems was related to the MS SQL database.  My limited understanding is that it had something to do with query plans and StringValue statistics...

(I am no DBA by any means...)

- marc

[STEVEG]

@mdebower 

Would you happen to know if there is an article from PTC on the fix?

[mdebower]

@STEVEG   no article that I know of.

From the Tech Support Engineer:

"Root cause was the StringValue statistics were updated with a sample rate less than 1%. By default SQL Server reduces the sampling rate as the number of rows in the table are increased. This can be a problem for very large tables. It’s also likely the StringValue data is skewed and a small sample size won’t reflect this in the statistics histogram.

To prevent this from happening in the future you would need to make sure that the appropriate sampling rate is used for statistics on StringValue indexes. It would make sense to disable auto statistics on StringValue indexes with the NORECOMPUTE option. Then create a SQL Server job to update statistics at regular intervals with an appropriate sampling rate. I see a lot of SQL Server experts recommend using the statistics maintenance scripts developed by Ola Holengren: https://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html "

[STEVEG]

What versions of Creo and PDMLink are you running?  We are Creo 4.0 and PDMLink 11.0 M030 CPS12.

We have some people with similar issues as well.

Most of the time Creo can freeze for a period of time when changing attributes through the embedded browser or even when just saving to a workspace.

PTC has us getting a bunch of log files using a new system_monitor.bat file included with a certain build of Creo 4 or higher.  It's included in the M100 but I don't know what build it first showed up in.

<install_dir>\Creo4\Creo 4.0\M100\Common Files\x86e_win64\obj\system_monitor.bat

There is an article on their website about how to set it up and what to do.

[CHASEONHO]

I am using CREO 3.0 M150 with PDMLINK 11.0 M030 CPS 13.
DB is using SQL 2012.

Thanks.

[Marco_Tosin]

https://www.ptc.com/en/support/article?n=CS134173

https://www.ptc.com/en/support/article?n=CS150989