Large srt* file in progress 4gl

Question

Progress version 11.0 srt* (srt) sort/temp files grow very large in RHEL Linux 6.0. Isolated to specific database that is used with webspeed for web application. Using the -T switch parameter to define the location of file. Not using -t so the files are disconnected and not showing on the file system.

executing lsof at the shell shows the files grow to GB sizes and increasing. Third column is size in byes:

_mprosrv 29968 3862790144 /usr/temp/srtJrjsxX (deleted)

_mprosrv 31588 15290187776 /usr/temp/srtVEi9Lp (deleted)

_mprosrv 32644 1533157376 /usr/temp/srtTozP1W (deleted)

_mprosrv 32667 3890683904 /usr/temp/srte5qI1U (deleted)

Is there a way to limit the size of these temp files or stop them from growing so large?

Answer 1

If you are on 11.0, consider upgrading to 11.2 or later.

There is apparently a bug (referred to as defect OE00227173, fixed in 11.2) where some large queries cause the _mprosrv processes to continually grow their .srt files rather than reuse the filespace as they are supposed to.

From the release notes:

Issue Number: OE00227173 Temp sort file grow every time that a query is executed

When running a search that has any wildcard in a word-index, the search will create an srt file on the db server. If the query returns a large of number of rows (greater than 100,000) then space in the sort file is not entirely re-used and the .srt can grow very large.

Temporary relief can be found by disconnecting user sessions from the server PIDs in question and then terminating the server processes (best to use promon R&D,4,7,7).

Code to fetch users by server PID:

def var v-pid as int format ">>>>>>>>>9" label "Server PID" no-undo.

do while true:
    update v-pid with frame f1 side-labels.

    find _server where _server._server-pid eq v-pid
        no-lock no-error.
    disp _server with frame f2.

    for each _connect where
        _connect._Connect-Server eq _server._server-num  /** NOT _server-id **/
        no-lock:

        find _userio where _connect._connect-id eq _userio._userio-id
        no-lock no-error.

        disp _connect._Connect-Usr /** NOT _Connect-Id **/
             _connect._Connect-Name
             _connect._Connect-Device
             _connect._Connect-Time
             _connect._Connect-Pid
             _userio._userio-dbaccess
             _userio._userio-dbread
             _userio._userio-dbwrite.

    end.
end.

Answer 2

No, there is no parameter to limit them. Understanding what you are doing to cause the growth is key. Usually they are the result of queries that lack appropriate indexes and thus must have records selected and sorted by the client.

I would:

• Enable -t on clients so that you can monitor SRT file growth in realtime.
• Enable client statement caching so that you can determine what query on what line of code in which source module is responsible when growth occurs.
• Compile with XREF and DEBUG so that you can review your code for table scans (XREF "whole index" references) and find (debug) source lines from the statement cache info
• Download ProTop 3 from http://dbappraise.com/protop.html so that you can monitor query activity in real time
• Add the -noautoresultlist parameter to your client startup (it is not a panacea but it might help in some cases)
• If you happen to catch a client "in the act" without client statement caching enabled send "kill -USR1 " then find and examine the 4gl stack trace in protrace. (probably in the startup dir of the client)