topleft
topright
Enter the Member Network Zone View the Top 10 Points Leaderboard View Members Who Are Currently Online View Latest Member Activity

Featured Members


Member Network Zone

Expert Blog Comments

IT Worker Confidence Grows
Our lives revolve around technology and this does not surprise me. Good news!
Is Your Team Working Through Lunch?
Brilliant: this should be ENFORCED in all companies struggling to be social! Great read : bookmarked...
What Makes a Great Team Member?
This is so true! Our project management team, and some other people I know fit this description pe...
Memory vs. CPU Print E-mail
Share This -
Digg
Delicious
Slashdot
Furl it!
Reddit
Spurl
Technorati
YahooMyWeb

Many articles have been written over the years about the trend of CPU vs. the trend of memory; in terms of density, speed, die size, etc.  We all agree that CPU speed has been increasing at a faster pace than DRAM access time, but what does really mean for an application running on the Grid? 

Before I start, I wanted to mentioned that the arguments made here are more focused towards shared and distributed memory applications/systems, as these types of applications tends to use or store data in remote machines and that their true memory footprint is difficult to gauge.  For instance, imagine a Grid or a shared infrastructure where a number of applications use/share that infrastructure.  If you are paying for usage, and the environment is heterogeneous, it will very difficult to create a usage model.  If your application is data intensive and thus requires lots of memory, and you run that application on a low-available memory machine, you end up using more CPU time as your application will be running for longer. 

Memory is a funny thing as it is not binary when it comes to usage.  CPU has some gray area when it comes to percentage of CPU used, but you are using the CPU or you are not.  Figuring out how much memory a process uses is difficult, as the data could be shared, not used at all, stale, or simply cached by the OS or the application for later use.  Furthermore, we don’t really know what process is accessing the memory, which is true for shared memory and distributed caching systems. 

There are tools out there that allow you to do things like measure reads/writes, memory usage per process, wait time, and other tools that allow you to make sense out of all of this data.  The problem is the fact that unless these tools are integrated into the application, proper memory usage cannot be determined for an application.   The other model is to put a cap on usage or available memory as virtualized environments tend to do.  If we undershoot our memory requirement estimate, we run into the scenario that I described earlier with paying more as your application will be running for longer.    

Ultimately, we are moving towards a pay per use model and memory will be part of this model.  For now, we have to come to terms with the fact that if we want a true model for memory usage, hooks have to be made into the application or the underlying infrastructure that tell us something about that usage. 

 




Comment on this article
RSS comments

Only registered users can write comments.
Please login or register.

 
Share This -
Digg
Delicious
Slashdot
Furl it!
Reddit
Spurl
Technorati
YahooMyWeb
< Previous   Next >




White Paper Library

Copyright © 2007-2012 CIOZones. All Rights Reserved. CIOZone is a property of PSN, Inc.