lbi File Growing Like Mad - how to diagnose

Posted by S33 on 20-Nov-2019 15:56

Yesterday & today, I am plagued with an lbi file that is growing and filling the hard disk. The code base has been stable, so it must be something in the current data that is looping, calling recursively, etc.

Is there any way to tell what process/user/program is associated with a given lbi file? I'm running with -t so the lbi files are visible, but all of them are owned by root. I did a "strings lbixxx |pg" on the big one and saw some program names in all caps, and a few lines of report output, but they did not lead me to a smoking gun yet.

Any advice?  ProTop to the rescue ??

This is 11.7.1 on RHEL. Thx in advance --

(And yes, this is urgent!)

All Replies

Posted by ChUIMonster on 20-Nov-2019 16:22

ProTop might be able to rescue you in that the user who is doing this is probably a pretty active user and is likely at or near the top of the "User IO Activity" screen.  And you could enable the client statement cache (perhaps for just one user) to see what such a user is doing.

However... that assumes that the user is actually doing stuff with the db.  And they might not be.  So what you really want to do is to run:

sudo fuser filename

This will give you a list of process ids that have that file open.  Since it is an LBI file I expect that there will only be a single PID.

The next thing to do would be to get a 4gl stack trace with:

proGetStack <pidFromAbove>

Posted by George Potemkin on 20-Nov-2019 17:11

Examples:

28828 ls -l --time-style=full-iso lbitaoXQc 
-rw-r--r--. 1 root root 0 2019-11-20 20:04:21.612734866 +0300 lbitaoXQc

28828 tail -2 sports.lg
[2019/11/20@20:04:03.811+0300] P-28275      T-140480595711808 I ABL     5: (452)   Login by root on /dev/pts/5. 
[2019/11/20@20:04:21.618+0300] P-28748      T-140480595711808 I ABL     5: (7129)  Usr 5 set name to root. 

Timestamps: 20:04:21 (wrong example, see below )

fuser

$ fuser lbitaoXQc
lbitaoXQc: 28748

lsof

$ lsof lbitaoXQc 
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
_progres 28748 root    5u   REG    8,2        0 416428 lbitaoXQc

Update: Example with 'ls' command is wrong: the common filesystems used in Linux don't store the creation time. But the ext4 file system does store it: stat -c %W lbi*

Posted by Tim Kuehn on 21-Nov-2019 18:27

lbi is created by vars and TTs which have defaulted to "undo" instead of having  a 'no-undo' phrase added.

If you have "undo" elements in your code and the structure of the data you're processing has changed, that could be the cause of this "all of the sudden".

Posted by Tim Kuehn on 21-Nov-2019 18:28

KB on lbi:

knowledgebase.progress.com/.../P66690

In addition to "undo" vars and TTs, lbi is also used for subtransactions:

Only subtransactions (a transaction block nested within another transaction block) and UNDO objects (variables and temp tables) are written to the ABL client local-before-image (lbi) file.

This thread is closed