Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Ntpq.exe memory issue with windows 2019

68 views
Skip to first unread message

Sadique Urf Arbaz Sayyed

unread,
Oct 21, 2020, 6:44:05 AM10/21/20
to
We started with a brand new windows server 2019 datacenter edition and installed an infrastructure monitoring agent on it and strictly no other program. The machine had 8 GB of memory. As part of monitoring NTP offset from sync'd host we scheduled a ntpqexe. The problem started after 4-5 days, the memory utilisation had increased to significant level >80%. On analysis we found it was a gradual increase and using RAMMAP we saw every time the ntpq.exe will run it will leave behind 24k of memory in PAGE Table with 0 B in Private. Moreover this issue is specific to windows server 2019 we tried following same steps on windows server 2012 machine and it worked perfectly fine with no memory creeping issues.

Any help or pointer are appreciated

Sadique Urf Arbaz Sayyed

unread,
Oct 21, 2020, 6:45:05 AM10/21/20
to
On Wednesday, October 21, 2020 at 4:14:05 PM UTC+5:30, Sadique Urf Arbaz Sayyed wrote:
> We started with a brand new windows server 2019 datacenter edition and installed an infrastructure monitoring agent on it and strictly no other program. The machine had 8 GB of memory. As part of monitoring NTP offset from sync'd host we scheduled a ntpqexe. The problem started after 4-5 days, the memory utilisation had increased to significant level >80%. On analysis we found it was a gradual increase and using RAMMAP we saw every time the ntpq.exe will run it will leave behind 24k of memory in PAGE Table with 0 B in Private. Moreover this issue is specific to windows server 2019 we tried following same steps on windows server 2012 machine and it worked perfectly fine with no memory creeping issues.
>
> Any help or pointer are appreciated

Full problem is mentioned here https://social.technet.microsoft.com/Forums/en-US/d45ba91a-cc43-4010-9a2c-d65b1a4cc33a/windows-2019-server-ntp-increases-memory-utilisation-by-acquiring-page-table?forum=ws2019

Jakob Bohm

unread,
Oct 21, 2020, 8:49:21 AM10/21/20
to
From what you have posted above (I have not checked the MS forum) it
sounds like the leak is of "PAGE"-d memory consumption, not page tables
(also known in the NT world as hyperspace).

Question is what is actually registered as owning that page-able memory.
Maybe you have found a memory leak in the NTP server itself, maybe
something in NT 10.??.2019?? (server 2019) leaks memory every time ntpq
makes an UDP socket connection to the NTP service to query it.

There are some advanced tools for checking what owns outstanding global
(kernel) memory allocations on NT systems. However first you should
check the "commit charge" of the NTP service process, as that is a
direct measure of how much pageable virtual memory is allocated in the
user mode part of that process.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Sadique Urf Arbaz Sayyed

unread,
Oct 21, 2020, 9:16:48 AM10/21/20
to
Ok so this NT server is used by our customers but in house I do not have any server. I'm simply running ntpq.exe -nc peers 127.0.0.1, here I am not expecting the output but why is it hogging onto memory. As you pointed out ntpq uses the UDP port 123 which is by default used by Windows Time service. And this issue does not occur if I have the windows time service disabled. So my question here is why does the process hogs onto memory if I have the Windows time service running (In windows 2019 it's running by default).

Jakob Bohm

unread,
Oct 21, 2020, 10:32:33 AM10/21/20
to
ntpq.exe is designed to talk to ntpd.exe from the same source
code bundle. Microsoft's NTP service (win32time) probably
completely lacks the ability to correctly handle that query.

Sadique Urf Arbaz Sayyed

unread,
Oct 21, 2020, 10:44:14 AM10/21/20
to
Yes Correct, But John here suppose my ntpd is running on a server and from the client side (Suppose windows time service is running) I run ntpq.exe with above command I do see the issue. The process will hold the 24Kb but actually the process is not visible in Task manager or anywhere but in RamMap we see that the executed process still occupied the Page table memory. So each query fired will consume 24KB and server will eventually see the 100% memory utilisation. I even had a call with Microsoft support they confirmed that this would be the application specific issue where caching is not cleared properly. I had the similar memory issue with IPMI utils as well and they provided me with the Hotfix.

David Woolley

unread,
Oct 21, 2020, 4:45:48 PM10/21/20
to
On 21/10/2020 15:44, Sadique Urf Arbaz Sayyed wrote:
> The process will hold the 24Kb but actually the process is not visible in Task manager or anywhere but in RamMap we see that the executed process still occupied the Page table memory.

Did you mean 24KB, or is that really 3KB?

Any memory leakage that persists after the process is no longer visible
in the process table is down to the OS.

As already pointed out page table allocations are unlikely to be what
that memory is.

I'm not familiar with the details of Window NT family memory use
reporting, but the only legitimate carry over would be for cached pages.
Such pages are optimisations and don't deny memory to other processes.

Both Linux and Windows try and allocate nearly all their memory to
something. In the case of the Linux "free" command, it computes an
available figure which is much larger than the free figure, by including
memory that can safely be discarded. If there isn't an OS bug, I wonder
if you are seeing that effect.

One wild thought: is ntpq or one of its DLLs not position independent
code? I could speculate as to why Windows might keep relocated pages
around in case the code is reloaded at the same address before the page
gets reused for other reasons. However, I don't actually know if
Windows does something like that.

Uwe Klein

unread,
Oct 28, 2020, 2:01:13 PM10/28/20
to
Am 21.10.20 um 22:45 schrieb David Woolley:
> One wild thought: is ntpq or one of its DLLs not position independent
> code?  I could speculate as to why Windows might keep relocated pages
> around in case the code is reloaded at the same address before the page
> gets reused for other reasons.  However, I don't actually know if
> Windows does something like that.

That does not jibe with "creeping increase of memory taken".

If Win keeps something for reuse ... it should not grow but be reused
later again kept for ... :-)

Windows has always been a rather buggy and unrealiable OS.

Uwe


David Woolley

unread,
Oct 29, 2020, 8:24:20 AM10/29/20
to
On 28/10/2020 18:01, Uwe Klein wrote:
> That does not jibe with "creeping increase of memory taken".
>
> If Win keeps something for reuse ... it should not grow but be reused
> later again kept for ...:-)

As I said, I'm not familiar with the way that Windows shows memory
statistics, but I do know that both on Windows and Linux, people often
get confused because the OS aims only to keep a small amount of memory
free. I was assuming that memory used was total - free, rather than
reflecting that which could not be released without fatally harming a
running process.

Chris

unread,
Oct 29, 2020, 10:58:37 AM10/29/20
to
Sounds like a classic memory leak. Not familiar with ws2019, but you
need to track down what's causing it. For example, does the problem
go away if you disable ntpq.exe and is that part of the os, or third
party utility ?. Are you sure ntpq.exe terminates after execution,
or is it staying resident in memory ?...

Regards,

Chris

Sadique Urf Arbaz Sayyed

unread,
Oct 29, 2020, 11:11:45 AM10/29/20
to
Hi, Yes The issue goes away if I disable the execution of ntpq.exe, Please check the link I have shared in my earlier comment. I'm tracking the problem down and so far I have found that the issue doesn't occur if you have the windows time service disabled.
0 new messages