This application claims the benefit of U.S. Provisional Patent Application 61/974,475, filed Apr. 3, 2014, whose disclosure is incorporated herein by reference.
The present invention relates generally to computing systems, and particularly to methods and systems for memory management in computing systems.
An embodiment of the present invention that is described herein provides a method including, in a computing system that includes one or more compute nodes that run clients, defining memory chunks, each memory chunk including multiple memory pages accessed by a respective client. Respective similarity-preserving signatures are computed for one or more of the memory chunks. Based on the similarity-preserving signatures, an identification is made that first and second memory chunks differ in content in no more than a predefined number of memory pages with at least a predefined likelihood. Efficiency of access to the identified first and second memory chunks is improved.
In some embodiments, computing a similarity-preserving signature for a memory chunk includes computing a set of page signatures over the respective memory pages of the memory chunk. Identifying that the first and second memory chunks differ in content in no more than a predefined number of memory pages with at least the predefined likelihood may include identifying that the similarity-preserving signatures of the first and second memory chunks differ in no more than a given number of page signatures.
In some embodiments, improving the efficiency of access includes finding in the first and second memory chunks respective first and second memory pages that have identical content, and deduplicating the first and second memory pages. Finding the first and second memory pages that have the identical content may include comparing respective first and second hash values computed over the first and second memory pages.
In an embodiment, improving the efficiency of access includes placing first and second clients, which respectively access the first and second memory chunks, on a same compute node. In an alternative embodiment, improving the efficiency of access includes placing first and second clients, which respectively access the first and second memory chunks, on first and second compute nodes that are topologically adjacent to one another in the computing system.
In another embodiment, improving the efficiency of access includes placing the first and second memory chunks on a same compute node or on first and second compute nodes that are topologically adjacent to one another in the computing system. In yet another embodiment, defining the memory chunks includes classifying the memory pages into active and inactive memory pages, and including in the memory chunks only the inactive memory pages.
There is additionally provided, in accordance with an embodiment of the present invention, a computing system including one or more compute nodes that include respective memories and respective processors. The processors are configured to run clients that access memory pages stored in the memories, to define memory chunks, each memory chunk including multiple memory pages accessed by a respective client, to compute respective similarity-preserving signatures for one or more of the memory chunks, to identify, based on the similarity-preserving signatures, that first and second memory chunks differ in content in no more than a predefined number of memory pages with at least a predefined likelihood, and to improve efficiency of access to the identified first and second memory chunks.
There is also provided, in accordance with an embodiment of the present invention, a computer software product, the product including a tangible non-transitory computer-readable medium in which program instructions are stored, which instructions, when read by one or more processors of respective compute nodes, cause the processors to run clients that access memory pages stored in memories of the compute nodes, to define memory chunks, each memory chunk including multiple memory pages accessed by a respective client, to compute respective similarity-preserving signatures for one or more of the memory chunks, to identify, based on the similarity-preserving signatures, that first and second memory chunks differ in content in no more than a predefined number of memory pages with at least a predefined likelihood, and to improve efficiency of access to the identified first and second memory chunks.
The present invention will be more fully understood from the following detailed description of the embodiments thereof, taken together with the drawings in which:
Embodiments of the present invention that are described herein provide improved methods and systems for managing memory resources in computing systems. In the disclosed embodiments, a computing system comprises one or more compute nodes that run clients, e.g., applications, Virtual Machines (VMs) or operating-system processes.
The memory space is typically split into equal-size units referred to as memory pages. The clients access content stored in memory by locating the appropriate memory page or pages and the accessing the content stored therein. Clients may access memory pages stored either on the same node or on other nodes.
The system identifies situations in which different clients access groups or ranges of memory pages, referred to herein as chunks, which are similar in content to one another. For example, the system may correlate various events and identify the patterns in which clients access groups or ranges of memory pages. By proper clustering, the system is able to improve storage efficiency and overall performance. For example, the system may de-duplicate memory pages that belong to different chunks but have identical content, or relocate clients that use similar memory chunks to the same compute node or to nearby nodes.
Each memory chunk comprises a plurality of memory pages, not necessarily contiguous, used by a certain client. Memory chunks are typically regarded as similar if they likely, with at least a certain likelihood, to differ in content by no more than a predefined number of memory pages. In order to identify similar memory chunks, the system computes and stores for each memory chunk a respective chunk signature that preserves the similarity property. In one embodiment, the chunk signature comprises a list of short page signatures that are computed over the respective memory pages of the chunk. Chunks are considered similar if their chunk signatures (page-signature lists) are likely to differ by no more than a given number of page signatures.
In a typical embodiment, the chunk similarity mechanism is implemented in addition to a mechanism for identifying exact matches between memory pages having the same content. For example, the system may compute and store a respective hash value over each memory page (not to be confused with the page signature that is part of the chunk signature). In an example deduplication process, the system may first identify similar memory chunks (using the chunk signatures), and then search within the similar chunks (using the hash values) for identical memory pages to be deduplicated.
In this deduplication process, the chunk similarity mechanism is used as a fast and computationally-efficient way of identifying memory ranges that are likely to contain large numbers of duplicate memory pages. The disclosed deduplication process is highly scalable and may be performed at various levels of the system, e.g., between applications or processes of a given VM, within VMs on a given compute node, or across an entire compute-node cluster.
As such, the methods and systems described herein are especially advantageous in large-scale compute-node clusters whose total memory size is on the order of hundreds of terabytes or more. Nevertheless, the disclosed techniques are applicable in small-scale computing systems, as well.
Compute nodes 24 (referred to simply as “nodes” for brevity) typically comprise servers, but may alternatively comprise any other suitable type of compute nodes. System 20 may comprise any suitable number of nodes, either of the same type or of different types. In some of the disclosed techniques, the system may even comprise a single compute node. Nodes 24 are connected by a communication network 28, typically a Local Area Network (LAN). Network 28 may operate in accordance with any suitable network protocol, such as Ethernet or Infiniband.
Each node 24 comprises a Central Processing Unit (CPU) 44, also referred to as a processor. Depending on the type of compute node, CPU 44 may comprise multiple processing cores and/or multiple Integrated Circuits (ICs). Regardless of the specific node configuration, the processing circuitry of the node as a whole is regarded herein as the node CPU. Each node 24 further comprises a memory 40, typically a volatile Random Access Memory (RAM), and a Network Interface Card (NIC) 48 for communicating with network 28. Some of nodes 24 may comprise non-volatile storage devices such as magnetic Hard Disk Drives—HDDs—or Solid State Drives—SSDs (not shown in the figure).
Typically, each node 24 runs one or more clients. In the present example, the clients comprise Virtual Machines (VMs) 32, which are assigned physical resources of the node (e.g., CPU, memory and networking resources) by a hypervisor 36. Alternatively, however, clients may comprise, for example, user applications, operating-system processes or containers, or any other suitable type of client. The description that follows refers to VMs, for the sake of clarity, but the disclosed techniques can be used in a similar manner with any other suitable types of clients.
The system and compute-node configurations shown in
In system 20, each VM accesses (e.g., reads and writes) memory pages that are stored in memory 40 of the node 24 that runs the VMs and/or in memory 40 of one or more other nodes 24. In some embodiments, system 20 runs a Node Page Manager (NPM) process that manages the memory resources of system 20, and in particular carries out the techniques described herein. The NPM process, or simply NPM for brevity, may be implemented in a distributed manner by CPUs 44 of nodes 24, by a selected CPU 44, or by some centralized management node (not shown in the figure).
In some embodiments, the NPM groups memory pages used by the VMs into memory chunks, computes for each chunk a respective similarity-preserving chunk signature, and uses the chunk signatures for improving the efficiency of accessing similar memory chunks. Each memory chunk comprises a plurality of memory pages, not necessarily contiguous, used by a certain VM 32. In one embodiment, each page is 4 KB in size and each memory chunk is 128 MB in size. Alternatively, any other suitable chunk size may be used. The chunk size need not necessarily be uniform or constant.
In some embodiments the NPM groups all the memory pages of a given VM into chunks. Alternatively, however, the NPM may group into chunks only some of the memory pages of a VM. For example, for deduplication purposes the NPM may classify the memory pages of a VM into active pages (that are accessed frequently) and inactive pages (that are accessed rarely if at all), and group into chunks only the inactive pages.
For each chunk, the NPM computes and stores a respective chunk signature. The chunk signature is also referred to as a similarity-preserving signature, because comparison between the chunk signatures of different chunks is indicative of the extent of similarity between the contents of the chunks. Typically, the NPM regards memory chunks as similar if they differ in content by no more than a predefined number of memory pages, with at least a predefined likelihood. In some embodiments the predefined likelihood is 1, i.e., the similarity is deterministic rather than statistical.
In different embodiments, the NPM may use various kinds of chunk signatures. The “similarity-preservation” property typically means that, if two chunks are similar, i.e., differ in content in no more than a predefined number of memory pages, their chunk signatures will be close to one another by at least a predefined amount with at least a predefined probability. In addition, if two chunks are dissimilar, i.e., differ in content in more than a given number of memory pages, their chunk signatures will be distant from one another by at least a given amount with at least a given probability. A good chunk signature is typically fast to compute and compare, and occupies a small amount of memory.
In one embodiment, the chunk signature comprises a list of short page signatures that are computed over the respective memory pages of the chunk. The NPM regards chunks as similar if their chunk signatures (page-signature lists) are likely to differ by no more than a given number of page signatures, and vice versa. Each page signature may comprise a short hash value computed over the respective page content.
Typically, the size of the page signature is smaller than the size of the hash values used for exact match detection of page content, because the former have less stringent accuracy requirements. The page hash values should represent the page content with very high probability, because they are used for actual deduplication decisions. The chunk signatures, on the other hand, are used for pointing the NPM to memory areas that are likely to contain a large number of duplicate pages (which will then be compared and de-duplicated using the accurate page hash values).
In an example embodiment, each page signature in the chunk signature is four bytes in size, while each page hash value is twenty bytes in size. Alternatively, however, any other suitable sizes can be used.
The NPM may compute the page signatures using any suitable computation scheme, for example using a sliding window and a rolling hash function. One possible example of a rolling hash function is the Karp-Rabin signature. Alternatively, however, any other suitable similarity-preserving hash function can be used. Example techniques are described, for example, by Martinez et al., in “State of the Art in Similarity Preserving Hashing Functions,” Proceedings of the 2014 International Conference on Security and Management, July, 2014; and by Yu et al., in “Error-Correcting Output Hashing in Fast Similarity Search,” Proceedings of the Second International Conference on Internet Multimedia Computing and Service, December, 2010, which are incorporated herein by reference.
For each VM 32, data structure 60 comprises one or more entries 62, each specifying a respective memory chunk. Each entry 62 comprises multiple page hash values 64 computed over the respective pages of the chunk, and a similarity-preserving chunk signature 68. In the present example, chunk signature 68 comprises a list of short page signatures.
Data structure 60 may be centralized or distributed over multiple nodes, depending on the implementation of the NPM process. In one embodiment, each node 24 computes page hash values 64 and chunk signature 68 for the memory pages and memory chunks used by its VMs. Each node shares this information with the cluster, so that the NPM process is able to access the entire data structure 60.
The NPM process may use the chunk signatures described herein for various management purposes. Typically, the chunk signatures are used as a fast and effective pre-screening tool that identifies memory regions that are likely to contain large numbers of duplicate memory pages.
At a similarity detection step 84, the NPM looks for memory chunks that are similar to one another, based on their respective chunk signatures 68. If similar chunks are found, the NPM proceeds to de-duplicate at least some of the memory pages in the similar chunks, at a deduplication step 88. Typically, the NPM finds duplicate memory pages, i.e., corresponding pages in the similar chunks that have identical content, using page hash values 64. When using this method, the NPM focuses its deduplication efforts on similar chunks, in which the likelihood of finding duplicate pages is high.
As noted above, the deduplication process of
At a VM checking step 94, the NPM identifies VMs that access similar memory chunks. If such VMs are found, the NPM migrates one or more of them so that, after migration, the VMs are located on the same compute node.
Locating VM that access similar memory chunks on the same node is advantageous for several reasons. For example, deduplication can be performed within the node and not between nodes. Moreover, locating more pages locally at the same node as the accessing VM reduces latency and communication overhead.
In an alternative embodiment, the NPM may not necessarily migrate the VMs (that access similar chunks) to the same node, but to nearby nodes. The term “nearby” in this context means that the nodes are topologically adjacent to one another in system 20, e.g., located less than a predefined number of network hops from one another.
In other embodiments, the NPM may migrate similar chunks to reside on the same node or at least on nearby nodes. Migration of chunks may be performed instead of or in addition to migration of VMs.
In alternative embodiments, the NPM may use the chunk signatures as a fast and memory-efficient means for producing a fingerprint or profile of the VM memory, e.g., using Bloom filters. VM memory fingerprints can be used for efficient comparison of VMs and identification of VMs that use similar content. Based on such identification, VMs can be placed and memory can be shared efficiently. VM placement based on such fingerprints can even be carried out without live VMs, by using fingerprints of previously-active VMs.
In some embodiments, the NPM may define a hierarchy, or nesting, of chunks. In such embodiments, chunks of a given size may be grouped into larger, higher-level chunks. Such a hierarchy enables the NPM to perform fast pruning of information.
Although the embodiments described herein mainly address management of volatile-memory resources, the methods and systems described herein can also be used in other applications, such as in managing persistent storage.
It will thus be appreciated that the embodiments described above are cited by way of example, and that the present invention is not limited to what has been particularly shown and described hereinabove. Rather, the scope of the present invention includes both combinations and sub-combinations of the various features described hereinabove, as well as variations and modifications thereof which would occur to persons skilled in the art upon reading the foregoing description and which are not disclosed in the prior art. Documents incorporated by reference in the present patent application are to be considered an integral part of the application except that to the extent any terms are defined in these incorporated documents in a manner that conflicts with the definitions made explicitly or implicitly in the present specification, only the definitions in the present specification should be considered.
Number | Name | Date | Kind |
---|---|---|---|
5159667 | Borrey | Oct 1992 | A |
6148377 | Carter et al. | Nov 2000 | A |
6591355 | Schuster et al. | Jul 2003 | B2 |
6823429 | Olnowich | Nov 2004 | B1 |
6880102 | Bridge | Apr 2005 | B1 |
7162476 | Belair et al. | Jan 2007 | B1 |
7421533 | Zimmer et al. | Sep 2008 | B2 |
7913046 | Kamay et al. | Mar 2011 | B2 |
8082400 | Chang et al. | Dec 2011 | B1 |
8266238 | Zimmer et al. | Sep 2012 | B2 |
8352940 | Pafumi et al. | Jan 2013 | B2 |
8544004 | Fultheim et al. | Sep 2013 | B2 |
8671445 | Wang et al. | Mar 2014 | B1 |
8782003 | Patterson | Jul 2014 | B1 |
8818951 | Muntz et al. | Aug 2014 | B1 |
8943260 | Ben-Yehuda et al. | Jan 2015 | B2 |
9183035 | Bacher et al. | Nov 2015 | B2 |
20020143868 | Challenger et al. | Oct 2002 | A1 |
20030212869 | Burkey | Nov 2003 | A1 |
20040153615 | Koning et al. | Aug 2004 | A1 |
20060053139 | Marzinski et al. | Mar 2006 | A1 |
20060059242 | Blackmore et al. | Mar 2006 | A1 |
20060059282 | Chaudhary et al. | Mar 2006 | A1 |
20060143389 | Kilian et al. | Jun 2006 | A1 |
20060155674 | Traut | Jul 2006 | A1 |
20060155946 | Ji | Jul 2006 | A1 |
20060184652 | Teodosiu | Aug 2006 | A1 |
20060248273 | Jernigan, IV et al. | Nov 2006 | A1 |
20070033375 | Sinclair | Feb 2007 | A1 |
20080294696 | Frandzel | Nov 2008 | A1 |
20090049259 | Sudhakar | Feb 2009 | A1 |
20090049271 | Schneider | Feb 2009 | A1 |
20090055447 | Sudhakar | Feb 2009 | A1 |
20090204636 | Li | Aug 2009 | A1 |
20090204718 | Lawton | Aug 2009 | A1 |
20090304271 | Takahashi | Dec 2009 | A1 |
20090307435 | Nevarez et al. | Dec 2009 | A1 |
20090307462 | Fleming et al. | Dec 2009 | A1 |
20100017625 | Johnson | Jan 2010 | A1 |
20100077013 | Clements | Mar 2010 | A1 |
20100211547 | Kamei et al. | Aug 2010 | A1 |
20100281208 | Yang | Nov 2010 | A1 |
20110055471 | Thatcher | Mar 2011 | A1 |
20110066668 | Guarraci | Mar 2011 | A1 |
20110072234 | Chinya et al. | Mar 2011 | A1 |
20110271070 | Worthington et al. | Nov 2011 | A1 |
20120005207 | Gulhane | Jan 2012 | A1 |
20120011504 | Ahmad et al. | Jan 2012 | A1 |
20120130848 | Shishido | May 2012 | A1 |
20120131259 | Baskakov | May 2012 | A1 |
20120158709 | Gaonkar | Jun 2012 | A1 |
20120192203 | Corry et al. | Jul 2012 | A1 |
20120210042 | Lim et al. | Aug 2012 | A1 |
20120233425 | Yueh | Sep 2012 | A1 |
20120272238 | Baron | Oct 2012 | A1 |
20120317331 | Broas | Dec 2012 | A1 |
20120324181 | Garthwaite et al. | Dec 2012 | A1 |
20130080408 | Cashman et al. | Mar 2013 | A1 |
20130179381 | Kawabata | Jul 2013 | A1 |
20130212345 | Nakajima | Aug 2013 | A1 |
20130249925 | Ginzburg | Sep 2013 | A1 |
20130275705 | Schenfeld et al. | Oct 2013 | A1 |
20130326109 | Kivity | Dec 2013 | A1 |
20130339568 | Corrie | Dec 2013 | A1 |
20140115252 | Yu | Apr 2014 | A1 |
20140244952 | Raj et al. | Aug 2014 | A1 |
20140280664 | Sengupta et al. | Sep 2014 | A1 |
20140365708 | Iwata et al. | Dec 2014 | A1 |
20150039838 | Tarasuk-Levin et al. | Feb 2015 | A1 |
20150089010 | Tsirkin et al. | Mar 2015 | A1 |
20150286414 | Gordon | Oct 2015 | A1 |
20170031779 | Helliker et al. | Feb 2017 | A1 |
Number | Date | Country |
---|---|---|
2009033074 | Mar 2009 | WO |
Entry |
---|
International Application # PCT/IB2015/052179 Search report dated Sep. 16, 2015. |
U.S. Appl. No. 14/333,521Office Action dated Nov. 27, 2015. |
U.S. Appl. No. 14/260,304 Office Action dated Dec. 10, 2015. |
U.S. Appl. No. 14/181,791 Office Action dated Feb. 12, 2016. |
International Application #PCT/IB2015/057658 Search Report dated Jan. 12, 2016. |
International Application #PCT/IB2015/057235 Search Report dated Dec. 29, 2015. |
Amit et al., “VSWAPPER: A Memory Swapper for Virtualized Environments”, Proceedings of the 19th International Conference on Architectural Support for Programming Languages and Operating Systems (AISPLOS'14), pp. 349-366, Salt Lake City, USA, Mar. 1-4, 2014. |
Gupta et al., “Difference Engine: Harnessing Memory Redundancy in Virtual Machines”, 8th USENIX Symposium on Operating Systems Design and Implementation, pp. 309-322, year 2010. |
Heo et al., “Memory overbooking and dynamic control of Xen virtual machines in consolidated environments”, Proceedings of the 11th IFIP/IEE International Conference on Symposium on Integrated Network Management, pp. 630-637, year 2009. |
Waldspurger., “Memory Resource Management in VMware ESX Server”, Proceedings of the 5th Symposium on Operating Systems Design and Implementation, 14 pages, Dec. 9-11, 2002. |
Wood et al., “Memory Buddies: Exploiting Page Sharing for Smart Colocation in Virtualized Data Centers”, Proceedings of the 2009 ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments, pp. 31-40, Washington, USA, Mar. 11-13, 2009. |
Gordon et al., “Ginkgo: Automated, Application-Driven Memory Overcommitment for Cloud Computing”, ASPLOS's RESoLVE workshop, 6 pages, year 2011. |
Zhao et al., “Dynamic memory balancing for virtual machines”, Proceedings of the 2009 ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments pp. 21-30, Washington, USA, Mar. 11-13, 2009. |
Hines et al., “Applications Know Best: Performance-Driven Memory Overcommit with Ginkgo”, IEEE 3rd International Conference on Cloud Computing Technology and Science, pp. 130-137, Nov. 29-Dec. 1, 2011. |
International Application #PCT/IB2015/058841 Search Report dated Feb. 28, 2016. |
VMWARE Inc., “Understanding Memory Resource Management in VMware vSphere® 5.0”, Technical Paper, 29 pages, year 2011. |
U.S. Appl. No. 14/260,304 Office Action dated May 25, 2016. |
International Application # PCT/IB2016/050396 Search Report dated Mar. 13, 2016. |
Roussev, V., “Data Fingerprinting with Similarity Digests”, Advances in Digital Forensics VI, Chapter 8, IFIP Advances in Information and Communication Technology, vol. 337, 20 pages, 2010. |
Ben-Yehuda et al, U.S. Appl. No. 14/181,791, filed Feb. 17, 2014. |
Ben-Yehuda et al, U.S. Appl. No. 14/260,304, filed Apr. 24, 2014. |
Zivan, O., U.S. Appl. No. 14/333,521, filed Jul. 17, 2014. |
Mitzenmacher et al., “The Power of Two Random Choices: Survey of Techniques and Results”, Handbook of Randomized Computing, pp. 255-312, year 2000. |
Hudzua et al., “Memory Aggregation for KVM”, 41 pages, KVM forum, Nov. 2012. |
VMware Virtualization, 8 pages, year 2014. |
Hilland et al, RDMA Protocol Verbs Specification, version 1.0, 243 pages, Apr. 2003. |
Recio et al, “Remote Direct Memory Access Protocol Specification,” RFC 5040, Network Working Group ,57 pages, Oct. 2007. |
Gordon et al, U.S. Appl. No. 14/543,920, filed Nov. 18, 2014. |
Traeger, U.S. Appl. No. 14/538,848, filed Nov. 12, 2014. |
Gordon et al, U.S. Appl. No. 14/797,201, filed Jul. 13, 2015. |
International Application # PCT/IB2014/067327 Search report dated May 20, 2015. |
International Application # PCT/IB2014/067328 Search report dated May 18, 2015. |
International Application # PCT/IB2015/050937 Search report dated Jun. 28, 2015. |
International Application # PCT/IB2015/052177Search report dated Jul. 19, 2015. |
Lazar et al., U.S. Appl. No. 14/594,188, filed Jan. 12, 2015. |
U.S. Appl. No. 14/543,920 Office Action dated Nov. 18, 2016. |
U.S. Appl. No. 14/594,188 Office Action dated Apr. 5, 2017. |
U.S. Appl. No. 14/181,791 Office Action dated Jun. 28, 2017. |
Number | Date | Country | |
---|---|---|---|
20150286442 A1 | Oct 2015 | US |