Microsoft Technology Licensing, LLC

Ajay Kalhan

Shize Xu

Pankaj Arora

Santeri Olavi Voutilainen

Vivek Ravindranath Narasayya

John Morgan Oslake

Junfeng Dong

Changsong Li

Jiaqi Liu

Arnd Christian König

Manoj A Syamala

Todd F Pfleiger

Mark Connolly Benvenuto

Hao Xia

Lu Xun

Tomas Talius

Qun Guo

Gopala Krishna Reddy Kakivaya

Lev Novik

Jason Duane Clark

Marc Todd Friedman

Andrew Eyring Kimball

Peter Alan Carlin

Willis Lang

Joachim Hammer

Cihangir Biyikoglu

Istvan Cseri

Srikumar Rangarajan

Alan D Halverson

Nikhil Teletia

Tony Petrossian

Prashant Varanasi

Pradeep Mani

Stefano Stefani

Goetz Graefe

Craig C Peeper

Michael James Zwilling

Cesar Alejandro Galindo-Legaria

Alexandre Olegovich Verbitski

Nigel Robin Ellis

Conor J Cunningham

Jose A Blakeley

Aleksandras Surna

Milind Madhukar Joshi

Jun Fang

F Soner Terek

Srikanth Avadhanam

Christian Kleinerman

Shrinivas Ashwin

Yixue Zhu

Jeffrey A East

Karthik Saligrama Ramachandra

Samuel H Smith

Tsvi M Reiter

Christian König

Tobias Joakim Bertil Ternström

Clifford T Dibble

Yi Shan

David Johns DeWitt

Nagavamsi Ponnekanti

Honggang Zhang

Harold R Berenson

Manoj Syamala

Intelligent memory brokering for multiple process instances, such as relational databases (e.g., SQL servers), reclaims memory based on value, thereby minimizing cost across instances. An exemplary solution includes: based at least on a trigger event, determining a memory profile for each of a plurality of process instances at a computing node; determining an aggregate memory profile, the aggregate memory profile indicating a memory unit cost for each of a plurality of memory units; determining a count of memory units to be reclaimed; identifying, based at least on the aggregate memory profile and the count of memory units to be reclaimed, a count of memory units to be reclaimed within each process instance so that a total cost is minimized to reclaim the determined count; and communicating, to each process instance having identified memory units to be reclaimed, a count of memory units to be reclaimed within the process instance.

Memory management for multiple process instances

Techniques for differential overbooking on a cloud database. These techniques may include determining a reservation amount of a multi-tenant resource for a first service of a based upon an overbooking characteristic of the first service, and determining that a total usage value of the multi-tenant resource by a plurality of services is greater than a threshold value. In addition, the techniques may include determining a service usage value of the multi-tenant resource by the first service, determining a first overage value of the first service based on the service usage value and the reservation amount, and performing a resource reclamation process over the multi-tenant resource based on the first overage value of the first service.

Differential overbooking in a cloud computing environment

Methods for determining cache activity and for optimizing cache reclamation are performed by systems and devices. A cache entry access is determined at an access time, and a data object of the cache entry for a current time window is identified that includes a time stamp for a previous access and a counter index. A conditional counter operation is then performed on the counter associated with the index to increment the counter when the time stamp is outside the time window or to maintain the counter when the time stamp is within the time window. A counter index that identifies another counter for a previous time window where the other counter value was incremented for the previous cache entry access causes the other counter to be decremented. A cache configuration command to reclaim, or additionally allocate space to, the cache is generated based on the values of the counters.

System and method for determining cache activity and optimizing cache reclamation

A solution is disclosed for memory management of serverless databases that includes: based at least on detecting a trigger event, determining whether memory is to be reclaimed; based at least on determining that memory is to be reclaimed, determining an amount of memory to be reclaimed; identifying memory to be reclaimed; and reclaiming the identified memory. Disclosed solutions are flexible, enabling customization of the aggressiveness and manner of memory reclamation. This permits users to specify a tailored balance point between performance and cost, for arrangements that bill users based on resource usage (e.g., memory consumed by a serverless database). In some examples, users specify a ramp-down parameter that is used to determine how much memory can be evicted in a particular reclamation event, time intervals (or another criteria) for triggering a reclamation event, and a definition for whether a cache is active.

Memory management for serverless databases

Managing databases implemented in a cloud computing environment. A method includes detecting that a database implemented in the cloud computing environment is in a state of non-use. The method further includes as a result of detecting that a database implemented in the cloud computing environment is in a state of non-use, instantiating a workload in the cloud computing environment to deactivate the database. The workload is configured to store metadata for the database and database data remotely in cloud storage such that the database can be reactivated at a later time.

Dynamic deactivation of cold database in database service

Systems and methods that restore a failed reconfiguration of nodes in a distributed environment. By analyzing reports from read/write quorums of nodes associated with a configuration, automatic recovery for data partitions can be facilitated. Moreover, a configuration manager component tracks current configurations for replication units and determines whether a reconfiguration is required (e.g., due to node failures, node recovery, replica additions/deletions, replica moves, or replica role changes, and the like.) Reconfigurations of data activated as being replicated from an old configuration to being replicated on a new configuration may be performed in a transactionally consistent manner based on dynamic quorums associated with the new configuration and the old configuration.

Quorum based transactionally consistent membership management in distributed storage

Embodiments are directed to predicting the health of a computer node using health report data and to proactively handling failures in computer network nodes. In an embodiment, a computer system monitors various health indicators for multiple nodes in a computer network. The computer system accesses stored health indicators that provide a health history for the computer network nodes. The computer system then generates a health status based on the monitored health indicators and the health history. The generated health status indicates the likelihood that the node will be healthy within a specified future time period. The computer system then leverages the generated health status to handle current or predicted failures. The computer system also presents the generated health status to a user or other entity.

Proactive failure handling in data processing systems

Systems and methods that restore failed reconfiguration of nodes in distributed systems. By analyzing reports from read/write quorums of nodes associated with a configuration, automatic recovery for data partitions can be facilitated. Moreover, a configuration manager component tracks current configurations for replication units and determines whether a reconfiguration is to be performed (e.g., due to node failures, node recovery, replica additions/deletions, replica moves, or replica role changes, and the like.) Reconfigurations of data activated as being replicated from a first configuration to a second configuration may be performed in a transactionally consistent manner based on dynamic quorums associated with the second configuration and the first configuration.

Quorum based transactionally consistent membership management in distributed systems

Managing cluster resources for a cluster. The method includes identifying a plurality of quiescence policies. Each of the quiescence policies define one or more conditions for cluster entities which when met, identify that cluster resources should be reclaimed from cluster entities by quiescing cluster entities. The method further includes, for each quiescence policy, identifying an amount of reclaimed capacity defining the amount of cluster resources that will be reclaimed by implementing the quiescence policy. The method further includes, for each quiescence policy, identifying an amount of reserve capacity defining the amount of cluster resources that should be reserved for resuming quiesced cluster entities. The method further includes; selecting a quiescence policy based on comparing the reclaimed capacities and reserve capacities for the quiescence policies. The method further includes, booking cluster resources for cluster entities on the cluster according to the selected quiescence policy.

Modeling and forecasting reserve capacity for overbooked clusters

Defragmenting a cluster service to service additional capacity requests on the service. A method includes determining an amount of server resources needed for an additional deployment reservation request for a new deployment or increasing reservation of resources of an existing deployment. The method further includes determining a server that currently does not have capacity to service the additional deployment reservation request. The method further includes determining how resources on the server can be freed up by moving other replicas of other deployments on the server to other servers to allow the server to service the additional deployment reservation request.

Defragmenting clusters with reserved resources

Embodiments of the invention dynamically vary the number of replicas based on certain conditions to protect users from data loss. The size of the database is one condition that can be used to determine the number of replicas required. A database system may create three replicas. When the database size exceeds a first threshold, a fourth replica may be created. The fourth replica is maintained as long as the database size is above a second threshold that is smaller than the first threshold. However, when the database shrinks below the second threshold, then the fourth replica is deleted. Using two different thresholds in this manner prevents the system from frequently cycling between three and four replicas.

Dynamically varying the number of database replicas

Embodiments are directed to predicting the health of a computer node using health report data and to proactively handling failures in computer network nodes. In an embodiment, a computer system monitors various health indicators for multiple nodes in a computer network. The computer system accesses stored health indicators that provide a health history for the computer network nodes. The computer system then generates a health status based on the monitored health factors and the health history. The generated health status indicates the likelihood that the node will be healthy within a specified future time period. The computer system then leverages the generated health status to handle current or predicted failures. The computer system also presents the generated health status to a user or other entity.

Growing community of inventors

Redmond, WA, United States of America

Ajay Kalhan