Insufficient virtual memory error - Help!!

[Jorge Cocomess]

A user received this error during proceesing.

Selected 9713400 records of 9828613 tested Mon Dec 5 17:14:29 2005
Selection Analysis statistics in disk13:[SELECT_STATS]/TWORET_20051205_155806.txt
%SORT-W-SYSERROR, system service error
-LIB-F-INSVIRMEM, insufficient virtual memory
%SORT-W-SYSERROR, system service error
-LIB-F-INSVIRMEM, insufficient virtual memory
%SORT-W-SYSERROR, system service error
-LIB-F-INSVIRMEM, insufficient virtual memory

Even though I had increased the user (UAF)PGFLQUO to 2,000,000 and still expereince
this error.

H/W Platform: ES45 OpenVMS 7.3-2 W/16GB of RAM

Please direct me to a resolution. Thank you in advance.

Jorge C.

[Arch_Muthiah]

Jorge C,

The same error has been discussed in detail earlier in this forum, please go thru this link, will be helpfull,

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=701623

Archunan

[Arch_Muthiah]

Jorge C,

This error has occured while sorting the file, that's SORT-W-SYSERROR and INSVIRMEM error. The virtual memory allocated to a process is sum of WSQUOTA and PGFLQUOTA. So try to increase both these parameter value to the value enough to SORT the file.


Archunan

[Steven Schweda]

help /mess /facility = LIB INSVIRMEM

[Jorge Cocomess]

Archunan - How much more do I need to increase these values? Currently, PGFLQUO = 4,000,0000 and WSquota=32,652

After the value has been increased, error still exist during the sort.

At this time, I think I need to call HP for support.

Thanks!!

[David B Sneddon]

Jorge,

You are trying to sort 9,713,400 records.
How big are the records?
From this you should be able to work out how
much space you need for the sort.

Dave

[Thomas Ritter · Accepted solution]

If the problem is memory related sorting try file based sorting. From VMS help


SORT

/WORK_FILES

Examples


1.$ ASSIGN DRA5: SORTWORK0
$ ASSIGN DB0: SORTWORK1
$ ASSIGN DB1: SORTWORK2
$ SORT/KEY=(POS:1,SIZ:80)/WORK_FILES=3 -
_$ STATS1,STATS2,STATS3,STATS4 SUMMARY.LIS

Because the input files in this sort operation are large files,
specifying three work files improves the efficiency of the sort
operation.

Note that you can also assign the work files to a specific
directory on a device by including the directory name. For

[Hein van den Heuvel]

Yes, this would be a perfect question for support, but it is well documented and has been answered many times before.

It basically says you told SORT is could use more page (WSEXTEND) then it could actually map (PGFLQUO and the 1GB memory limit). Sort anticipates thsi problem, and in general can deal with it. It may just be a WARNING.

Check out $SHOW WORK and $SHOW PROC/QUO

google: +sort +insvirmem +warning +site:itrc.hp.com

points to:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=701623


Counter-intuitively perhaps you need to DECREASE params, not increase. Have you benchmarked your sorts at all? You may be well beyon the point of diminishing returns with your workingset/pagefilequota.

If the data can not entirely fit in memory (say larger than 1GB, which it appears to be), then you might as well go down again, say to 100MB. That will generate plenty space for sort 'runs' which will go to the workfiles to be merged later.

I assume this worked at some point with a smaller dataset? What did the sort stats tell you? Did it go out to the work disk?

I _thought_ there was a whitepaper floating around with sort memory settings, but I can not find that just now. Maybe it was HP internal (notesfile).

hth,
Hein.

[Arch_Muthiah]

Jorge C,

Hope you have solved your problem by doing DCL sort. If you interested only DCL sorting, then you can prefer high performance DCL hypersort by defining this $ DEFINE hsort SYS$LIBRARY:HYPERSORT.EXE
now you can use $hsort/key=(,,) infile.

You could have mentioned the input file size; anyway though we can not exactly calculate the VM requirement,

1. we can keep pglquota size 4 times of the input file size and not exceeding half of your phy.paging file size. or

2.increase the Phy paging and swap file size
because, for example when your sort process runout of its wsquota limit, borrow limit reached, and no more chance to get free pages from neighbouring process as all are required sit in mem. In this situation, if any other high priv process needs some free pages from sort process as it has some unused pages, the sort process now in demand to freeup some of its pages, these pages of data will go to (un) or mdified page portion of paged mem(pgflqouta) and inturn to phy.paging file. If there is not enough space in paged mem area, then there will be insufficient virt mem problem.

Also you mentioned you allocated PGFLQUO = 4,000,0000 and WSquota=32,652. You may be known this, but anyway just I want mention this.... eventhough you have large pglqou size, the runtime error you got not just due to your infile size and sort verb. It depends on so many entities and its acitivities, and the way program designed. Yes, the efficient program won't consume more memory; for example, the fortran prog read the two dimentional table row-wise and c-Prog will read column-wise, imagine how much the pagefaults difference.
Like this, this particular error depends on how many process (COMPuted queue length)sharing pgflqou, modified/unmodified page mem size, processes's wssetsize, wsextent, wsquota, borrow limit, Phy.paging - swapfile size, maximum pagefaults limit per process, etc, etc...

Note: When you have large file to be sorted, HP recommends to go for mem upgrade.

Archunan

[Rudolf Wingert]

Hello Jorge,
I did see the same behavior years ago. Sometimes the problem comes with applications, which maps dynamical memory. OpenVMS hold this memory regardless you free it and exit the application. Did you try the same command in a new one terminal?
AFAIK some system parameters are important too (NPAGEDYN, VIRTUALPAGECNT...). An other action is to purge or delete files to free space in memory.
Best regards R. Wingert

[Robert Gezelter]

Jorge,

As Hein has pointed out, the problem is an inconsistency between PGFLQUOTA, WSQUOTA, WSEXTENT, and potentially some other parameters. In effect, VIRTUALPAGECNT and WSEXTENT would leave SORT with the presumption that it can expand virtual memory when in fact other quotas prevent it. Hein has already mentioned this, and I will not re-hash it.

There are some points worth mentioning that may have been overlooked in the discussion:

- WSEXTENT is often overidden for BATCH queues. Thus procedures which work interactively fail in production with the larger WSEXTENT available to the batch job. The cure for this is to ensure that the values in the UAF are compatible with both the interactive WS parameters (which are in the UAF on a per-account basis) and the WS parameters used for batch queues (check these with the SHOW QUEUE command).

- A common mis-understanding is that the virtual size needed to efficiently sort a file is related to the size of the file. Sorting is a very well studied and understood process (see Knuth "Volume 3: Sorting and Searching", among others for an extensive analysis). To summarize, the amount of memory, physical or virtual, required to sort a file is a very small fraction of the file's size. It is true that SORT will attempt to pull the entire file into memory, but that is not necessary, not will it produce optimal performance. Large file sorts with work files are extremely efficient. What is more important, in many such cases, the sufficient extension and buffering on the input and output files, not the io operations done on the work files.

- Bob Gezelter, http://www.rlgsc.com

[Jorge Cocomess]

Please close