frozen sessions
Can somebody tell me what a session in a "cond wait PC_I hash" condition mean?
I've never seen a session in this state before.
I have multiple sessions that are all stuck at the same place.
The statements are all called from stored procedures. The last one executing
(spil_send_mail)
only inserts into a table, but that's where all of the sessions appear to be
stuck.
This is on Redhat Linux 5
IBM Informix Dynamic Server Version 11.50.FC6W3 -- On-Line -- Up 48 days
19:28:01 -- 31086888 Kbytes
session effective #RSAM total used dynamic
id user user tty pid hostname threads memory memory explain
7049980 umsuser - - -1 itil-tfx 1 13119488 12737536 off
tid name rstcb flags curstk status
7165786 sqlexec 561499548 Y--P--- 15568 cond wait PC_I hash -
Memory pools count 2
name class addr totalsize freesize #allocfrag #freefrag
7049980 V 5a4366040 13115392 381144 15976 659
7049980*O0 V 59caa8040 4096 808 1 1
name free used name free used
overhead 0 6576 mtmisc 0 9840
resident 0 192 scb 0 432
opentable 0 512680 filetable 0 67744
ru 0 600 misc 0 80
blobio 0 17384 log 0 16536
temprec 0 104608 blob 0 2048
keys 0 19320 ralloc 0 10658624
gentcb 0 1752 ostcb 0 2920
sort 0 104 sqscb 0 561864
sql 0 72 rdahead 0 1136
hashfiletab 0 552 osenv 0 2792
buft_buffer 0 126248 sqtcb 0 74752
fragman 0 517576 sapi 0 320
udr 0 30264
sqscb info
scb sqscb optofc pdqpriority optcompind directives
59d58a028 598c43028 0 0 0 1
Sess SQL Current Iso Lock SQL ISAM F.E.
Id Stmt type Database Lvl Mode ERR ERR Vers Explain
7049980 webstore DR Wait 0 0 9.28 Off
Stored procedure stack :
context proc-counter opcode name
------------------------------------------------------------------
0x00000005e1a30858 0x59b869a08+0x0010 EXPR webstore:spil_send_email_prod
0x00000005a586a458 0x5890b8ec8+0x0010 EXPR webstore:spil_clc_enroll_member
Current SQL statement in procedure webstore:spil_send_email_prod
proc-counter 0x0x59b869a08 opcode EXPR
(<procedure> spil_send_mail, m_email_id, m_to_address, m_from_address,
m_value_pairs, p_user_define1, p_user_define2, p_user_define3, p_user_define4)
Last parsed SQL statement :
SELECT FIRST 1 CURRENT FROM systables
Original Post:
Can somebody tell me what a session in a "cond wait PC_I hash" condition mean?
I've never seen a session in this state before.
I have multiple sessions that are all stuck at the same place.
The statements are all called from stored procedures. The last one executing
(spil_send_mail)
only inserts into a table, but that's where all of the sessions appear to be
stuck.
This is on Redhat Linux 5
IBM Informix Dynamic Server Version 11.50.FC6W3 -- On-Line -- Up 48 days
19:28:01 -- 31086888 Kbytes
session effective #RSAM total used dynamic
id user user tty pid hostname threads memory memory explain
7049980 umsuser - - -1 itil-tfx 1 13119488 12737536 off
tid name rstcb flags curstk status
7165786 sqlexec 561499548 Y--P--- 15568 cond wait PC_I hash -
Memory pools count 2
name class addr totalsize freesize #allocfrag #freefrag
7049980 V 5a4366040 13115392 381144 15976 659
7049980*O0 V 59caa8040 4096 808 1 1
name free used name free used
overhead 0 6576 mtmisc 0 9840
resident 0 192 scb 0 432
opentable 0 512680 filetable 0 67744
ru 0 600 misc 0 80
blobio 0 17384 log 0 16536
temprec 0 104608 blob 0 2048
keys 0 19320 ralloc 0 10658624
gentcb 0 1752 ostcb 0 2920
sort 0 104 sqscb 0 561864
sql 0 72 rdahead 0 1136
hashfiletab 0 552 osenv 0 2792
buft_buffer 0 126248 sqtcb 0 74752
fragman 0 517576 sapi 0 320
udr 0 30264
sqscb info
scb sqscb optofc pdqpriority optcompind directives
59d58a028 598c43028 0 0 0 1
Sess SQL Current Iso Lock SQL ISAM F.E.
Id Stmt type Database Lvl Mode ERR ERR Vers Explain
7049980 webstore DR Wait 0 0 9.28 Off
Stored procedure stack :
context proc-counter opcode name
------------------------------------------------------------------
0x00000005e1a30858 0x59b869a08+0x0010 EXPR webstore:spil_send_email_prod
0x00000005a586a458 0x5890b8ec8+0x0010 EXPR webstore:spil_clc_enroll_member
Current SQL statement in procedure webstore:spil_send_email_prod
proc-counter 0x0x59b869a08 opcode EXPR
(<procedure> spil_send_mail, m_email_id, m_to_address, m_from_address,
m_value_pairs, p_user_define1, p_user_define2, p_user_define3, p_user_define4)
Last parsed SQL statement :
SELECT FIRST 1 CURRENT FROM systables
Response:
The PC_I Hash condition is an internal concurrency control mechanism to allow
only 1 thread to be writing to one of the caches, I'd suspect this is the
global stored procedure cache. If there are threads waiting on this condition,
then that would imply that there is 1 thread that would be modifying the
cache, and when that thread is done, it would be responsible for waking the
threads waiting on that condition. If threads are not getting woken up from
that condition there could be a problem that you'd want to get Tech support
involved in.
Jacques Renaut
IBM Informix Advanced Support
APD Team
Thanks Jacques. This is the first time we've seen something like this, and
it was only affecting sessions that used this procedure. The rest of the
sessions (again procedure driven) were working without a problem. I ended
up restarting the engine to correct the problem.
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
JACQUES RENAUT
Sent: Thursday, June 10, 2010 7:44 AM
To: ids@iiug.org
Subject: Re: frozen sessions [20364]
Original Post:
Can somebody tell me what a session in a "cond wait PC_I hash" condition
mean?
I've never seen a session in this state before.
I have multiple sessions that are all stuck at the same place.
The statements are all called from stored procedures. The last one executing
(spil_send_mail)
only inserts into a table, but that's where all of the sessions appear to be
stuck.
This is on Redhat Linux 5
IBM Informix Dynamic Server Version 11.50.FC6W3 -- On-Line -- Up 48 days
19:28:01 -- 31086888 Kbytes
session effective #RSAM total used dynamic id user user tty pid hostname
threads memory memory explain 7049980 umsuser - - -1 itil-tfx 1 13119488
12737536 off
tid name rstcb flags curstk status
7165786 sqlexec 561499548 Y--P--- 15568 cond wait PC_I hash -
Memory pools count 2
name class addr totalsize freesize #allocfrag #freefrag 7049980 V 5a4366040
13115392 381144 15976 659 7049980*O0 V 59caa8040 4096 808 1 1
name free used name free used
overhead 0 6576 mtmisc 0 9840
resident 0 192 scb 0 432
opentable 0 512680 filetable 0 67744
ru 0 600 misc 0 80
blobio 0 17384 log 0 16536
temprec 0 104608 blob 0 2048
keys 0 19320 ralloc 0 10658624
gentcb 0 1752 ostcb 0 2920
sort 0 104 sqscb 0 561864
sql 0 72 rdahead 0 1136
hashfiletab 0 552 osenv 0 2792
buft_buffer 0 126248 sqtcb 0 74752
fragman 0 517576 sapi 0 320
udr 0 30264
sqscb info
scb sqscb optofc pdqpriority optcompind directives
59d58a028 598c43028 0 0 0 1
Sess SQL Current Iso Lock SQL ISAM F.E.
Id Stmt type Database Lvl Mode ERR ERR Vers Explain 7049980 webstore DR Wait
0 0 9.28 Off
Stored procedure stack :
context proc-counter opcode name
------------------------------------------------------------------
0x00000005e1a30858 0x59b869a08+0x0010 EXPR webstore:spil_send_email_prod
0x00000005a586a458 0x5890b8ec8+0x0010 EXPR webstore:spil_clc_enroll_member
Current SQL statement in procedure webstore:spil_send_email_prod
proc-counter 0x0x59b869a08 opcode EXPR
(<procedure> spil_send_mail, m_email_id, m_to_address, m_from_address,
m_value_pairs, p_user_define1, p_user_define2, p_user_define3,
p_user_define4)
Last parsed SQL statement :
SELECT FIRST 1 CURRENT FROM systables
Response:
The PC_I Hash condition is an internal concurrency control mechanism to
allow only 1 thread to be writing to one of the caches, I'd suspect this is
the global stored procedure cache. If there are threads waiting on this
condition, then that would imply that there is 1 thread that would be
modifying the cache, and when that thread is done, it would be responsible
for waking the threads waiting on that condition. If threads are not getting
woken up from that condition there could be a problem that you'd want to get
Tech support involved in.
Jacques Renaut
IBM Informix Advanced Support
APD Team
****************************************************************************
***
Forum Note: Use "Reply" to post a response in the discussion forum.