| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 5406.1 | Is MCC running with its compatible version of CMA? | TEMTY::L_GROSSMAN | | Fri Jul 30 1993 09:14 | 3 |
|
MCC would display an error message when starting up that the CMA version
is incompatible. This has been seen with DAP running.
|
| 5406.2 | Yes, CMA V1.10-030 | UTRTSC::BEEKMAN | Ton Beekman - MCS/SSO NL - 7838 2345 | Mon Aug 02 1993 04:07 | 8 |
|
Yes, MCC is running its compatible version of CMA
image name: "CMA$RTL"
image file identification: "CMA V1.10-030"
MCC is also NOT displaying any error messages during startup.
|
| 5406.3 | And the other three? | RACER::dave | Ahh, but fortunately, I have the key to escape reality. | Mon Aug 02 1993 07:18 | 7 |
| Yes, thats the version of ONE of the CMA images, how about the other three
that need to match. I have seen at least one site that had replaced only two
of the four images, and everything looked fine, but memory usage went sky high.
Also, how quickly does the memory go away?
Continious, Big burst then slowly, Nothing then suddenly lots?
What are the usefull numbers?
|
| 5406.4 | Also the right version | UTRTSC::BEEKMAN | Ton Beekman - MCS/SSO NL - 7838 2345 | Mon Aug 02 1993 08:58 | 44 |
|
The other files on this system, are the same ones as those from
the MCCBMS013.C saveset.
CMA$LIB_SHR.EXE;3 30-APR-1992 14:39:20.00
image file identification: "CMA T1.11-000"
CMA$OPEN_LIB_SHR.EXE;2 30-APR-1992 14:39:19.00
image file identification: "CMA T1.11-000"
CMA$OPEN_RTL.EXE;3 12-JUN-1992 16:40:43.62
image file identification: "CMA V1.10-030"
CMA$RTL.EXE;3 12-JUN-1992 16:41:12.77
image file identification: "CMA V1.10-030"
About the behaviour:
Process has a starting pgflquo of 150.000
When the MCC_EXPORTER_FM_BG image is running about 70000 pages
are left
Here are some samples:
Time Paging file quota
11:49 70747
11:59 58547
12:05 55134
12:17 45784
12:25 45720
12:37 41258
12:47 41149
12:57 36988
13:07 28258
13:17 21144
13:27 12456
13:33 8142
13:35 6570
13:37 2640
13:41 1854
13:47 0 gone/dead
|
| 5406.5 | | UTRTSC::BEEKMAN | Ton Beekman - MCS/SSO NL - 78382345 | Wed Aug 04 1993 09:48 | 7 |
| Is there anybody else who has seen this problem, or can reproduce this?
At the moment I'm reproducing this in the office, and you see that the
pagefilequota is dropping. But you've to setup many exporting requests,
to see this behaviour.
Ton
|
| 5406.6 | Export job died when pagefile drop to 7000 | GIDDAY::WAN | Denny Wan, Sydney CSC | Sun Dec 05 1993 20:43 | 44 |
| My customer has encountered a similar problem. In this case, the
exportor always died when there was about 7000 pages left. He got the
following error in the log file :
$ SET PROCESS/DUMP
$ BTS == "$SYS$SYSTEM:MCC_EXPORTER_FM_BG.EXE"
$ BTS "dka0:[reports_data]export_faulding.rdb" "10"
%CMA-F-EXCCOP, exception raised; VMS condition code follows
-SYSTEM-F-INSFMEM, insufficient dynamic memory
%CMA-F-EXCCOP, exception raised; VMS condition code follows
-SYSTEM-F-INSFMEM, insufficient dynamic memory
NETMAN job terminated at 4-DEC-1993 17:45:44.81
Accounting information:
Buffered I/O count: 2198146 Peak working set size:
25000
Direct I/O count: 205165 Peak page file size:
242205
Page faults: 10704755 Mounted volumes:
0
Charged CPU time: 1 03:26:37.07 Elapsed time: 2
03:01:42.04
The relevent quotas are :
WSMAX 45,000 Virtualpagecnt 300,000
WSExtent 25,000 Pagfilquo 25,000
We have been gradually increasing the virtual page count and pagefile
quota and it has extened the time before the export job died. Is this
an indication of a memory leak problem?
We have checked the CMA image and they are the same as in .4? We are
exporting both data for the Node4 and NIS entities.
What can we do to alleviate the problem?
Any ideas welcomed.
Denny.
|
| 5406.7 | ex | GIDDAY::WAN | Denny Wan, Sydney CSC | Sun Dec 05 1993 20:45 | 2 |
| Further to .6, the export job was sitting at a pagefile consumption of
130,000 pages for almost a day before it surges up to 249,000 and died.
|
| 5406.8 | Please CLD this problem | TOOK::GUERTIN | I am never worng | Tue Dec 07 1993 09:13 | 6 |
| We have instrumented isolating massive memory leaks, such as these
using our own version of the Fake-VM tool. If you CLD this (QAR system
is a mess, don't use it for a while) we should be able to do
isolation/repair work on the exporter.
-Matt.
|
| 5406.9 | | RACER::dave | Ahh, but fortunately, I have the key to escape reality. | Tue Dec 07 1993 16:32 | 2 |
| Also, please DONOT put a "pointer" to the notes file in the CLD,
but put the information there.
|
| 5406.10 | CLD case CFS.4969 | UTRTSC::BEEKMAN | Ton Beekman - NL/MCS - 7838-2345 | Wed Dec 08 1993 03:19 | 5 |
| A CLD of this problem had already been made on 9-aug-1993.
See case CFS.4969
Until now no solution yet.
Ton
|