Community Tip - Have a PTC product question you need answered fast? Chances are someone has asked it before. Learn about the community search. X
When first starting to work on a performance problem there is usually a request made to send in some combination of wt & db properties files, an Oracle report and Method Server logs. The support engineer will review the data looking for problems or potential problems. What does that review entail? Some variation of the below is often what occurs first what happens happens as the next depends on what is found.
Of the hundreds of properties between the wt and db properties files, there are only a small number which really matter for performance. Using the Windchill Configuration Assistant (installed by default in R10 and later systems see chapter 1 in the article documentation links) is good way to get almost all of the server side properties set correctly. This tool will make machine specific recomendations for the settings of key performance properties. The Windchill Client Inspector does someting similar for the client side.
2. Surprisingly the db.properties file contains many properties which are key for performance.
3. The next db.properties to check to ensure they are at their defaults are:
4. The last settings to review in the db.properties file are the query limits. Query limits are a double edged sword. On one hand they prevent unbounded sets of results from the database from overwhelming the Method Server memory, but on the other hand some (usually a very small number of operations) may need a large result to complete but won't because they run into the query limit, and that’s the rub. You need to set the limit low enough to prevent out of memory problems, but high enough things that need to complete are able too. To further complicate things, there are three query limits, two are for searches and the other is for all other queries. See the link(authenticated) for more informaiton on these limits. The wt.pom.queryLimit is by far the most important parameter to set this property not being set is the number one cause of method server outages it is also the only property the Windchill configuration Assistant doesn’t set which I think it should.
Next is a review of Oracle (or SQLServer).
See the article link(authenticated) for a more in depth discussion about tuning Oracle using the Oracle Gather Info Script.
In a review of the gather info report, we are trying to get a sense of what the biggest problems are in the system; is there enough SGA what are the longest system wait events and what is the slowest SQL? A significant percentage of Windchill performance problems can be improved or resolved by making changes to Oracle. What changes are needed will depend on the specifics of the system but usually the top 3-5 long running or resource intensive SQL statements are identified and indexes recommended, increasing the SGA is also a commonly recomended change. A regular review of the database performance by a DBA is something many systems could be benefit from.
Lastly is a look at the Method Server log files.
Have you had to look through 50 or 100 MethodServer log files, which are cumulatively hundreds of megabytes in size? It can be time consuming…. The questions to answer are, which log files contain the problems, when did those problems occur and if possible what is the root cause that led to the problem? I usually start by using a text editor to search the directory holding the log files, looking for ‘wt.method.MethodContextMonitor.stats.summary’ and then look for lines which exhibit something unusual, see the article(authenticated) for details on what to look for. What happens next depends on what is found, but opening a Technical Support case will be the best course of action.
It's been my observation that performance recomendations come in two varieties. The first is the best practice type. This usually involves some a series of recomendations which are well intentioned but havn't been evaluated for the specifics of the system or circumstances of the system involved. The second way, and the way performance TSE's work, is to to gather and evaluate a series of data, diagnose and understand the problem and then take corrective actions. This approach can take longer, and require more data but it works everytime and importantly minimizes the risk to the system involved.
Would you please post a pointer to the download site for the Windchill Configuration Assistant? I cannot find it. Does it require an additional license?
No additional license is required. It used to be that the Windchill Configuration Assistant was available for download but it in R10 it is installed along with Windchill in the <Windchill Home>\utilities\wca directory for me this path is: D:\ptc\Windchill_10.0\Windchill\utilities\wca. The KCS article https://www.ptc.com/appserver/cs/view/solution.jsp?n=CS40876 contains links to a documentation file which in Chapter 1 the WCA is documented.
I've also updated the post above to reflect that fact that the WCA no longer needs to be downloaded, my appologies for the confusion.
No apologies necessary.
We're still on 9.1, and you've given enough info for me to find it already installed on our server. And the pointer to the User Guide also is a great help.
Thanks!
Could you please explain what wt.pom.rowPrefetchCount and wt.query.template.streamingQueryLimit do?
Many thanks.
Both properties are documented in Windchill/codebase/properties.html
wt.pom.rowPrefetchCount: SQL results are read in batches. The default is to read 20 rows at a time. If a SQL returned 1,000 rows, it would take 50 fetches (20 rows per fetch) to read in the results. Increasing this property would reduce the number of round trips to fetch the query results, but has a significant impact on the MethodServer's memory usage. It's strongly recommended to leave this property set to the default.
wt.query.template.streamingQueryLimit: Limits the number of rows processed during ReportTemplate query execution for formats that support streaming. Default is -1 or unlimited. Article CS142827 suggests setting this limit to prevent the MethodServer from running out of memory in the event a QML report returns too much data. This property is for a very specific use case and doesn't come up very often. I've only had to recommend this property twice.
Thanks Jeremy. Now I know where to search desc for all properties