Patent classifications
G06F2209/504
REDISTRIBUTING UPDATE RESOURCES DURING UPDATE CAMPAIGNS
Disclosed are various embodiments for the controlling the amount of active updates that can occur during a given time on devices that are associated with tenants (e.g., organizations) and subtenants (e.g., sub-organizations) in a multi-tenant environment. In particular, each tenant and subtenant is assigned throttle corresponding to different update parameters (e.g., an amount of devices executing an active update, an amount of data to be downloaded during a campaign, a time for completing the update campaign, etc.). When an update campaign is established, the update campaign can define the different devices that are to be updated. In some situations, the number of active updates required may exceed the allotted resources for a given subtenant. When a subtenant requires additional resources than what is assigned to complete the update, the subtenant can borrow resources defined by the update parameters from a subtenant peer that has a surplus.
METHOD FOR ENHANCING THROUGHPUT IN BLOCKCHAIN NETWORK
In a hyper ledger-based blockchain network system, in order to adjust latency and throughput required by a specific hyper ledger-based network, by using a block size, an endorsement policy, the number of channels, and the number of vCPUs allocation, the latency and the throughput desired by a user are maintained.
System and method of a shared memory allocator
A method and apparatus of a network device that allocates a shared memory buffer for an object is described. In an exemplary embodiment, the network device receives an allocation request for the shared memory buffer for the object. In addition, the network device allocates the shared memory buffer from shared memory of a network device, where the shared memory buffer is accessible by a writer and a plurality of readers. The network device further returns a writer pointer to the writer, where the writer pointer references a base address of the shared memory buffer. Furthermore, the network device stores the object in the shared memory buffer, wherein the writer accesses the shared memory using the writer pointer. The network device further shares the writer pointer with at least a first reader of the plurality of readers. The network device additionally translates the base address of the shared memory buffer to a reader pointer, where the reader pointer is expressed in a memory space of the first reader.
MULTI-TENANT RESOURCE ALLOCATION USING CONTROL GROUPS IN CLOUD-BASED COMPUTING ENVIRONMENT
Some embodiments may be associated with a cloud-based computing environment. A multi-tenant master process platform, associated with a RDBMS, may create a logical database for a tenant on a physical instance of the cloud-based computing environment. A connection to the logical database may be received from a client user associated with the tenant, and a process for the connection may be created. A process identification number created for the process may then be captured along with the database identifier for the tenant using an in-kernel virtual machine program. The system may send the process identification number and the database identifier to a user space program. The user space program creates a control group with the name of the database identifier and places the process identification number into the control group. The control group can then be limited with respect to a maximum amount of resources (memory, CPU etc.).
System and method for autonomous and dynamic resource allocation in storage systems
Embodiments are described for an autonomously and dynamically allocating resources in a distributed network based on forecasted a-priori CPU resource utilization, rather than a manual throttle setting. A multivariate (CPU idle %, disk I/O, network and memory) rather than single variable approach for Probabilistic Weighted Fuzzy Time Series (PWFTS) is used for forecasting compute resources. The dynamic throttling is combined with an adaptive compute change rate detection and correction. A single spike detection and removal mechanism is used to prevent the application of too many frequent throttling changes. Such a method can be implemented for several use cases including, but not limited to: cloud data migration, replication to a storage server, system upgrades, bandwidth throttling in storage networks, and garbage collection.
Managing resource allocation in hierarchical quota system
A method for managing resource allocation in a hierarchical quota system, comprising n layers of quota nodes, n being a positive integer greater than 1, and comprises at a first quota node in an i.sup.th layer of quota nodes, in response to receiving a resource allocation request from a user, determining whether an amount of requested resources exceeds a first quota; if the amount of requested resources does not exceed the first quota, determining whether the first node holds a quota delegation for the first quota node; if the first node holds the quota delegation, determining whether the amount of requested resources exceeds a second quota specified by the quota delegation for the first quota node; if the amount of requested resources does not exceed the second quota, allocating the requested resources to the user.
System and method for throttling service requests having non-uniform workloads
A system that provides services to clients may receive and service requests, various ones of which may require different amounts of work. The system may determine whether it is operating in an overloaded or underloaded state based on a current work throughput rate, a target work throughput rate, a maximum request rate, or an actual request rate, and may dynamically adjust the maximum request rate in response. For example, if the maximum request rate is being exceeded, the maximum request rate may be raised or lowered, dependent on the current work throughput rate. If the target or committed work throughput rate is being exceeded, but the maximum request rate is not being exceeded, a lower maximum request rate may be proposed. Adjustments to the maximum request rate may be made using multiple incremental adjustments. Service request tokens may be added to a leaky token bucket at the maximum request rate.
REAL TIME MULTI-TENANT WORKLOAD TRACKING AND AUTO THROTTLING
Technologies are disclosed for real-time workload tracking and throttling within a multi-tenant service. Multi-tenant services receive requests from computing devices associated with different tenants. While processing requests, the multi-tenant service itself sends requests to an underlying resource, such as a database. Requests from computing device associated with an overactive tenant may cause the multi-tenant service to overwhelm the underlying resource. The overwhelmed underlying resource may not know which tenant a request received by the underlying resource is associated with, and so the underlying resource is unable to only throttle requests originating from computing devices associated with the overactive tenant. Instead, the underlying resource throttles all requests from the multi-tenant service. To avoid this result, the multi-tenant service tracks utilization of the underling resource associated with each tenant, and throttles requests received from overactive tenants before the underlying resource becomes overwhelmed and throttles all requests from the multi-tenant service.
Resource allocation using distributed segment processing credits
Systems and methods for allocating resources are disclosed. Resources as processing time, writes or reads are allocated. Credits are issued to the clients in a manner that ensure the system is operating in a safe allocation state. The credits can be used not only to allocate resources but also to throttle clients where necessary. Credits can be granted fully, partially, and in a number greater than requested. Zero or negative credits can also be issued to throttle clients. Segment credits are associated with identifying unique fingerprints or segments and may be allocated by determining how many credits a CPU/cores can support. This maximum number may be divided amongst clients connected with the server.
BLOCK STORAGE VIRTUALIZATION MANAGER
Described are techniques for implementing a block storage virtualization (BSV) manager. The techniques including a method comprising associating a Block Storage Virtualization (BSV) manager with a virtual machine (VM) having virtually provisioned block storage resources. The method further comprises aggregating, by the BSV manager, the virtually provisioned block storage resources into a virtual address space having a maximum capacity and an allocated capacity, wherein the allocated capacity is less than the maximum capacity. The method further comprises determining, by the BSV manager, that free space in the allocated capacity is less than a provisioning threshold. The method further comprises, in response to determining that the free space in the allocated capacity is less than the provisioning threshold, procuring, by the BSV manager, a predetermined amount of additional block storage resources for the VM.