TM1 and hard page faults

[TrevorGoss]

Hello to all,

Our business recently bought DynaTrace (http://www.dynatrace.com/en/) which is a host performance monitoring and host diagnostic tool. For our TM1 Production server we monitor Disk Space and performance (all drives), memory, hard page faults, network utilisation and CPU usage.

DynaTrace also alerts us if thresholds are met, such as high CPU usage, low memory or low disk space.

We keep getting alerts telling us that we have had over 20 hard page faults per second, for our TM1 production tool, at least once a day. We get these alerts even though we are not low on RAM, we still have 20/25 Gb of free space.

It is my understanding that a server will start paging, if it is low on RAM and it needs to write to disk and this is when page faults will occur so we are confused as to why we are getting a large amount of hard page faults when we are not low on RAM.

My questions is, does TM1 contribute to a server gaining more hard page faults? Since it is an in memory application. Our server has windows as its OS, does this make any difference?

Thanks.

Trevor.

[tomok]

it is a misconception that just because TM1 is an in-memory system that the only time it interacts with the paging file is when it runs out of memory. Even though it may not be storing anything in the paging file, TM1 still interacts with it, I assume to keep it "managed" or whatever so that if it needs to use it everything is OK. I don't know the specifics. You can prove this by having no paging file at all, or one really small. TM1 will crash in very short order, regardless of how much RAM you have.

[jim wood]

How TM1 interacts with memory is also driven by the OS. The OS constantly interacts with the page file. The OS will try to allocate resources to all processes requiring memory. It has to try and make sure the system never runs out of memory. As Tomok mentioned TM1 does hit the page file even when there's lots of memory available. This for the most part has nothing to do with TM1. It's just another process trying to gain resources from the OS.

[jim wood]

One option you might want to look at is moving to a Unix server. You can manage and allocate resource much better in a Unix environment. I'm not up to date with Linux but it also may offer better resource management as it's a UNIX derivative,

Jim.

[BrianL]

The page file and all associated paging operations are completely managed by the operating system.

That being said, there is a tm1s.cfg parameter (LockPagesInMemory) you can use to get TM1 to instruct windows to never page out memory to disk. This option can make out of memory crashes more likely since the OS now has less flexibility in managing memory.


http://www-01.ibm.com/support/docview.w ... wg27024038
and
http://www-01.ibm.com/support/docview.w ... wg21413242

[David Usherwood]

Be good to hear to what extent these 'hard page faults' of which you speak are actually a problem. I'll admit they sound alarming

[TrevorGoss]

Thank you all for your replies.

it is a misconception that just because TM1 is an in-memory system that the only time it interacts with the paging file is when it runs out of memory. Even though it may not be storing anything in the paging file, TM1 still interacts with it, I assume to keep it "managed" or whatever so that if it needs to use it everything is OK. I don't know the specifics. You can prove this by having no paging file at all, or one really small. TM1 will crash in very short order, regardless of how much RAM you have.

I will give that a go, removing the ability for the server to page, thanks.

How TM1 interacts with memory is also driven by the OS. The OS constantly interacts with the page file. The OS will try to allocate resources to all processes requiring memory. It has to try and make sure the system never runs out of memory. As Tomok mentioned TM1 does hit the page file even when there's lots of memory available. This for the most part has nothing to do with TM1. It's just another process trying to gain resources from the OS.

One option you might want to look at is moving to a Unix server. You can manage and allocate resource much better in a Unix environment. I'm not up to date with Linux but it also may offer better resource management as it's a UNIX derivative,
Jim.

We are on Windows Server 2008 R2 at the moment, which demonstrates how hard it can be for us to move OS, for the time being we are stuck with Windows, but I take your point about Unix.

The page file and all associated paging operations are completely managed by the operating system.

That being said, there is a tm1s.cfg parameter (LockPagesInMemory) you can use to get TM1 to instruct windows to never page out memory to disk. This option can make out of memory crashes more likely since the OS now has less flexibility in managing memory.


http://www-01.ibm.com/support/docview.w ... wg27024038
and
http://www-01.ibm.com/support/docview.w ... wg21413242

I am familiar with this parameter, but I will steer clear of it as the statement "this option can make out of memory crashes more likely" is enough for me. This is pretty significant, from the first source

When a TM1 server running on a Windows 64-bit operating system is idle for a period of time, physical memory taken up by the TM1 server is paged out to disk. This paging to disk happens even if there are no other processes contending for the memory pages. Essentially, Windows leaves the memory pages vacant and available. This is a function of the Windows 64-bit operating system and not TM1.

This confirms Tomok's post.

Be good to hear to what extent these 'hard page faults' of which you speak are actually a problem. I'll admit they sound alarming

The main reason why I thought they might be a problem is because DynaTrace felt it was one of the important bits of information that needed to be monitored, it has given us a setting to set email alerts when we get a certain number of page faults. To be honest, before DynaTrace these were not really a problem as we rarely run out of RAM.

Thank you all for your responses, I will try cancel paging (on a dev server of course) and see what happens, I think it is best if I quickly illustrate what is a "hard" page fault, compared to a "soft" page fault.

Hard page fault: Hard page faults occur when the page is not located in physical memory or a memory-mapped file created by the process.

Soft page fault: a soft page fault occurs when the page is resident elsewhere in memory.

Source: https://blogs.technet.microsoft.com/ask ... ge-faults/

Thank you to all.