_proapsv process linked to the unlinked DBI- (deleted) file in Red Hat Linux

[Ryszard Musielak]

Hello,

can anyone tell me what is this process?

# lsof | grep \(deleted\) | grep -v grep | grep _proap |  sort -nrk 7 | nl | more
    1  _proapsv  16440                 root   22u      REG                8,1  3165913088   18724878 /usr/wrk/DBI-208636096OCAD12 (deleted)

It's using over 3GB of data, when I check for the DB process, it is not in any way linked to any background jobs:

[root@myserver]# proshut /bcp/pack/package -C list | grep 16440
 82  16440 Sun Oct 24 14:51:04 2021   plindsay    BAT   batch                no

In the past I once terminated such a process, but I think it's caused some damage, so not sure if I can terminated it.

It does seem to be spawned by this app server:

# asbman -i AccordLive -q | grep 16440
16440 AVAILABLE 16114 019979 022061 053014 24-Oct-2021 14:51 08-Nov-2021 13:17

What can I do about it? The file shown by the lsof command indicated the 3GB cannot be released until this process ends.

Kind Regards,
Richard

 

[Cringer]

_proapsv is an appserver process.

 

[Stefan]

proGetStack can help identify what that process is doing.

 

[Rob Fitzpatrick]

When an ABL client process (e.g. _progres, prowin, prowin32, _proapsv, etc.) starts, it creates temporary files in its temp (-T) directory. These include DBI (temp-table database storage), lbi (local before-image), srt (sort file) and rcd (r-code cache).

In Unix they are created as unlinked files by default; if desired, this can be overridden with the -t client startup parameter. The advantage of unlinked files is that there is nothing left to clean up if the client terminates abnormally. The disadvantage is that they are not seen in directory listings and their usage is not shown in df output. As you have seen, their descriptors are shown as "(deleted)" in lsof output.

You shouldn't delete the files of a running application client. That isn't helping anyone.

But you, or whoever is responsible for this application, should look at why it is creating so much temp-table data. It seems the application is reading a lot of data from somewhere (likely the database), then writing it to temp-tables. If the data source is the database then this is an inefficient design. It would likely be better to read the data directly from the database and work with it, as opposed to read from DB/write to DBI/read from DBI. But without knowing anything about this app server I can't speculate further about what is wrong and how to fix it.

 

[Ryszard Musielak]

Thank you for your responses.

But you, or whoever is responsible for this application, should look at why it is creating so much temp-table data

Ha, easier said than done, I can report this to my third party, but I am not sure how quickly I will get an answer.

I know the issues around this from these articles:

Progress Customer Community

progress-supportcommunity.force.com

Why is space not being freed from disk after deleting a file in Red Hat Enterprise Linux? - Red Hat Customer Portal

Why is space not being freed from disk after deleting a file in Red Hat Enterprise Linux? When deleting a large file or files, the file is deleted successfully but the size of the filesystem does not reflect the change. I've deleted some files but the amount of free space on the filesystem has...

access.redhat.com

However, since the file is the "unlinked" type, it is not possible to do anything but to stop and start the Apps server as the cleanest way.

I have a feeling this is related to a user session that was terminated abruptly. I will wait till tomorrow, users login to our system from Citrix servers which get rebooted every night, so this might get cleared over-night.

My aim is to create an additional 30GB partition like /workspace and change the DB parameters to create those TEMP structures there. As we do DR scenarios every 6 months, the DB and Apps server get shut down anyway, which clears this neatly.

Thanks again
Richard

 

[Rob Fitzpatrick]

My aim is to create an additional 30GB partition like /workspace and change the DB parameters to create those TEMP structures there.

These are not database temp files. You need to change the -T directory of the app server, in ubroker.properties.

 

[Ryszard Musielak]

These are not database temp files. You need to change the -T directory of the app server, in ubroker.properties.

My apologies for not being so specific, I was thinking more generally. I stand corrected.

and Thank you.
R.