Skip to main content

UV / uniQuery SELECT on phantom are 'pending'

  • April 29, 2021
  • 2 replies
  • 1 view
Manu Fernandes
Forum|alt.badge.img+2
hello uv's gurus, 

I'll share a strange behavior we encounter on Uv Windows.

We run some phantoms as scheduler which performs actions on request.
The phantom check what to do, execute it then wait for the next instruction.  It is restarted each 8 hours.
---
Sometimes, we encounter troubles at uniQUERY SELECT level, the select is 'pending', seems 'blocked' ...
After 50 seconds of execution, we check the status via PORT.STATUS PID xxxx LAYER.STACK and we read the phantom is 'selecting'  - actual level of execution is 'Query' from uniBASIC EXECUTE CAPTURING 
Here is a sample stack 
- MI.SCHEDULER is the base program which CALL MI.SCHEDULER.CTR
MI.SCHEDULER.CTR
-- receive the job to do
-- create a level EXECUTE MI.SUB which perform the task 
In this sample, we read SB.EXECUTE perform a EXECUTE query SELECT ARTICLES ... 


PORT.STATUS PID 21448 LAYER.STACK
Pid.... User name. Who. Port name..... Last command processed
0ř0ř0
21448řsvc_uv_coldstartř -2řSELECT ARTICLES USING DICT D.FPRART WITH ART.CLE # "" AND WITH ART.ESP = "BET" AND WITH ART.VAR = "4G" AND WITH ART.CAT = "1"

Layer type....... Program name.................... Address...
Query
Verb
Command Language
Execute
BASIC run machine SB.EXECUTE 0x000004DA
BASIC run machine SB.SELECT.IDS 0x00001702
BASIC run machine SB.PROCESS 0x00001484
BASIC run machine PR.P.TRE.NOD.IMPORT 0x00001598
BASIC run machine SB.PROCESS 0x00000A84
BASIC run machine PR.WS.TRE.NOD.IMPORT 0x0000046C
BASIC run machine MI.SUB 0x000000E4
Verb
Command Language
Execute
BASIC run machine MI.SCHEDULER.CTR 0x00002618
BASIC run machine MI.SCHEDULER 0x00000856
Verb
Command Language​
the list-readu every report a active group lock on ARTICLES by the phantom port itself but no other 'lock' situation.... 
Active Group Locks: Record Group Group Group
Device.... Inode..... Netnode Userno Lmode G-Address. Locks ...RD ...SH ...EX
3095298892 4836996281 0 -2 25 RD 3D5800 0 1 0 0
​

ARTICLES is loaded with 3000 of records, correctly sized/hashed/distributed, have no index, all dictionaries are D-type direct attributes (no i-type)

Our solution is to kill to restart the phantom.

Executed from a interactive session, the SELECT is realy quick and is never 'pending'  
This is a sample, we encounter it on different files, different queries ... it seems linked to the 'phantom' context. 
We already identify that phantoms's SELECT goes slower and slower after hours of service, thats why we restart it after 8 hours.

Any idea is welcome :-) !

------------------------------
Manu Fernandes
------------------------------

    2 replies

    A
    • Anonymous
    • 0 replies
    • April 29, 2021
    hello uv's gurus, 

    I'll share a strange behavior we encounter on Uv Windows.

    We run some phantoms as scheduler which performs actions on request.
    The phantom check what to do, execute it then wait for the next instruction.  It is restarted each 8 hours.
    ---
    Sometimes, we encounter troubles at uniQUERY SELECT level, the select is 'pending', seems 'blocked' ...
    After 50 seconds of execution, we check the status via PORT.STATUS PID xxxx LAYER.STACK and we read the phantom is 'selecting'  - actual level of execution is 'Query' from uniBASIC EXECUTE CAPTURING 
    Here is a sample stack 
    - MI.SCHEDULER is the base program which CALL MI.SCHEDULER.CTR
    MI.SCHEDULER.CTR
    -- receive the job to do
    -- create a level EXECUTE MI.SUB which perform the task 
    In this sample, we read SB.EXECUTE perform a EXECUTE query SELECT ARTICLES ... 


    PORT.STATUS PID 21448 LAYER.STACK
Pid.... User name. Who. Port name..... Last command processed
0ř0ř0
21448řsvc_uv_coldstartř -2řSELECT ARTICLES USING DICT D.FPRART WITH ART.CLE # "" AND WITH ART.ESP = "BET" AND WITH ART.VAR = "4G" AND WITH ART.CAT = "1"

Layer type....... Program name.................... Address...
Query
Verb
Command Language
Execute
BASIC run machine SB.EXECUTE 0x000004DA
BASIC run machine SB.SELECT.IDS 0x00001702
BASIC run machine SB.PROCESS 0x00001484
BASIC run machine PR.P.TRE.NOD.IMPORT 0x00001598
BASIC run machine SB.PROCESS 0x00000A84
BASIC run machine PR.WS.TRE.NOD.IMPORT 0x0000046C
BASIC run machine MI.SUB 0x000000E4
Verb
Command Language
Execute
BASIC run machine MI.SCHEDULER.CTR 0x00002618
BASIC run machine MI.SCHEDULER 0x00000856
Verb
Command Language​
    the list-readu every report a active group lock on ARTICLES by the phantom port itself but no other 'lock' situation.... 
    Active Group Locks: Record Group Group Group
Device.... Inode..... Netnode Userno Lmode G-Address. Locks ...RD ...SH ...EX
3095298892 4836996281 0 -2 25 RD 3D5800 0 1 0 0
​

    ARTICLES is loaded with 3000 of records, correctly sized/hashed/distributed, have no index, all dictionaries are D-type direct attributes (no i-type)

    Our solution is to kill to restart the phantom.

    Executed from a interactive session, the SELECT is realy quick and is never 'pending'  
    This is a sample, we encounter it on different files, different queries ... it seems linked to the 'phantom' context. 
    We already identify that phantoms's SELECT goes slower and slower after hours of service, thats why we restart it after 8 hours.

    Any idea is welcome :-) !

    ------------------------------
    Manu Fernandes
    ------------------------------
    Manu,

    It is worth trying to check what the process is actually doing using a trace command such as truss (AIX), strace (Linux and Solaris) or tusc (HP-UX). The syntax is always the same though the command will vary depending  upon the Operating System. You can monitor directly on your terminal, though it is usually easier to direct the output to files and check the file contents - which van get very large very quickly - e.g.

    # truss -f -p PID> 1>truss_PID.out 2>truss_PID.err

    Break the truss when you are done with it, or it will stop automatically when the monitored PID terminates. Noting again that the output can get very large indeed if left to run.

    Check in the output files - you may get a strong pointer as to what it is doing or waiting for. It is also worth checking the NOTIFY settings, I recommend using NOTIFY IGNORE. Otherwise I recommend gathering a 'uvdiag' along with the truss output and opening a support ticket through normal channels.

    ------------------------------
    John Jenkins
    Principal Technical Support Engineer
    Rocket Software Limited
    U.K.
    ------------------------------
    David Green
    • David Green
    • Inspiring
    • 48 replies
    • April 29, 2021
    hello uv's gurus, 

    I'll share a strange behavior we encounter on Uv Windows.

    We run some phantoms as scheduler which performs actions on request.
    The phantom check what to do, execute it then wait for the next instruction.  It is restarted each 8 hours.
    ---
    Sometimes, we encounter troubles at uniQUERY SELECT level, the select is 'pending', seems 'blocked' ...
    After 50 seconds of execution, we check the status via PORT.STATUS PID xxxx LAYER.STACK and we read the phantom is 'selecting'  - actual level of execution is 'Query' from uniBASIC EXECUTE CAPTURING 
    Here is a sample stack 
    - MI.SCHEDULER is the base program which CALL MI.SCHEDULER.CTR
    MI.SCHEDULER.CTR
    -- receive the job to do
    -- create a level EXECUTE MI.SUB which perform the task 
    In this sample, we read SB.EXECUTE perform a EXECUTE query SELECT ARTICLES ... 


    PORT.STATUS PID 21448 LAYER.STACK
Pid.... User name. Who. Port name..... Last command processed
0ř0ř0
21448řsvc_uv_coldstartř -2řSELECT ARTICLES USING DICT D.FPRART WITH ART.CLE # "" AND WITH ART.ESP = "BET" AND WITH ART.VAR = "4G" AND WITH ART.CAT = "1"

Layer type....... Program name.................... Address...
Query
Verb
Command Language
Execute
BASIC run machine SB.EXECUTE 0x000004DA
BASIC run machine SB.SELECT.IDS 0x00001702
BASIC run machine SB.PROCESS 0x00001484
BASIC run machine PR.P.TRE.NOD.IMPORT 0x00001598
BASIC run machine SB.PROCESS 0x00000A84
BASIC run machine PR.WS.TRE.NOD.IMPORT 0x0000046C
BASIC run machine MI.SUB 0x000000E4
Verb
Command Language
Execute
BASIC run machine MI.SCHEDULER.CTR 0x00002618
BASIC run machine MI.SCHEDULER 0x00000856
Verb
Command Language​
    the list-readu every report a active group lock on ARTICLES by the phantom port itself but no other 'lock' situation.... 
    Active Group Locks: Record Group Group Group
Device.... Inode..... Netnode Userno Lmode G-Address. Locks ...RD ...SH ...EX
3095298892 4836996281 0 -2 25 RD 3D5800 0 1 0 0
​

    ARTICLES is loaded with 3000 of records, correctly sized/hashed/distributed, have no index, all dictionaries are D-type direct attributes (no i-type)

    Our solution is to kill to restart the phantom.

    Executed from a interactive session, the SELECT is realy quick and is never 'pending'  
    This is a sample, we encounter it on different files, different queries ... it seems linked to the 'phantom' context. 
    We already identify that phantoms's SELECT goes slower and slower after hours of service, thats why we restart it after 8 hours.

    Any idea is welcome :-) !

    ------------------------------
    Manu Fernandes
    ------------------------------

    This behavior sounds like a COMMON variable that is always getting append to and never cleared.  So that a LOCATE keeps getting slower and slower.

     

    David

     



    Terms & ConditionsAccessibility statement