إضغط لتفاصيل الإعلانات



Results 1 to 9 of 9
Share
  1. #1

    Default Windows 2008 R2 SP1- First Look… Well That’s Cool

    Yesterday I got the chance to start testing Windows 2008 R2 SP1 beta on my test servers, I want to share this experience with you.
    The installation was simple and took about 20 min ( 2 Quad Core Processors and 20 GB RAM )
    After the first restart the server will restart again

    Now time for testing.. Check properties for one of my VM..and now I have new options under VM Memory
    Now.. time to start my first VM ( Windows 2008 R2 with SQL and MED-V installed )
    The VM started with 512 MB
    The OS inside the VM recognized a new driver and start trying to install driver SW for it
    The driver installation will fail .. As the VM is still using the old IC.. So I will install the new IC

    Now time for guest restart

    Now my VM is can understand the synamic memory..I started my VM and kept eye on Hyper-V Console
    Now my VM started with 918 MB of RAM.. Coz my SQL started automatically
    So I decided to do a small test.. I opened my VM and terminate my SQL process.. and guess what
    The Dynamic Memory adjusted my running RAM to 606 MB .. that is cool.
    I will start more testing on different OS with different workloads.. So stay tuned


  2. Facebook Comments - تعليقـك على الفيس بوك يسعدنا ويطور مجهوداتنـا


  3. Forum Ads:

  4. Forum Ads:

    اضفط هنا لمعرفة تفاصيل الإعلانات بالموقع


  5. Forum Ads:

    -->

  6. #2
    Join Date
    Nov 2007
    Location
    Arab world!
    Posts
    6,133
    Blog Entries
    4
    Rep Power
    10

    Default

    Thanks Mohamed, A nice share but what about the DRAM, If the machine started and after finishing the starting process and you will running the SQL and some other applications or services, did the RAM adjusted to a new higher value? or you will need to restart.

    As at VMWare you don't have the idea of DRAM but it already have another nice one named "overhead ram or processor Mhz"
    I mean you will do a static resoruces like RAM and Processing values, and all of them are a members of a pool of resources and the overhead value will be taken when the server needs more resources and there are resources available so it will be adjusted automatically and even the static RAM which you already configured may not fully utilized and other servers can use these resources when needed and sure you have the option to reserve the amount of resources to some of resources depending in the service priority to avoid any kind of servers resources battle or conflict.

    Let we see the HyperV point of view in same idea?.

    I made a vote for this share!

    Thanks.

  7. #3

    Default

    Hi Mohamed,
    Actually Dynamic RAM is kind of Over subscription not Over Commitment as VMware.. Over Commitment is not recommended or supported by Microsoft for MS application and also is not recommended by VMware. (Performance tuning best practice for ESX Server) , So as we never recommend Over Commitment for our customers in production environment ( This is a well known mistake that some consultants do ).

    Dynamic Memory is a way for the hypervisor to over-subscribe the memory resources to virtual machines, not overcommit them. It is not a way for virtual machines to use more memory than is in the box. It is essentially a way for the virtual machines to share the memory resources of the hardware in a more effective way. It is essentially allowing the Hyper-V platform to dole out resources as virtual machines require, vs. being constrained to fixed resources.

    The main thing that the enhanced dynamic memory will address is the lack of hot remove, which is a good thing. Basically, it is easy to do a hot-add, but what if you want to step it down after the need has passed? This is where the R2 features will kick in and reclaim the memory. I don't want to call dynamic memory a balloon driver, but it will automatically mark large blocks of memory as unavailable, which in turn will allow that memory be reclaimed back to the host.
    One fundamental truth to take away is that Hyper-V will never allocate more than the physical memory amount. Any disk swapping won't take place in lieu of direct memory allocation. Make no mistake: Microsoft's Hyper-V virtualization takes an important step in the right direction with the dynamic memory feature. It is not feature-for-feature on par with VMware's memory management technologies, but this increased feature set has sparked my interest.
    Last edited by mohamadoz; 09-07-2010 at 11:01 AM.

  8. Forum Ads:

  9. #4
    Join Date
    Nov 2007
    Location
    Arab world!
    Posts
    6,133
    Blog Entries
    4
    Rep Power
    10

    Default

    Thanks Mohamed, but you didn't answer my question?
    If the machine started and after finishing the starting process and you will running the SQL and some other applications or services, did the RAM adjusted to a new higher value? or you will need to restart.

    About the memory sharing i talked about, As my experience with VMware for 1 year and half there's no issues with this feature and even i see this feature a great one and smart one as it shares non used memory to support other VMs to support its overhead needs.

    Sharing Memory Across Virtual Machines
    Many ESX Server workloads present opportunities for sharing memory across virtual machines. For example, several virtual machines might be running instances of the same guest operating system, have the same applications or components loaded, or contain common data. In such cases, an ESX Server host uses a proprietary transparent page sharing technique to securely eliminate redundant copies of memory pages. With memory sharing, a workload running in virtual machines often consumes less memory than it would when running on physical machines. As a result, higher levels of overcommitment can be supported efficiently.
    You can use the Mem.ShareScanVM and Mem.ShareScanTotal advanced settings to control the rate at which the system scans memory to identify opportunities for sharing memory.
    You can also disable sharing for individual virtual machines by setting the sched.mem.pshare.enable option to FALSE (this option defaults to TRUE).
    ESX Server memory sharing runs as a background activity that scans for sharing opportunities over time. The amount of memory saved varies over time. For a fairly constant workload, the amount generally increases slowly until all sharing opportunities are exploited.

    And VMware have this feature enabled by defaults and it's a one feature that makes visualization is a cost reduction environment and smarter one as it adjust itself when need more resources.

  10. #5

    Default

    for your question I already answered that in the screen shots in the post..Memory is added and removed automatically based on workloads. About page sharing let me explain the technology in details and all concerns about.

    Page Sharing is a memory technique where the hypervisor inspects and hashes all memory in the system and stores it in a hash table. Over time, which can be hours, the hashes are compared and if identical hashes are found, a further bit by bit comparison is performed. If the pages are exactly the same, a single copy is stored and multiple VMs memory are mapped to this shared page. If any one of these virtual machines need to modify that shared page, copy on write semantics are used resulting in a new (and thus unshared) memory page.


    Page Sharing is a well understood memory technique and there are a number of factors that contribute to its efficacy such as:

    1. Large Memory Pages
    2. OS Memory Utilization & Zero Pages

    Page Sharing, TLBs, Large Memory Pages & More…


    To discuss Large Memory Page Support and its implications on Page Sharing, let’s take a step back and level set. For that, I’m going to reference an excellent article written by Alan Zeichick from AMD in 2006. While the focus of this article discusses the implications of large memory pages and java virtual machines, it also applies to machine virtualization. I’m going to reference specific sections, but if you’d like to read the full article it is here:


    http://developer.amd.com/documentati...142006111.aspx
    All x86 processors and modern 32-bit and 64-bit operating systems allocate physical and virtual memory in pages. The page table maps virtual address to physical address for each native application and "walking" it to look up address mappings takes time. To speed up that process, modern processors use the translation lookaside buffer (TLB), to cache the most recently accessed mappings between physical and virtual memory.

    Often, the physical memory assigned to an application or runtime isn't contiguous; that's because in a running operating system, the memory pages can become fragmented. But because the page table masks physical memory address from applications, apps think that they do have contiguous memory. (By analogy, think about how fragmented disk files are invisible to applications; the operating system's file system hides all of it.)

    When an application needs to read or write memory, the processor uses the page table to translate the virtual memory addresses used by the application to physical memory addresses. As mentioned above, to speed this process, the processor uses a cache system—the translation lookaside buffers. If the requested address is in the TLB cache, the processor can service the request quickly, without having to search the page table for the correct translation. If the requested address is not in the cache, the processor has to walk the page table to find the appropriate virtual-to-physical address translation before it can satisfy the request.
    The TLB's cache is important, because there are a lot of pages! In a standard 32-bit Linux, Unix, or Windows server with 4GB RAM, there would be a million 4KB small pages in the page table. That's big enough—but what about a 64-bit system with, oh, 32GB RAM? That means that there are 8 million memory 4KB pages on this system.
    Mr. Zeichick continues:
    Why is it [Large Pages] better? Let's say that your application is trying to read 1MB (1024KB) of contiguous data that hasn't been accessed recently, and thus has aged out of the TLB cache. If memory pages are 4KB in size, that means you'll need to access 256 different memory pages. That means searching and missing the cache 256 times—and then having to walk the page table 256 times. Slow, slow, slow.
    By contrast, if your page size is 2MB (2048KB), then the entire block of memory will only require that you search the page table once or twice—once if the 1MB area you're looking for is contained wholly in one page, and twice if it splits across a page boundary. After that, the TLB cache has everything you need. Fast, fast, fast.
    It gets better.

    For small pages, the TLB mechanism contains 32 entries in the L1 cache, and 512 entries in the L2 cache. Since each entry maps 4KB, you can see that together these cover a little over 2MB of virtual memory.
    For large pages, the TLB contains eight entries. Since each entry maps 2MB, the TLBs can cover 16MB of virtual memory. If your application is accessing a lot of memory, that's much more efficient. Imagine the benefits if your app is trying to read, say, 2GB of data. Wouldn't you rather it process a thousand buffed-up 2MB pages instead of half a million wimpy 4KB pages?
    Kudos, Mr. Zeichick.
    I expanded on Mr. Zeichick’s physical memory to page table entry example and created this table to further illustrate the situation with 4KB pages at varying physical memory sizes.
    Physical Memory Page Table Entries (4KB) 4 GB 1 million pages 32 GB 8 million pages 64 GB 16 million pages 96 GB 24 million pages 128 GB 32 million pages 192 GB 48 million pages 256 GB 64 million pages 384 GB 96 million pages 512 GB 128 million pages 1 TB 256 million pages


    When you consider that servers have supported 32/64 GB of memory for years now and that many industry standard servers shipping today, like the HP DL 385 G6, support up to 192 GB of memory per server today you can quickly see that the time for larger memory page support is overdue. Take a look at the recently released Nehalem EX processor. The Nehalem EX supports up to 256 GB of memory per socket. You could theoretically have a 4 socket server with 1 TB of physical memory. Do you really want to access all this memory 4k at a time?
    (Even with just 64 GB of physical memory in a server, think of this as filling up an Olympic size swimming pool with water one 8 ounce cup at a time and it just gets worse as you add and use more memory…)
    Key Points:

    • The TLB is a critical system resource that you want to use effectively and efficiently as possible as it can have significant impact on system performance.
    • The use of 4k memory pages in a 32-bit world where systems max out at 4 GB of memory has been an issue for years now and the problem is far worse in a 64-bit world with systems easily capable of tens (if not hundreds) of gigabytes of memory.
    • Using 4k memory pages on 64-bit systems with much greater memory support, drastically reduces the effectiveness of the TLB and overall system performance.

    There’s More: SLAT, NPT/RVI, EPT and Large Pages…
    One point I want to add is how Large Pages and Second Level Address Translation (SLAT) hardware coexist. With nested paging, (AMD calls this Rapid Virtualization Indexing (RVI) and/or Nested Page Tables (NPT), while Intel calls this Extended Page Tables or EPT) a page table in the hardware takes care of the translation between the guest address of a VM and the physical address, reducing overhead. With SLAT hardware, performance is generally improved about 20% across the board, and can be much higher (independent third parties have reported 100%+ performance improvements) depending on how memory intensive the workload is. In short, SLAT hardware is goodness and if you’re buying a server today as a virtualization host you want to ensure you’re purchasing servers with this capability.
    One important point that doesn’t appear to be well-known is that SLAT hardware technologies are designed and optimized with Large Memory Pages enabled. Essentially, the additional nesting of page tables makes TLB cache misses more expensive resulting in about a ~20% performance reduction if you’re using SLAT hardware with Large Memory Page Support disabled. Furthermore, that’s not including the 10-20% average performance improvement (could be more) expected by using Large Memory Pages in the first place. Potentially, we’re talking about a 40% performance delta running on SLAT hardware depending on whether Large Memory Pages are used or not.
    You may want to read those last two paragraphs again.
    In short, using Large Memory Pages is a no brainer. You definitely want to take advantage of Large Memory Pages:

    • Improved performance (on average 10-20% & can be higher)
    • More efficient TLB utilization
    • Avoid a ~20% performance hit on SLAT hardware

    HW Evolution, Large Memory Pages & the Implications on Page Sharing
    Computing hardware is in a constant state of evolution. Take networking for example. Originally, the frame size for Ethernet was 1518 bytes largely due to the fact that early networks operated at much lower speeds and with higher error rates. As networking evolved and improved (faster and with lower error rates), the 1518 byte size was recognized as a bottleneck and jumbo frames were introduced. Jumbo frames are larger, up to 9014 bytes in length, and deliver 6x more packets per payload and reduce CPU utilization by reducing the number of interrupts.
    Large Memory Pages is a similar situation where server hardware is evolving to improve the overall system scale and performance. As a byproduct of this evolution, it changes some base assumptions. Specifically, Large Memory Pages changes the fundamental assumption of small 4k memory pages to larger and more efficient 2MB memory pages. However, there are implications to changing such fundamental assumptions. While you can identify and share 4k pages relatively easily, the likelihood of sharing a 2MB page is very, very low (if not, zero). In fact, this is an area where Microsoft and VMware agree. VMware acknowledges this point and states as much.
    From VMware:
    The only problem is that when large pages is used, Page Sharing needs to find identical 2M chunks (as compared to 4K chunks when small pages is used) and the likelihood of finding this is less (unless guest writes all zeroes to 2M chunk) so ESX does not attempt collapses large pages and thats [sic] why memory savings due to TPS goes down when all the guest pages are mapped by large pages by the hypervisor.
    http://communities.vmware.com/message/1262016#1262016
    Bottom Line: Page Sharing works in a legacy 4k Memory Page world, but provides almost no benefit in a modern 2MB Memory Page world.
    As stated previously, support for Large Memory Pages is a no brainer. In fact, when designing Hyper-V Dynamic Memory, we were sure to optimize in the case where Large Memory Pages are present because we expect it will soon be standard. We are so confident in Large Memory Page support that:

    • Windows Server 2008/2008 R2 have Large Memory Pages enabled by default
    • Windows Vista/7 have Large Memory Pages enabled by default
    • Windows Server 2008 R2 Hyper-V added support for Large Memory Pages (surprise!) and is one of many new performance improvements in R2

    Memory page size is evolutionary. You can expect memory page size to grow beyond 2MB to even larger page sizes in the future. In fact, newer AMD64 processors can use 1GB pages in long mode and Intel is adding 1GB memory page support in their upcoming Westmere processors. (BTW, that’s not a typo, 1GB pages…)
    In addition to Large Page Memory, another factor impacting the efficacy of Page Sharing is OS Memory Utilization and Zero Pages.
    Page Sharing, OS Memory Utilization & Zero Pages
    One aspect of page sharing most people may not know is that the greatest benefit of page sharing comes from sharing zeroed pages. Let’s assume for a moment that I have a Windows XP system with 2GB of memory. As you can see in the screenshot below from a freshly booted system running Windows XP with no apps, the OS is using ~375MB of memory while the remaining memory ~1.8GB is unused and unfortunately wasted.

    In reality, you want the operating system to take full advantage of all the memory in the system and use it as an intelligent cache to improve system performance and responsiveness. If you’re going to buy a brand new system (I see an online ad today for a brand new quad core system with 8 GB of memory for $499) don’t you want the OS to use that memory? Of course you do. That’s why we created SuperFetch.
    SuperFetch keeps track of which applications you use most and loads this information in RAM so that programs load faster than they would if the hard disk had to be accessed every time. Windows SuperFetch prioritizes the programs you're currently using over background tasks and adapts to the way you work by tracking the programs you use most often and pre-loading these into memory. With SuperFetch, background tasks still run when the computer is idle. However, when the background task is finished, SuperFetch repopulates system memory with the data you were working with before the background task ran. Now, when you return to your desk, your programs will continue to run as efficiently as they did before you left. It is even smart enough to know what day it is in the event you use different applications more often on certain days.
    OK, so how is RAM usage affected? You may have noticed that Windows 7 tends to use a much greater percentage of system RAM than on Windows XP. It is not uncommon to view Task Manager on a Windows 7 system with several GB of RAM installed and less than 100MB of the RAM shows up as free. For instance, here is a screenshot of Task Manager from the machine I am working on now.

    As you can see, this system has 8GB of physical memory and is using 3.29 GB. I'm running Windows 7 x64 Edition, Outlook, One Note, Word, Excel, PowerPoint, Windows Live Writer, Live Photo Gallery, several instances of IE with over a dozen tabs open and other day to day tools and you can see that it shows 0 MB of free physical memory. At first glance, this would seem to be something to worry about, but once you consider the impact of SuperFetch this condition becomes less of a concern. Notice that ~5827MB is being used for cache.
    Excellent.
    Windows 7 is fully utilizing the system memory resources and intelligently caching so that I have a responsive system (fetching less from disk) with great performance and making it more likely the hard drive can spin down to save power to provide longer battery life.
    So, why am I explaining Zero Pages and SuperFetch?
    Because page sharing obtains the greatest benefit by page sharing zero pages running older operating systems and is less efficacious on modern operating systems. Like Jumbo Frame and Large Memory Pages, SuperFetch is another example of evolutionary changes in computing.
    In talking with customers who are investigating hosting virtual desktops, they told us that Windows 7 is their overwhelming choice. This was another important data point in determining how we chose to implement dynamic memory because making the assumption that an OS will have lots of zero pages around isn’t a good one today or for the future.
    Final Points on Page Sharing
    To sum up…
    Large Memory (2MB) Pages support is widely available in processors from AMD and Intel today. AMD and Intel have included support for Large Memory Pages going back many generations of x86/x64 processors. However, 32-bit systems generally didn't support generous amounts of memory (most maxed out at 4 GB which is a small fraction of what 64-bit systems support) so support for Large Memory Pages wasn't as crucial as it is now with 64-bit servers being the norm.

    • Page Sharing on systems with Large Memory Pages enabled results in almost no shared pages. While you can identify and share 4k pages relatively easily, the likelihood of sharing a 2MB page is very, very low (if not, zero). Again, this is an area where Microsoft and VMware agree.
    • Read that last bullet item again
    • Page Sharing works with small 4k memory pages. The downside to small memory pages is that they don’t efficiently use the TLB while Large Memory Pages more efficiently use the TLB and can significantly boost performance
    • Using small 4k memory pages instead of Large Memory pages reduces performance on SLAT hardware by ~20%
    • Windows Server 2008/2008 R2 have Large Memory Pages enabled by default
    • Windows Vista/7 have Large Memory Pages enabled by default
    • Windows Server 2008 R2 Hyper-V added support for Large Memory Pages and is one of the many new performance improvements in R2 (surprise!)
    • Page Sharing efficacy is decreasing (irrespective of Large Memory Pages) as modern OSes take full advantage of system memory to increase performance
    • The process of inspecting, hashing all the memory in the system, storing it in a hash table and then performing a bit-by-bit inspection can take hours. The time it takes is dependent on a number of variables such as the homogeneity of the guests, how busy the guests are, how much memory is physically in the system, if you’re load balancing VMs, etc.
    • Page sharing isn’t a particularly dynamic technique, meaning, if the hypervisor needs memory for another virtual machine immediately, page sharing isn’t the best answer. The converse is true as well. If a virtual machine frees up memory which could be used by other virtual machines, page sharing isn’t the best answer here either.

  11. Forum Ads:

  12. #6
    Join Date
    Nov 2007
    Location
    Arab world!
    Posts
    6,133
    Blog Entries
    4
    Rep Power
    10

    Default

    for your question I already answered that in the screen shots in the post..Memory is added and removed automatically based on workloads.
    In screen shots you stopped the SQL service manually and you made a restart to check the allocated memory.
    Let me ask you the question in another way.

    You have an exchange server, Oracle, or portal server.
    You have a dynamic memory is allocated already with 4 GB of RAM that's was in 7:00 AM before and your dynamic maximum memory configured is 8 GB.
    At 9 AM while all users Hits the server and accessing it you have 2000 persons who hits this server.
    is the dynamic memory will allocate MORE memory to align with the new needs?.

  13. #7

  14. #8
    Join Date
    Nov 2007
    Location
    Arab world!
    Posts
    6,133
    Blog Entries
    4
    Rep Power
    10

  15. #9
    Join Date
    Jan 2008
    Location
    Egypt
    Posts
    3,945
    Blog Entries
    1
    Rep Power
    16

Similar Threads

  1. Replies: 0
    Last Post: 24-02-2011, 10:58 AM
  2. Replies: 2
    Last Post: 18-01-2011, 05:42 PM
  3. Replies: 1
    Last Post: 23-07-2010, 09:00 PM
  4. Replies: 2
    Last Post: 04-07-2010, 12:08 AM
  5. It Happens Only in Japan....cool .....
    By hopy_braya in forum Engineers discussions
    Replies: 5
    Last Post: 12-04-2008, 11:07 PM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

أقسام المنتدى

الروابط النصية

تابع جروبنا على الفيس بوك

صفحة Egypt Engineers على الفيس بوك

تابعنا على linkedin

جروبنا على الياهو جروب