Skip to main content
S
scurtis-21-Visitor
1-Visitor
March 28, 2011
Question

Slow Check In in 9.1 M060

  • March 28, 2011
  • 3 replies
  • 1063 views

Hello Everyone,


We went live with Windchill 9.1 M060 last week after a migration from Pro/INTRALINK 3.4. We are experiencing extremely slow check in times for some drawings and assemblies. For example, one particular drawing and its assembly (two objects checked in) will take 45 minutes for the check in to complete. The upload of the objects is fast (~30 seconds) but the check in portion of the process seems to hang. This is only occurring for certain large assemblies and drawings. I don't see anything in any of the log files to indicate a problem. There is no spike in resource or memory usage on the servers when there is a hanging check in.


Has anyone else experienced a similar problem? Any thoughts on why the check in portion of this process is taking so long for certain objects.


Thanks,


Steve

3 replies

G
gangadhara.pooj1-Visitor
1-Visitor
March 29, 2011

Hi,

It requires a performance tuning after the migration, Please look into the PTC TAN 142710.
When I faced the performance problem after migration from Pro/I 3.4 to PDMLink 9.1 M070 PTC advised to update the following property values

1. wt.properties

com.ptc.core.collectionsrv.engine.isSmartToolbarEnabled=false
com.ptc.core.collectionsrv.engine.isIntralinkTracingEnabled=true


2. Update the following in codebase/com/ptc/core/collectionsrv/CollectionFeatures.xml

<feature id="ignore_optional_dummy_dependencies">
<description>By default OPTIONAL_DEPENDENTS collection includes dummy dependencies. This feature should be added if collection component should ignore optional dummy dependencies</description>
<collectioncomponent id=""/">
</feature>

With the following:

<feature id="ignore_optional_dummy_dependencies">
<description>By default OPTIONAL_DEPENDENTS collection includes dummy dependencies. This feature should be added if collection component should ignore optional dummy dependencies</description>
<collectioncomponent id="Download"/">
<collectioncomponent id="Checkout"/">
</feature>


Best Regards,
Gangadhara.P

S
scurtis-21-VisitorAuthor
1-Visitor
April 5, 2011

First off I would like to thank everyone that took the time to respond to my question. There were many good ideas on what to look for and additional client and server tuning tips. I received a number of replies that stated they had or currently have the same problem as we are seeing.


Our problem was resolved by allocating more memory to Oracle. We bumped the memory allocation for Oracle from 2 GB to 12 GB and the check in time for our test drawing went from 45 minutes down to 20 seconds.


Thanks again to all for the help.

S
scurtis-21-VisitorAuthor
1-Visitor
April 6, 2011

I had a request to post the Oracle changes that were made back to the exploder so please see below.


Our environment - Oracle 11G R2


Please note: An Oracle DBA at my customer made these changes. Posted below are the changes that were made. It is not clear if one change or a combination of the changes below provided the improved performance. I would recommend having an Oracle DBA make these changes to your environment. One reply to this thread provided contact info to a highly recommended Oracle DBA that I can pass along if there is interest.


For our environment, we made the following changes:


wind.__db_cache_size=1828716544 --> 11509170176


wind.__java_pool_size=16777216 --> 33554432


wind.__large_pool_size=16777216 --> 33554432


wind.__pga_aggregate_target=2147483648 --> 6442450944


wind.__sga_target=2147483648 --> 12314476544


wind.__shared_pool_size=268435456 --> 671088640


*.processes=500 --> 1000


*.sessions=225 --> 800


*.sga_max_size=2147483648 --> 12288800000


*.sga_target=2147483648 --> 12288800000



These parameters were added:


*.db_files=400


*.db_writer_processes=8


*.session_cached_cursors=100


*.session_max_open_files=20


*.sort_area_size=8192000



I hope this helps.

Terms & ConditionsAccessibility statement