Skip Ribbon Commands
Skip to main content
Navigate Up
Sign In

Quick Launch

Average Rating:

(6 Ratings)
facebook Twitter
Print Bookmark Alert me when this article is updated


T​roubleshooting WRT_8165 related issues
The WRT_8165 message is of symptomatic nature. In general, it is indicative of slowness in the pipeline the reason for which could be multiple/multifold.
Typically, the writer thread issues the timeout based commit because it would not receive any data from the upstream transformations for 60 seconds and thus it commits the records it has. As a first step towards troubleshooting, take the stack trace and try to understand if there are upstream widgets that can be the possible points of slowness. The other aspect to understand with this behavior is that the writer thread may accidentally cause DTM deadlock and so in order to prevent the same, it waits for a minute and then issues a timeout based commit.
Refer to articles 119214 and 146647 to get more understanding.

As the source from where the slowness could possibly be, can be various scenarios, here are some generic reasons that can help navigate to the trouble spot:

Disc IO is under-performing
  • On AIX, queue_depth parameter is set to a low value. Refer to KB article 149490.
  • On AIX, vm.nr_hugepages is configured 27008 in /etc/sysctl.conf. Refer to KB article 120758. 
  • Sometime the IO on the disc, which could be needed for caching the records from a lookup or aggregator, could be slow. Refer to KB 138428.

Database is under-performing

  • Database read either from the reader or a lookup could be under-performing. Read from the relational source is under-performing. Refer to KB article 146167.
  • Under-performing write on to the relational target. The underlying reason could be disc IO performance in AIX. Refer to KB article 120758.

Non-optimized query 

  • Sometimes an SQL override query may not be efficient, causing a full table scan on the server which results in SQL override query taking too much time to process. On a particular instance, after breaking down the query into multiple statements, the where clause with "LIKE" was seen to be doing a full table scan causing the query to slow down. Refer to KB 151233.
  • Parsing in token parser could be slow because of excess/unwanted data is pushed into it. One possible way could be to optimize the query such that it returns relevant records to the token parser. Refer to KB article 123476.
  • Sometimes getting superfluous data into the pipeline can result the sorters to process more and so more dependency on the disc IO. A Strategic decision to have the query pushed to the database can bypass the disc IO that the sorter would require and thereby preventing slowness in the pipeline. Refer to KB article 154489.

Reading from PowerExchange Listener session

  • Because of a timeout on the connection between PowerCenter pmdtm and the PowerExchange Listener. Refer to KB article 140571.

Known Issue CR 229693

More Information



Applies To
Product: PowerCenter
Problem Type: Performance
User Type: Administrator
Project Phase: Configure
Product Version: PowerCenter
Operating System:
Other Software:

Last Modified Date: 11/25/2019 5:38 PM ID: 158086
People who viewed this also viewed


Did this KB document help you?

What can we do to improve this information (2000 or fewer characters)