Re: DBMS_PIPE Waits

Dan,

this probably IS the case - if your sender is filling up the 8k buffer too quickly and pipe reader doesn't pull it out immediately, next put will wait until there's free room in the buffer. Since your timeout is not zero, sender gets blocked until there's free room in the buffer. And blocked means blocked - it will spin on pipe put until it either posts to the pipe or timeout expires (very unlikely with default of 1000 days) and won't do anything else. High pipe put waits indicate this and you actually don't need any more tests to confirm the issue. Minding that the session will sleep for 5 seconds before retrying the pipe put, it is very undesirable that SEND_MESSAGE() gets blocked due to lack of pipe buffer space. You may try to amend the situation by increasing pipe buffer size or by using zero timeout and handling non-zero return codes from SEND_MESSAGE() appropriately (resending with higher maxpipesize, for example). Shortening messages could help, too. Making sure the pipe reader can cope with the pipe write rate is the ultimate solution though - the pipe reader should be able to read data off the pipe faster than, or at least as fast as it is written, otherwise writers will eventually fill it up regardless the pipe buffer size and will start to wait on pipe put again.

Corrections and additions welcome.

-- 
Vladimir Zakharychev (bob@dpsp-yes.com)                http://www.dpsp-yes.com
Dynamic PSP(tm) - the first true RAD toolkit for Oracle-based internet applications.
All opinions are mine and do not necessarily go in line with those of my employer.


"dbuckingham" <member8912_at_dbforums.com> wrote in message news:2483945.1044421735_at_dbforums.com...


> 

> Having an issue where the performance of our system appears to be

> affected from the number of waits that are being experienced from the

> DBMS_PIPE.

> 

> We are finding that when the system performance is being affected, the

> "pipe put" waits were very high.

> 

> Our procedure is making a direct call the "sys.dbms_pipe" and passing in

> a pipe name and using the default Timeout and Maxpipesize. I believe

> this to be 1000days and 8k.

> 

> The performance is being affected when we execute a procedure that

> processes a lot of data very quickly. As a result, I am curious as to

> whether we might be filling up the pipe to quickly.

> 

> Has anyone got any ideas as to what tests I might be able to perform in

> order to determine if the actual is filling up to quickly?

> 

> Thanks.

> 

> Dan.

> 

> --

> Posted via http://dbforums.com