• V9.2-1 Page file size

    From Chris Townley@21:1/5 to All on Sat Feb 24 19:18:32 2024
    Just upgraded a VM from 9.2-1 to 9.2-2 which seemed to have worked well.

    Bearing in mind this us just a hobbyist system, when I created the VM I
    gave it 8GB memory, and an 8Gb system disk

    That was fine, and it created a 2Mb pagefile, not expecting it to be used.

    The autogen run at the end of the upgrade obviously though this was
    rubbish, so tried to create an 8Gb pagefile on the system disk. Clearly
    it couldn't, so it created one of over 4Gb - leaving me with 120Mb free.

    It also wanted an 8Gb dumpfile.

    Is any of this sensible?

    --
    Chris

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Chris Townley on Sat Feb 24 19:12:48 2024
    On 2/24/2024 2:18 PM, Chris Townley wrote:
    Just upgraded a VM from 9.2-1 to 9.2-2 which seemed to have worked well.

    Bearing in mind this us just a hobbyist system, when I created the VM I
    gave it 8GB memory, and an 8Gb system disk

    That was fine, and it created a 2Mb pagefile, not expecting it to be used.

    The autogen run at the end of the upgrade obviously though this was
    rubbish, so tried to create an 8Gb pagefile on the system disk. Clearly
    it couldn't, so it created one of over 4Gb - leaving me with 120Mb free.

    It also wanted an 8Gb dumpfile.

    Is any of this sensible?

    I believe that is one of the differences between Windows and VMS. On
    Windows plenty of RAM and no/small pagefile works fine. VMS want
    pagefile backing of virtual memory even if it is not likely to
    need it. And running out of pagefile space is bad - very bad. So I got
    1 x 8 GB pagefile on my VMS x86-64 and 3 x 1 GB pagefile on
    my VMS Alpha (can't remember what I have on my VMS Itanium).

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Chris Townley on Sat Feb 24 19:52:10 2024
    On 2/24/2024 7:33 PM, Chris Townley wrote:
    On 25/02/2024 00:12, Arne Vajhøj wrote:
    On 2/24/2024 2:18 PM, Chris Townley wrote:
    Just upgraded a VM from 9.2-1 to 9.2-2 which seemed to have worked well. >>>
    Bearing in mind this us just a hobbyist system, when I created the VM
    I gave it 8GB memory, and an 8Gb system disk

    That was fine, and it created a 2Mb pagefile, not expecting it to be
    used.

    The autogen run at the end of the upgrade obviously though this was
    rubbish, so tried to create an 8Gb pagefile on the system disk.
    Clearly it couldn't, so it created one of over 4Gb - leaving me with
    120Mb free.

    It also wanted an 8Gb dumpfile.

    Is any of this sensible?

    I believe that is one of the differences between Windows and VMS. On
    Windows plenty of RAM and no/small pagefile works fine. VMS want
    pagefile backing of virtual memory even if it is not likely to
    need it. And running out of pagefile space is bad - very bad. So I got
    1 x 8 GB pagefile on my VMS x86-64 and 3 x 1 GB pagefile on
    my VMS Alpha (can't remember what I have on my VMS Itanium).

    But VSI recommended 8Gb memory, and an 8Gb system disk. So how do we fit
    that in? Especially if they want another 8Gb for the dump file

    I don't get it. 8 GB RAM makes sense. I would go for 20/30/40/50 GB
    disk.

    I don't think you need that big a dump file. It may want that big
    a dump file, but if I remember correctly then VMS writes a subset
    of data if the dumpfile is not big enough for all data. Obviously
    if you want perfect analysis of a crash, then a full size dumpfile
    may be nice, but ...

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Townley@21:1/5 to All on Sun Feb 25 00:33:24 2024
    On 25/02/2024 00:12, Arne Vajhøj wrote:
    On 2/24/2024 2:18 PM, Chris Townley wrote:
    Just upgraded a VM from 9.2-1 to 9.2-2 which seemed to have worked well.

    Bearing in mind this us just a hobbyist system, when I created the VM
    I gave it 8GB memory, and an 8Gb system disk

    That was fine, and it created a 2Mb pagefile, not expecting it to be
    used.

    The autogen run at the end of the upgrade obviously though this was
    rubbish, so tried to create an 8Gb pagefile on the system disk.
    Clearly it couldn't, so it created one of over 4Gb - leaving me with
    120Mb free.

    It also wanted an 8Gb dumpfile.

    Is any of this sensible?

    I believe that is one of the differences between Windows and VMS. On
    Windows plenty of RAM and no/small pagefile works fine. VMS want
    pagefile backing of virtual memory even if it is not likely to
    need it. And running out of pagefile space is bad - very bad. So I got
    1 x 8 GB pagefile on my VMS x86-64 and 3 x 1 GB pagefile on
    my VMS Alpha (can't remember what I have on my VMS Itanium).

    Arne

    But VSI recommended 8Gb memory, and an 8Gb system disk. So how do we fit
    that in? Especially if they want another 8Gb for the dump file

    --
    Chris

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Townley@21:1/5 to All on Sun Feb 25 01:02:48 2024
    On 25/02/2024 00:52, Arne Vajhøj wrote:
    On 2/24/2024 7:33 PM, Chris Townley wrote:
    On 25/02/2024 00:12, Arne Vajhøj wrote:
    On 2/24/2024 2:18 PM, Chris Townley wrote:
    Just upgraded a VM from 9.2-1 to 9.2-2 which seemed to have worked
    well.

    Bearing in mind this us just a hobbyist system, when I created the
    VM I gave it 8GB memory, and an 8Gb system disk

    That was fine, and it created a 2Mb pagefile, not expecting it to be
    used.

    The autogen run at the end of the upgrade obviously though this was
    rubbish, so tried to create an 8Gb pagefile on the system disk.
    Clearly it couldn't, so it created one of over 4Gb - leaving me with
    120Mb free.

    It also wanted an 8Gb dumpfile.

    Is any of this sensible?

    I believe that is one of the differences between Windows and VMS. On
    Windows plenty of RAM and no/small pagefile works fine. VMS want
    pagefile backing of virtual memory even if it is not likely to
    need it. And running out of pagefile space is bad - very bad. So I got
    1 x 8 GB pagefile on my VMS x86-64 and 3 x 1 GB pagefile on
    my VMS Alpha (can't remember what I have on my VMS Itanium).

    But VSI recommended 8Gb memory, and an 8Gb system disk. So how do we
    fit that in? Especially if they want another 8Gb for the dump file

    I don't get it. 8 GB RAM makes sense. I would go for 20/30/40/50 GB
    disk.

    I don't think you need that big a dump file. It may want that big
    a dump file, but if I remember correctly then VMS writes a subset
    of data if the dumpfile is not big enough for all data. Obviously
    if you want perfect analysis of a crash, then a full size dumpfile
    may be nice, but ...

    Arne

    But I only have system on the system disc. ISTR when we moved to IA64,
    we started with 8Gb, but had to increase it to have the Oracle client.

    I wonder what VSI have to say. When the resolve the gateway timeout, I
    might post there

    --
    Chris

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John H. Reinhardt@21:1/5 to Chris Townley on Sat Feb 24 22:11:28 2024
    On 2/24/2024 7:02 PM, Chris Townley wrote:
    On 25/02/2024 00:52, Arne Vajhøj wrote:
    On 2/24/2024 7:33 PM, Chris Townley wrote:
    On 25/02/2024 00:12, Arne Vajhøj wrote:
    On 2/24/2024 2:18 PM, Chris Townley wrote:
    Just upgraded a VM from 9.2-1 to 9.2-2 which seemed to have worked well. >>>>>
    Bearing in mind this us just a hobbyist system, when I created the VM I gave it 8GB memory, and an 8Gb system disk

    That was fine, and it created a 2Mb pagefile, not expecting it to be used.

    The autogen run at the end of the upgrade obviously though this was rubbish, so tried to create an 8Gb pagefile on the system disk. Clearly it couldn't, so it created one of over 4Gb - leaving me with 120Mb free.

    It also wanted an 8Gb dumpfile.

    Is any of this sensible?

    I believe that is one of the differences between Windows and VMS. On
    Windows plenty of RAM and no/small pagefile works fine. VMS want
    pagefile backing of virtual memory even if it is not likely to
    need it. And running out of pagefile space is bad - very bad. So I got >>>> 1 x 8 GB pagefile on my VMS x86-64 and 3 x 1 GB pagefile on
    my VMS Alpha (can't remember what I have on my VMS Itanium).

    But VSI recommended 8Gb memory, and an 8Gb system disk. So how do we fit that in? Especially if they want another 8Gb for the dump file


    I'm not sure where you saw that, but section 1.2.1 of the V9.2-2 Install says: https://docs.vmssoftware.com/vsi-openvms-x86-64-v922-installation-guide/#d0e99

    Memory: 8 GB.

    Note that if your installation fails due to the lack of memory, you can increase the amount of it for the duration of the installation and then, if needed, reduce it back.

    Operating system: Other 64-bit.

    A virtual disk for the system files. The disk must be at least 15 GB in size


    I don't get it. 8 GB RAM makes sense. I would go for 20/30/40/50 GB
    disk.

    I don't think you need that big a dump file. It may want that big
    a dump file, but if I remember correctly then VMS writes a subset
    of data if the dumpfile is not big enough for all data. Obviously
    if you want perfect analysis of a crash, then a full size dumpfile
    may be nice, but ...

    Arne

    But I only have system on the system disc. ISTR when we moved to IA64, we started with 8Gb, but had to increase it to have the Oracle client.

    I wonder what VSI have to say. When the resolve the gateway timeout, I might post there


    On my V9.2-2 install (not upgrade)I created a 24GB system disk. I allocated 12GB of memory and it creates a 2MB page file. Install left 10.2GB free so Install uses about 14GB on my system. This includes an 11.74GB dump file to match the 11.74GB usable
    memory. Autoconfig at the end did not try to make a bigger page file nor create a swapfile.




    Disk NORTON$DKA0:, device type VMware Virtual disk, is online, mounted, file-
    oriented device, shareable, available to cluster, error logging is enabled.

    Error count 0 Operations completed 11874
    Owner process "" Owner UIC [SYSTEM]
    Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:R,W
    Reference count 30 Default buffer size 512
    Current preferred CPU Id 1 Fastpath 1
    Total size 24.00GB Sectors per track 0
    Total cylinders 0 Tracks per cylinder 0
    Logical Volume Size 24.00GB Expansion Size Limit 383.99GB

    Volume label "NORTON_A0" Relative volume number 0
    Cluster size 3 Transaction count 182
    Free space 10.27GB Maximum files allowed 16711679
    Extend quantity 5 Mount count 1
    Mount status System Cache name "_NORTON$DKA0:XQPCACHE"
    Extent cache size 64 Max blocks in extent cache 2153983
    File ID cache size 64 Blocks in extent cache 30345
    Quota cache size 0 Maximum buffers in FCP cache 4734
    Volume owner UIC [1,1] Vol Prot S:RWCD,O:RWCD,G:RWCD,W:RWCD

    Volume Status: ODS-5, subject to mount verification, protected subsystems
    enabled, file high-water marking, write-through XFC caching enabled,
    write-through XQP caching enabled, hard links enabled, special files
    enabled.

    $ show mem
    System Memory Resources on 24-FEB-2024 22:05:53.79

    Physical Memory Usage (bytes): Total Free In Use Modified
    Main Memory (GB) 11.74 11.15 0.58 0.00

    Extended File Cache (Time of last reset: 16-FEB-2024 22:59:52.90)
    Allocated (MBytes) 32.50 Maximum size (MBytes) 6014.39
    Free (MBytes) 0.64 Minimum size (MBytes) 3.12
    In use (MBytes) 31.85 Percentage Read I/Os 84%
    Read hit rate 59% Write hit rate 0%
    Read I/O count 7545 Write I/O count 1368
    Read hit count 4482 Write hit count 0
    Reads bypassing cache 26 Writes bypassing cache 1
    Files cached open 205 Files cached closed 137
    Vols in Full XFC mode 0 Vols in VIOC Compatible mode 2
    Vols in No Caching mode 0 Vols in Perm. No Caching mode 0

    Granularity Hint Regions (bytes): Total Free In Use Released
    S0 Execlet data (MB) 16.00 14.53 1.46 0.00
    S0 Executive data (MB) 36.00 0.15 35.84 0.00
    S0 Executive RO data (MB) 8.00 6.54 1.45 0.00
    S0 Resident image code (MB) 24.00 23.35 0.64 0.00
    S0 Resident image data (MB) 4.00 4.00 0.00 0.00
    S0 Resident RO image data (MB) 8.00 8.00 0.00 0.00
    S2 Execlet code (MB) 32.00 15.16 16.82 0.00
    S2 Execlet data (MB) 32.00 32.00 0.00 0.00
    S2 Executive data (MB) 8.00 0.00 8.00 0.00
    S2 Resident image code (MB) 32.00 11.80 20.19 0.00
    S2 Resident image data (MB) 4.00 4.00 0.00 0.00

    Slot Usage (slots): Total Free Resident Swapped
    Process Entry Slots 949 936 13 0

    Dynamic Memory Usage: Total Free In Use Largest
    Nonpaged Dynamic Memory (MB) 24.00 21.56 2.43 21.50
    USB Addressable Memory (KB) 1024.00 1022.87 1.12 1022.87
    Paged Dynamic Memory (MB) 11.74 6.80 4.93 6.80
    Lock Manager Dyn Memory (KB) 592.00 306.03 285.96
    S2 Dynamic Memory Usage (MB) 7.97 7.69 0.28 7.69

    Buffer Object Usage (bytes): In Use Peak
    32-bit System Space Windows (S0/S1) (bytes) 0.00 0.00
    64bit System Space Windows (S2) (bytes) 0.00 0.00
    Physical bytes locked by buffer objects (bytes) 0.00 0.00

    Memory Reservations (bytes): Group Reserved In Use Type
    Total (0 bytes reserved) 0 0

    Paging File Usage (bytes): Index Free Size
    DISK$NORTON_A0:[SYS0.SYSEXE]PAGEFILE.SYS;1
    (MB) 254 2.18 2.18
    Total committed paging file usage:(MB) 18.71

    Of the physical memory in use, 572.25 MB are permanently allocated to OpenVMS. $ dir DISK$NORTON_A0:[SYS0.SYSEXE]PAGEFILE.SYS;1

    Directory DISK$NORTON_A0:[SYS0.SYSEXE]

    PAGEFILE.SYS;1 2.24MB/2.24MB 27-JAN-2024
    19:55:46.08 [1,1] (RWED,RWED,,)

    Total of 1 file, 2.24MB/2.24MB

    $ dir DISK$NORTON_A0:[SYS0.SYSEXE]sysdump.dmp

    Directory DISK$NORTON_A0:[SYS0.SYSEXE]

    SYSDUMP.DMP;1 11.74GB/11.74GB 27-JAN-2024
    21:41:45.65 [1,1] (RWED,RWED,,)

    Total of 1 file, 11.74GB/11.74GB

    --
    John H. Reinhardt

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to All on Sun Feb 25 05:30:57 2024
    On Sat, 24 Feb 2024 19:12:48 -0500, Arne Vajhøj wrote:

    On Windows plenty of RAM and no/small pagefile works fine.

    Really?? Last I heard, Windows would not run without a page/swap file. Did
    they fix that?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Duff@21:1/5 to Chris Townley on Sun Feb 25 19:37:35 2024
    On 25/2/24 11:33, Chris Townley wrote:
    On 25/02/2024 00:12, Arne Vajhøj wrote:
    On 2/24/2024 2:18 PM, Chris Townley wrote:
    Just upgraded a VM from 9.2-1 to 9.2-2 which seemed to have worked well. >>>
    Bearing in mind this us just a hobbyist system, when I created the VM
    I gave it 8GB memory, and an 8Gb system disk

    That was fine, and it created a 2Mb pagefile, not expecting it to be
    used.

    The autogen run at the end of the upgrade obviously though this was
    rubbish, so tried to create an 8Gb pagefile on the system disk.
    Clearly it couldn't, so it created one of over 4Gb - leaving me with
    120Mb free.

    It also wanted an 8Gb dumpfile.

    Is any of this sensible?

    I believe that is one of the differences between Windows and VMS. On
    Windows plenty of RAM and no/small pagefile works fine. VMS want
    pagefile backing of virtual memory even if it is not likely to
    need it. And running out of pagefile space is bad - very bad. So I got
    1 x 8 GB pagefile on my VMS x86-64 and 3 x 1 GB pagefile on
    my VMS Alpha (can't remember what I have on my VMS Itanium).

    Arne

    But VSI recommended 8Gb memory, and an 8Gb system disk. So how do we fit
    that in? Especially if they want another 8Gb for the dump file


    In a production environment, by putting the page file (and secondary
    page files) and the dump file on disks other than the system disk. The
    last thing you want is more paging to and from the system disk which
    does enough demand zero paging as it is due to image activation. With
    real hardware, locally connected disks are nice for page files as long
    as you can provide redundancy for them (hardware mirroring with a raid controller, for example).

    In a hobbyist situation, do you need a page file that large? Unless you
    have an app that uses masses of memory, you can probably get away with something smaller. I have 6GB of memory with 3GB of page file, and I
    rarely use more than 1% of the page file. See warnings about no dump
    file and selective dumps in the documentation (qv) if you do this!

    In a hobbyist situation, do you need a dump file? Unless you're doing
    kernel mode development, perhaps not. Set DUMPBUG=0 in MODPARAMS.DAT,
    reboot, and delete the dump file.

    If you do want a dump file, you can probably get away with something
    much smaller by specifying an appropriate value for DUMPSTYLE in
    MODPARAMS.DAT. You should at least compress the dump by setting bit 3,
    and choose other bits for that parameter based on your circumstances.

    Remember, if a dump file doesn't exist either in SYS$SYSTEM: or in a
    DOSD location that you've specified, VMS will use the page file to write
    the crash dump.

    There's an entire chapter devoted to all this in the "OpenVMS System
    Manager's Manual Vol 2". Find it here:

    https://vmssoftware.com/docs/VSI_SYS_MGMT_MANUAL_VOL_II.PDF

    Jim.
    --
    eight-cubed.com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to John H. Reinhardt on Sun Feb 25 08:00:43 2024
    On 2/24/2024 11:11 PM, John H. Reinhardt wrote:
    On 2/24/2024 7:02 PM, Chris Townley wrote:
    On 25/02/2024 00:52, Arne Vajhøj wrote:
    I don't get it. 8 GB RAM makes sense. I would go for 20/30/40/50 GB
    disk.

    I don't think you need that big a dump file. It may want that big
    a dump file, but if I remember correctly then VMS writes a subset
    of data if the dumpfile is not big enough for all data. Obviously
    if you want perfect analysis of a crash, then a full size dumpfile
    may be nice, but ...

    Arne

    But I only have system on the system disc. ISTR when we moved to IA64,
    we started with 8Gb, but had to increase it to have the Oracle client.

    I wonder what VSI have to say. When the resolve the gateway timeout, I
    might post there


    On my V9.2-2 install (not upgrade)I created a 24GB system disk.  I
    allocated 12GB of memory and it creates a 2MB page file.  Install left 10.2GB free so Install uses about 14GB on my system.  This includes an 11.74GB dump file to match the 11.74GB usable memory.  Autoconfig at the
    end did not try to make a bigger page file nor create a swapfile.

    I got a very small pagefile as well by default. But I increased the
    size.

    I believe it is still:

    memory usage exceed WSEXTENT => application can not allocate memory and
    crash

    running out of PAGEFILE => system crashes

    so WSEXTENT < sizeof(PAGEFILE) makes sense to me.

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Jim Duff on Sun Feb 25 08:09:23 2024
    On 2/25/2024 3:37 AM, Jim Duff wrote:
    On 25/2/24 11:33, Chris Townley wrote:
    On 25/02/2024 00:12, Arne Vajhøj wrote:
    VMS want
    pagefile backing of virtual memory even if it is not likely to
    need it. And running out of pagefile space is bad - very bad. So I got
    1 x 8 GB pagefile on my VMS x86-64 and 3 x 1 GB pagefile on
    my VMS Alpha (can't remember what I have on my VMS Itanium).

    But VSI recommended 8Gb memory, and an 8Gb system disk. So how do we
    fit that in? Especially if they want another 8Gb for the dump file

    In a hobbyist situation, do you need a page file that large?  Unless you have an app that uses masses of memory, you can probably get away with something smaller.  I have 6GB of memory with 3GB of page file, and I
    rarely use more than 1% of the page file.

    On my system @sys$startup:tomcat$startup and
    @sys$startup:activemq$startup without even using them
    bump usage to 600 MB.

    In a hobbyist situation, do you need a dump file?  Unless you're doing kernel mode development, perhaps not.  Set DUMPBUG=0 in MODPARAMS.DAT, reboot, and delete the dump file.

    If you do want a dump file, you can probably get away with something
    much smaller by specifying an appropriate value for DUMPSTYLE in MODPARAMS.DAT.  You should at least compress the dump by setting bit 3,
    and choose other bits for that parameter based on your circumstances.

    Remember, if a dump file doesn't exist either in SYS$SYSTEM: or in a
    DOSD location that you've specified, VMS will use the page file to write
    the crash dump.

    Yes. Unless one really are into reading crash dumps, then
    dumps are not so much fun.

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Lawrence D'Oliveiro on Sun Feb 25 07:54:36 2024
    On 2/25/2024 12:30 AM, Lawrence D'Oliveiro wrote:
    On Sat, 24 Feb 2024 19:12:48 -0500, Arne Vajhøj wrote:
    On Windows plenty of RAM and no/small pagefile works fine.

    Really?? Last I heard, Windows would not run without a page/swap file. Did they fix that?

    First time I heard about it was in the early 00's.

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Townley@21:1/5 to John H. Reinhardt on Sun Feb 25 13:48:56 2024
    On 25/02/2024 04:11, John H. Reinhardt wrote:
    On 2/24/2024 7:02 PM, Chris Townley wrote:
    On 25/02/2024 00:52, Arne Vajhøj wrote:
    On 2/24/2024 7:33 PM, Chris Townley wrote:
    On 25/02/2024 00:12, Arne Vajhøj wrote:
    On 2/24/2024 2:18 PM, Chris Townley wrote:
    Just upgraded a VM from 9.2-1 to 9.2-2 which seemed to have worked >>>>>> well.

    Bearing in mind this us just a hobbyist system, when I created the >>>>>> VM I gave it 8GB memory, and an 8Gb system disk

    That was fine, and it created a 2Mb pagefile, not expecting it to
    be used.

    The autogen run at the end of the upgrade obviously though this
    was rubbish, so tried to create an 8Gb pagefile on the system
    disk. Clearly it couldn't, so it created one of over 4Gb - leaving >>>>>> me with 120Mb free.

    It also wanted an 8Gb dumpfile.

    Is any of this sensible?

    I believe that is one of the differences between Windows and VMS. On >>>>> Windows plenty of RAM and no/small pagefile works fine. VMS want
    pagefile backing of virtual memory even if it is not likely to
    need it. And running out of pagefile space is bad - very bad. So I got >>>>> 1 x 8 GB pagefile on my VMS x86-64 and 3 x 1 GB pagefile on
    my VMS Alpha (can't remember what I have on my VMS Itanium).

    But VSI recommended 8Gb memory, and an 8Gb system disk. So how do we
    fit that in? Especially if they want another 8Gb for the dump file


    I'm not sure where you saw that, but section 1.2.1 of the V9.2-2 Install says: https://docs.vmssoftware.com/vsi-openvms-x86-64-v922-installation-guide/#d0e99

    Memory: 8 GB.

    Note that if your installation fails due to the lack of memory, you can increase the amount of it for the duration of the installation and then,
    if needed, reduce it back.

    Operating system: Other 64-bit.

    A virtual disk for the system files. The disk must be at least 15 GB in
    size


    I don't get it. 8 GB RAM makes sense. I would go for 20/30/40/50 GB
    disk.

    I don't think you need that big a dump file. It may want that big
    a dump file, but if I remember correctly then VMS writes a subset
    of data if the dumpfile is not big enough for all data. Obviously
    if you want perfect analysis of a crash, then a full size dumpfile
    may be nice, but ...

    Arne

    But I only have system on the system disc. ISTR when we moved to IA64,
    we started with 8Gb, but had to increase it to have the Oracle client.

    I wonder what VSI have to say. When the resolve the gateway timeout, I
    might post there


    On my V9.2-2 install (not upgrade)I created a 24GB system disk.  I
    allocated 12GB of memory and it creates a 2MB page file.  Install left 10.2GB free so Install uses about 14GB on my system.  This includes an 11.74GB dump file to match the 11.74GB usable memory.  Autoconfig at the
    end did not try to make a bigger page file nor create a swapfile.




    Disk NORTON$DKA0:, device type VMware Virtual disk, is online, mounted,
    file-
        oriented device, shareable, available to cluster, error logging is enabled.

        Error count                    0    Operations completed              11874
        Owner process                 ""    Owner UIC [SYSTEM]
        Owner process ID        00000000    Dev Prot S:RWPL,O:RWPL,G:R,W
        Reference count               30    Default buffer size                 512
        Current preferred CPU Id       1 Fastpath                              1
        Total size               24.00GB    Sectors per track                     0
        Total cylinders                0    Tracks per cylinder                   0
        Logical Volume Size      24.00GB    Expansion Size Limit 383.99GB

        Volume label         "NORTON_A0"    Relative volume number                0
        Cluster size                   3    Transaction count                   182
        Free space               10.27GB    Maximum files allowed
    16711679
        Extend quantity                5    Mount count                           1
        Mount status              System    Cache name "_NORTON$DKA0:XQPCACHE"
        Extent cache size             64    Max blocks in extent cache
    2153983
        File ID cache size            64    Blocks in extent cache            30345
        Quota cache size               0    Maximum buffers in FCP
    cache       4734
        Volume owner UIC           [1,1]    Vol Prot S:RWCD,O:RWCD,G:RWCD,W:RWCD

      Volume Status:  ODS-5, subject to mount verification, protected subsystems
          enabled, file high-water marking, write-through XFC caching enabled,
          write-through XQP caching enabled, hard links enabled, special files
          enabled.

    $ show mem
                  System Memory Resources on 24-FEB-2024 22:05:53.79

    Physical Memory Usage (bytes):     Total        Free      In Use
    Modified
      Main Memory             (GB)     11.74       11.15        0.58
    0.00

    Extended File Cache  (Time of last reset: 16-FEB-2024 22:59:52.90)
     Allocated (MBytes)             32.50    Maximum size (MBytes)
    6014.39
     Free (MBytes)                   0.64    Minimum size (MBytes)             3.12
     In use (MBytes)                31.85    Percentage Read I/Os                84%
     Read hit rate                     59%   Write hit rate                       0%
     Read I/O count                  7545    Write I/O count                   1368
     Read hit count                  4482    Write hit count                      0
     Reads bypassing cache             26    Writes bypassing cache               1
     Files cached open                205    Files cached closed                137
     Vols in Full XFC mode              0    Vols in VIOC Compatible
    mode         2
     Vols in No Caching mode            0    Vols in Perm. No Caching
    mode        0

    Granularity Hint Regions (bytes):   Total        Free      In Use
    Released
      S0 Execlet data           (MB)    16.00       14.53 1.46        0.00
      S0 Executive data         (MB)    36.00        0.15 35.84        0.00
      S0 Executive RO data      (MB)     8.00        6.54 1.45        0.00
      S0 Resident image code    (MB)    24.00       23.35 0.64        0.00
      S0 Resident image data    (MB)     4.00        4.00 0.00        0.00
      S0 Resident RO image data (MB)     8.00        8.00 0.00        0.00
      S2 Execlet code           (MB)    32.00       15.16 16.82        0.00
      S2 Execlet data           (MB)    32.00       32.00 0.00        0.00
      S2 Executive data         (MB)     8.00        0.00 8.00        0.00
      S2 Resident image code    (MB)    32.00       11.80 20.19        0.00
      S2 Resident image data    (MB)     4.00        4.00 0.00        0.00

    Slot Usage (slots):                Total        Free    Resident
    Swapped
      Process Entry Slots                949         936 13           0

    Dynamic Memory Usage:              Total        Free      In Use
    Largest
      Nonpaged Dynamic Memory (MB)     24.00       21.56        2.43
    21.50
      USB Addressable Memory  (KB)   1024.00     1022.87        1.12
    1022.87
      Paged Dynamic Memory    (MB)     11.74        6.80        4.93
    6.80
      Lock Manager Dyn Memory (KB)    592.00      306.03      285.96
      S2 Dynamic Memory Usage (MB)      7.97        7.69        0.28
    7.69

    Buffer Object Usage (bytes):                              In Use
    Peak
      32-bit System Space Windows (S0/S1)     (bytes)
    0.00        0.00
      64bit System Space Windows (S2)         (bytes) 0.00        0.00
      Physical bytes locked by buffer objects (bytes)
    0.00        0.00

    Memory Reservations (bytes):       Group    Reserved      In Use
    Type
      Total (0 bytes reserved)                         0           0

    Paging File Usage (bytes):                     Index        Free
    Size
      DISK$NORTON_A0:[SYS0.SYSEXE]PAGEFILE.SYS;1
                                        (MB)         254        2.18
    2.18
      Total committed paging file usage:(MB)
    18.71

    Of the physical memory in use, 572.25 MB are permanently allocated to OpenVMS.
    $ dir DISK$NORTON_A0:[SYS0.SYSEXE]PAGEFILE.SYS;1

    Directory DISK$NORTON_A0:[SYS0.SYSEXE]

    PAGEFILE.SYS;1                                     2.24MB/2.24MB
    27-JAN-2024
     19:55:46.08  [1,1]            (RWED,RWED,,)

    Total of 1 file, 2.24MB/2.24MB

    $ dir DISK$NORTON_A0:[SYS0.SYSEXE]sysdump.dmp

    Directory DISK$NORTON_A0:[SYS0.SYSEXE]

    SYSDUMP.DMP;1                                     11.74GB/11.74GB
    27-JAN-2024
     21:41:45.65  [1,1]            (RWED,RWED,,)

    Total of 1 file, 11.74GB/11.74GB


    OK, I clearly need to rebuild a larger system disk
    Many thanks

    --
    Chris

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to All on Sun Feb 25 20:14:50 2024
    On Sun, 25 Feb 2024 07:54:36 -0500, Arne Vajhøj wrote:

    On 2/25/2024 12:30 AM, Lawrence D'Oliveiro wrote:

    On Sat, 24 Feb 2024 19:12:48 -0500, Arne Vajhøj wrote:

    On Windows plenty of RAM and no/small pagefile works fine.

    Really?? Last I heard, Windows would not run without a page/swap file.
    Did they fix that?

    First time I heard about it was in the early 00's.

    Remember when “netbooks” first came along? Initial Linux-based models like the Asus Eee 701 (I have one) were the first machines with SSDs and no
    hard drive. Microsoft had just introduced Vista, which was hopelessly
    inept on running on such small machines. So they postponed the death of
    XP, and together with Intel, they managed to put limits on the specs of
    these machines, so that they could continue running XP.

    XP was hard on SSDs, because it required a swap file, and the continual
    writing to the SSD shortened its life.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Clubley@21:1/5 to Chris Townley on Mon Feb 26 18:31:56 2024
    On 2024-02-24, Chris Townley <news@cct-net.co.uk> wrote:
    Just upgraded a VM from 9.2-1 to 9.2-2 which seemed to have worked well.

    Bearing in mind this us just a hobbyist system, when I created the VM I
    gave it 8GB memory, and an 8Gb system disk

    That was fine, and it created a 2Mb pagefile, not expecting it to be used.

    The autogen run at the end of the upgrade obviously though this was
    rubbish, so tried to create an 8Gb pagefile on the system disk. Clearly
    it couldn't, so it created one of over 4Gb - leaving me with 120Mb free.


    That was a stupid thing for autogen to do.

    There should be some inbuilt free space limit so that autogen never leaves
    the free space on the disk below something like 10%. That way, you can
    continue with the upgrade/installation without trashing the system disk
    by filling it up, and hence you get the opportunity to fix that on a reboot.

    The other thing I don't like about this is that autogen should run initially
    in test mode during the installation/upgrade, and then only commit the
    changes after you are happy with them. You know, just like we are all taught
    to do when adjusting autogen parameters manually. :-)

    It also wanted an 8Gb dumpfile.


    That should have been optional. Were you asked if you wanted a dumpfile ?
    If not, that's probably something else that should be added.

    So, does anyone agree or disagree with the above suggestions ?

    Simon.

    --
    Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    Walking destinations on a map are further away than they appear.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From abrsvc@21:1/5 to All on Thu Feb 29 11:27:30 2024
    First of all there is no need for a specific dump file at all. Setting SAVEDUMP allows the use of the pagefile for a dump that can then be copied elsewhere to free up the pagefile upon reboot. Also, setting dumpstyle such that the selective dump is
    selected, will reduce the size requirements and most often save sufficient information to analyze the dump and locate the problem that caused the crash.

    Most systems have a small pagefile on the system disk and other larger ones on alternative devices to address any pagefile size requirements as well as performance.

    This has been the case for years and should not be news to anyone here. I recall using the above pagefile techniques for VAX systems 30+ years ago. Even the dump file (if you want a specific one) can be on an alternative drive (see DOSD).

    Dan

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)