Skip to main content
C
CHASEONHO18-Opal
18-Opal
October 7, 2019
Question

It takes too long to connect to PDM in CREO

  • October 7, 2019
  • 3 replies
  • 3775 views

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

 

3 replies

B
23-Emerald III
BenLoosli23-Emerald III
23-Emerald III
October 7, 2019

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!)

C
CHASEONHO18-OpalAuthor
18-Opal
October 8, 2019

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.

B
23-Emerald III
BenLoosli23-Emerald III
23-Emerald III
October 8, 2019

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%).

M
mdebower18-Opal
18-Opal
October 7, 2019

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

 

 

 

S
21-Topaz I
STEVEG21-Topaz I
21-Topaz I
October 7, 2019

@mdebower 

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

M
mdebower18-Opal
18-Opal
October 8, 2019

@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 "

 

    S
    21-Topaz I
    STEVEG21-Topaz I
    21-Topaz I
    October 7, 2019

    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.

    C
    CHASEONHO18-OpalAuthor
    18-Opal
    October 8, 2019

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

     

    Thanks.

    Terms & ConditionsCookie settingsAccessibility statement