Operating System - OpenVMS
1748019 Members
4394 Online
108757 Solutions
New Discussion юеВ

Re: PGFLQUOTA leak with FTP

 
SOLVED
Go to solution
Hari Shankar S
Advisor

PGFLQUOTA leak with FTP

It has been found that the PGFLQUOTA of FTP never decreases. When new FTP connections are established the PGFLQUOTA is consumed but when the connections are closed the PGFLQUOTA is not decreased. As times passes, more and more writeable pages are gradually
added to the end of p0 space. If the system is left on long enough, it could eventually run out of quota.

Does any one have any idea why this problem occurs?
25 REPLIES 25
Hoff
Honored Contributor

Re: PGFLQUOTA leak with FTP

Looks to be a bug in the code. A leak. There are various reasons why this can arise within an application, but there's little that can be done to resolve this case without access to the source code. (Eons ago, there was a bug within sys$creprc that caused a four-page leak, for instance.)

This reply assumes that this is the TCP/IP Services product (there are several IP stacks around) and the current version and current ECO, and that this arises on a recent or current version of OpenVMS Alpha or OpenVMS I64, and that this is involving the ftp server and not the ftp client.

Assuming this is the current version and ECO of the TCP/IP Services product, log a problem report with HP with a reproducer.

In the short term, you could periodically restart the FTP server; that should clear this up. (If you have the source code to ftp available, that's another discussion entirely.)
Wim Van den Wyngaert
Honored Contributor

Re: PGFLQUOTA leak with FTP

Don't get it. FTP client and server are both alive only during a session. Do you mean that you keep the session alive for a long time ?

Wim
Wim
Hari Shankar S
Advisor

Re: PGFLQUOTA leak with FTP

The FTP server is an OpenVMS system and the client may be any other. The OVMS system is kept on without restarting the system or the service. The clients may come and go as they like. Even though the FTP connection is closed, the PGFLQUOTA is not decreased.
Hari Shankar S
Advisor

Re: PGFLQUOTA leak with FTP

Hoff,
Can you please explain to me what all could be reasons for the memory leak?
Volker Halle
Honored Contributor

Re: PGFLQUOTA leak with FTP

Hari,

which process are your referring to ? TCPIP$FTP_1 ? Which version and architecture of OpenVMS and which version of TCPIP ?

$ UCX SHOW VERS ! should give info

For each FTP client connection to the OpenVMS system, a new network process will be created named TCPIP$FTPCnnnnn. This process terminates, if the FTP connection is terminated by the client. Only the FTP Server TCPIP$FTP_1 process stays around.

If there would be a 'memory' leak affecting PGFLQUOTA, this could only exist in the FTP server process.

What symptoms of this leak are you seeing ?
Are you using SHOW PROC/QUOTA/ID=ypid-of-FTP-server> ?

The Paging file quota: value shown is the remaining page file quota for this process. If some more is allocated for each FTP connection and not de-allocated or even re-used, then you would see pagefile quota decreasing over time.

Volker.
Hoff
Honored Contributor

Re: PGFLQUOTA leak with FTP

>Can you please explain to me what all could be reasons for the memory leak?

Resolving a leak requires source code access, or a whole lot more time and effort in reverse engineering this than this particular bug is probably worth. Do you have source code access to the particular ftp daemon here? (If you don't have that source code, there's not that much that can be done here short of a very substantial investment in software engineering. Other than forwarding this problem report over to HP support with a reproducer.)

As for the trigger, this isn't a small topic area. There are a vast number of triggers here. I have presented day-long courses on advanced programming tips and techniques and tools specifically for OpenVMS tailored for various sites. And that time only begins to cover some of what's involved here. And which introduces how to try to avoid these leaks (and a close cousin to leaks, the heap corruption), and how to more quickly find them when they arise. For an overview of some of what has been in the training in this specific topic area, see http://64.223.189.234/node/401 and some of the articles referenced there.

Most any dynamically-allocated data structure can be lost during processing, and there can be fragmentation of the heap that leads to increased virtual memory use. The sys$creprc flaw mentioned earlier leaked pagefile; the system service was not releasing all of what it had consumed. There are many other operations where the application must perform some sort of tracking and release; neither OpenVMS nor C do not offer any form of garbage collection, though there are ways to incorporate some techniques that avoid the need to track memory.

John Gillings
Honored Contributor

Re: PGFLQUOTA leak with FTP

Hari,

In general the PAGFILCNT (=remaining PGFLQUOTA) of a process does not increase. Although it's possible to delete virtual memory, it tends to be rarely done, because there's very little benefit, and the conditions under which you can do it are fairly strict and difficult to achieve. For most processes VIRTPEAK is monotonic increasing and PAGFILCNT is therefore monotonic decreasing.

A long lived process may continue to grow even if it doesn't have a leak. It just means its work load is gradually expanding. Hopefully the rate of growth diminishes over time.

Monitor the process long term and look at the shape of the growth curve. If it's linear, you probably are dealing with a leak (but if you don't have access to the source code, there's little you can do about it). If the growth is asymptotic, there's probably natural and benign.

>If the system is left on long enough,
>it could eventually run out of quota.

Possibly true, but if it hasn't happened yet, and the projected point at which it will happen is a long way into the future, it's not something you should be too concerned about.
A crucible of informative mistakes
Hari Shankar S
Advisor

Re: PGFLQUOTA leak with FTP

Volker,

>which process are your referring to ? TCPIP$FTP_1 ?
Yes, I am referring to the TCPIP$FTP_1 process.

>Which version and architecture of OpenVMS and which version of TCPIP ?
OpenVMS is Alpha V8.3-1h1 and TCP/IP is V5.6 Eco3 with the latest patches installed.

>What symptoms of this leak are you seeing ?
If there is a lot of incoming FTP with my system , %PGFLQUOTA_CNT can grow, I mean, the quota is partially consumed. When all those FTPs (open channels) with my system finish, the channels are released , the process TCPIP$FTPC000XXX DIES ,AND ONLY TWO CHANNELS BG'S, OPENED AT TCPIP$FTP_1. BUT PAGFILCNT of TCPIP$FTP_1 is not decreased

>Are you using SHOW PROC/QUOTA/ID=ypid-of-FTP-server> ?
The information about the leak is gotten from SDA formatting the JIB (Job Information Block) of the TCPIP$FTP_1 process and displaying with F$GETJPI and PAGFILCNT
Hari Shankar S
Advisor

Re: PGFLQUOTA leak with FTP

John,

>Although it's possible to delete virtual memory, it tends to be rarely done
How is this done?

>Monitor the process long term and look at the shape of the growth curve.
I can see that each 48 or 54 minutes the consumption of PGFLQUOTA grows. But there is not an explanation for that , becase the number of FTP session DON'T GROW.

>but if it hasn't happened yet, and the projected point at which it will happen is a >long way into the future
It has happened.