- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Page file quota exhaustion observed on Itanium...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-24-2014 03:53 AM
02-24-2014 03:53 AM
Page file quota exhaustion observed on Itanium but not on Alpha.
OK,
On our Itanium systems (RX2800, OpenVMS 8-4, Update v7.0, TCPIP 5-7 ECO 3) we are seeing one of the processes exitting with %LIB-F-INSVIRMEM, insufficient virtual memory.
This has never occurred on our Alpha systems (OpenVMS 7-3-2).
The issue seems to be arounf the creation and un mapping of global sections. The system service call $CRMPSC_GFILE_64 is used tp create a global section, this is then deleted using $DELTVA_64.
Reproducing the calls used shows a gradual exhausting of page file quota on the Itanium, no issues are observed when running the same program on the Alpha (7-3-2). I am unable to test Alpha 8-3 or 8-4, our DS15 running 8-3 failed last week.
Anyway, I've attached the code (Pascal) used to replicate the problem.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-25-2014 02:59 PM
02-25-2014 02:59 PM
Re: Page file quota exhaustion observed on Itanium but not on Alpha.
Brian,
Nice reproducer. Interesting. I can't see anything obvious which might cause a leak. Does it leak if you just repeatedly map/unmap a single section, or does it take map 1000/unmap 1000?
Maybe modify the program so it outputs PAGFILCNT ($GETJPI) at strategic places to narrow down the event and quantify the size of the leak? Could it be an effect of rounding to whole pages?
I'd also include the output LIB$STAT_VM - there's a possibility that you're checker boarding the heap (again, can't see where that might happen in your code, but it's worth looking).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-25-2014 03:03 PM
02-25-2014 03:03 PM
Re: Page file quota exhaustion observed on Itanium but not on Alpha.
Oh, just realised... something else that might be interesting.
Instead of MAP 1..1000 then UNMAP 1..1000
see what happens if you MAP 1..1000 and UNMAP 1000..1
This may make a difference in terms of how the VM system deals with deleting and possibly reusing memory.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-26-2014 12:47 AM
02-26-2014 12:47 AM
Re: Page file quota exhaustion observed on Itanium but not on Alpha.
Hi John.
I fell over the solution yesterday afternoon , it seems to be a leak around the use of the Pascal OPEN routine and lack of corresponding CLOSE.
Each mapping of the global section calls OPEN with a useraction to get the channel. The UNMAP routines just calls $DASSGN using the channel. The size of the type use to defined the file is (SECTION_FILE_TYPE) is 524 bytes.
Amending the code to pass the file handle backwards and forwards and adding a CLOSE of the appropriate file to the UNMAP routine stops the memory leak. It would seem there is a subtle difference in the Pascal RTL between VMS 8-3 and 7-3-2, possibly just between the Alpha and Itanium versions.
Anyway, thanks for the help
cheers
Brian
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-03-2014 07:59 AM
03-03-2014 07:59 AM
Re: Page file quota exhaustion observed on Itanium but not on Alpha.
The Pascal RTL keeps an internal list of all open files. It needs that in the event it has to do any automatic closing of files when they go out of scope or you unwind frames with open files. One of the few places with platform-specific code is doing the atomic accesses on that list. The code is thread-safe as well. They are logically the same, but use somewhat different algorithms due to how they use specific instructions to update/manipulate the list.
Also during that timeframe, I was probably porting to Itanium and made some structural changes for the port...
So I'm a little surprised by the difference you saw, but not totally shocked by it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-03-2014 12:22 PM
03-03-2014 12:22 PM
Re: Page file quota exhaustion observed on Integrity but not on Alpha.
>The Pascal RTL keeps an internal list of all open files. ... The code is thread-safe as well.
I couldn't implement procedure scoped files when I implemented threading in Pascal/iX. Each stack was protected from the other threads due to the kernel design. But it worked fine in Pascal/UX.
Looking back over the decades, I suppose I could have used a thread specific linked list to handle that but there was no hardware TLS. Anyway after all that work, I'm not sure anyone ever used threading in those two PA-RISC Pascals.
Especially since all I/O would need to have explicit locking.