Home Page for the TeradataForum
 

Archives of the TeradataForum

Message Posted: Thu, 15 Jan 2004 @ 22:14:41 GMT


     
  <Prev Next>   <<First <Prev
Next>
Last>>
 


Subj:   Re: V2R5 Memory Usage...
 
From:   John Hall

From the Resusage manual:

"Number of failures performing memory allocations and size-increasing memory alters for vproc memory types as well as node memory types."


It's been a long time, but my understanding of this is that a task requested a unit of memory from the memory management subsystem. Because of the amount of work already in progress, there was insufficient physical memory available to satisfy that request. As a result, some of the least-recently-used (LRU) work was swapped-out to disk, thereby making room for the new task.

MEMFAILS reflects the number of memory management requests that failed - not the amount of memory that was requested or swapped-out.

MEMFAILS, along with related columns, gives information that helps to evaluate the performance and problems between logical (or virtual) and physical memory. To understand the significance of MEMFAILS, you need to understand what's happening at the time the measurement was taken.

To contrive an example:

Keep in mind, that for performance reasons, the machine tries to keep as much work as possible in memory. The more often that this is true, the better the performance.

Let's say that there is a single task running which has created some very large buffers. Since there is no other work, all of its buffers can be kept in physical memory. You can say that virtual memory and physical memory are the same thing at this point.

A new task comes along which generates small units-of-work. Each of those units-of-work will request some memory for itself. Since the old task has filled physical memory, each memory request by the new task will cause a MEMFAIL - memory was requested, but could not be immediately satisfied because physical memory was full.

Let's say that we have 2Gb of physical memory and each of the units-of-work is requesting 32Kb each (let's call that 32Kb a Segment).

The request for a Segment will cause a portion of the LRU physical memory belonging to the old task to be written to disk. It still belongs to the virtual memory of the old task, it's just located on disk after the swap-out. The freed-up space is then allocated to the new task.

When the old task requires the data contained in the swapped-out Segment, the memory management system will identify other LRU segments that can be swapped-out to disk and then it reloads the needed segment for the old task.

All that MEMFAILS indicates is that some typical memory management overhead has taken place. No big deal - it's not even very interesting.

What about the situation in which a lot of small tasks keep making small requests for memory. This starts to become a problem because so much time is being spent on managing memory. What's even worst is the case where those small tasks actually need a fairly large amount of memory and instead of asking for the full amount in one request, it keeps requesting small units of memory until it has satisfied its needs.

Let's say the task needs 20 segments, but only requests one segment at a time. In that case, you'll probably end-up with 20 MEMFAILS per task. Now consider the situation where you might have hundreds (or thousands) of these tasks requesting undersized chunks of memory - your machine will quickly bottleneck on the memory management system.

So the bottom line is that a small value for MEMFAILS is typical and really doesn't indicate a problem. As the value goes up, the performance of the overall machine degrades. But even then, I don't think that MEMFAILS can be interpreted in isolation - you really need to know what else is happening with the system.

In a system that is spending a lot of time swapping memory, increasing the size of physical memory should improve performance. How much better? Aw, that's the question - but it's probably proportional to your budget.



     
  <Prev Next>   <<First <Prev
Next>
Last>>
 
 
 
 
 
 
 
 
 
  
  Top Home Privacy Feedback  
 
 
Copyright for the TeradataForum (TDATA-L), Manta BlueSky    
Copyright 2016 - All Rights Reserved    
Last Modified: 27 Dec 2016