CN107579926B - QoS setting method of Ceph cloud storage system based on token bucket algorithm - Google Patents
QoS setting method of Ceph cloud storage system based on token bucket algorithm Download PDFInfo
- Publication number
- CN107579926B CN107579926B CN201710986526.5A CN201710986526A CN107579926B CN 107579926 B CN107579926 B CN 107579926B CN 201710986526 A CN201710986526 A CN 201710986526A CN 107579926 B CN107579926 B CN 107579926B
- Authority
- CN
- China
- Prior art keywords
- request
- token bucket
- tokens
- sub
- queue
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
The invention discloses a QoS setting method of a Ceph cloud storage system based on a token bucket algorithm, wherein the Ceph cloud storage system comprises a plurality of clients and a server which is in communication connection with the clients, the server is provided with a total token bucket module, the total token bucket module comprises a plurality of sub token bucket modules, and each client and each sub token bucket module are in one-to-one correspondence; meanwhile, the capacity of processing the burst is provided, the depth of the bucket, namely the maximum token number kept by the sub-token bucket module, can process the large IO which comes suddenly, and the problems of jitter and the like are avoided.
Description
Technical Field
The invention belongs to the field of distributed storage, and particularly relates to a QoS (quality of service) setting method of a Ceph cloud storage system based on a token bucket algorithm.
Background
Cloud storage is an emerging concept extending and developing from a cloud computing concept, and refers to a system which provides data storage and service access functions to the outside through cooperation of a large number of various storage devices of different types in networks such as cluster application, network technology or distributed file systems through aggregation of application software, so that the safety of data is guaranteed, and the storage space is saved.
Qos (quality of service) is a control mechanism that provides different priorities for different users or different data streams, or ensures the performance of the data streams to reach a certain level according to the requirements of the program. QoS refers to the probability that a network satisfies a given service contract in the field of packet-switched networks; in the field of telephone service, the measurement of indexes such as line noise, sound, proper volume level and the like is referred to; in the storage domain, the control is mainly performed by IOPS (Input/Output Operations Per Second) for storage access. Providing QoS guarantees resource utilization is important in various areas of expertise.
Ceph eliminates the dependence on a single central node, and really realizes a distributed storage system without a central structure, which cannot be achieved by other distributed storage systems. Ceph, the most popular open source distributed storage system at present, has become one of the open source storage schemes of openstack, which has been incorporated into a linux kernel. However, QoS is important in storage, and due to the resource contention, many workloads compete for IOPS, and it is necessary to provide QoS techniques to ensure that bandwidth of critical tasks is available. Especially in the case of using the SSD, with the steady increase of the SSD capacity, the competition of the SSD by various workloads becomes a normal state; and the SSD will be maintained automatically, and this daily maintenance will affect performance, at this time, the QoS may prioritize the storage bandwidth, so that the critical task can obtain the required bandwidth even when the resource competition is severe, otherwise, the critical task may not compete enough bandwidth and execute slowly with other tasks. The current updated version of Ceph introduced an optimized architecture for SSDs by bluestore et al, but Ceph currently has no support for QoS.
The token bucket (token bucket) algorithm is one of the most common algorithms for implementing traffic shaping and rate limiting in packet-switched computer networks, and it deals with incoming packets in a manner of generating tokens at a fixed rate, and decides the issuing or discarding of packets according to the number of remaining tokens. The token bucket algorithm can be used in network technology, and still has great application potential in other fields such as storage and the like.
Disclosure of Invention
The technical problem to be solved by the invention is to provide a QoS setting method of a Ceph cloud storage system based on a token bucket algorithm aiming at the defects of the prior art, the QoS setting method of the Ceph cloud storage system based on the token bucket algorithm provides limit limitation in QoS, when a plurality of clients perform IO operation, the maximum IOPS can be limited, and the phenomenon that some clients occupy a large amount of IOPS and other clients are hungry can be avoided; meanwhile, the capacity of processing the burst is provided, the depth of the bucket, namely the maximum token number kept by the sub-token bucket module, can process the large IO which comes suddenly, and the problems of jitter and the like are avoided.
In order to achieve the technical purpose, the technical scheme adopted by the invention is as follows:
a QoS setting method of a Ceph cloud storage system based on a token bucket algorithm is disclosed, the Ceph cloud storage system comprises a plurality of clients and a server side in communication connection with the clients, the server side is provided with a total token bucket module, the total token bucket module comprises a plurality of sub-token bucket modules, each client and each sub-token bucket module are in one-to-one correspondence, and the QoS setting method comprises the following steps:
(1) set maximum and token generation speed: presetting the maximum value of the number of tokens contained in the total token bucket module and the speed of generating the tokens by the sub token bucket module;
(2) generating an IO request: the client generates an IO request, and the server stores the IO request into a corresponding IO request set queue, wherein the sub-token bucket modules and the IO request set queue are in one-to-one correspondence;
(3) obtaining a token: a sub-token bucket module in the server side continuously generates tokens according to the token generation speed and puts the tokens into the sub-token bucket module, and meanwhile, the total number of the tokens contained in all the sub-token bucket modules is not more than the maximum value of the number of the tokens contained in the total token bucket module;
(4) a queue head IO request: judging whether the IO request set queue is empty, if so, ending, otherwise, taking out the IO request at the head of the queue by the sub token bucket module according to the arrangement sequence in the IO request set queue;
(5) requesting the token: the sub token bucket module sets the number of tokens required by the IO request according to the size, the type and the token generation speed of the IO request at the head of the queue, if the number of tokens in the sub token bucket module is larger than or equal to the number of tokens required by the IO request, the same number of tokens are taken out of the sub token bucket module and the IO request is processed, and the IO request exits the IO request set queue and returns to the execution step (4); if the number of tokens in the sub token bucket module is smaller than that of tokens required by the IO request, taking out all the tokens left in the sub token bucket module, subtracting the number of tokens required by the IO request from the number of tokens left in the sub token bucket module, marking the calculated result to the IO request, updating the result to be the new number of tokens required by the IO request, putting the IO request back to the head position of the IO request set queue, and executing the next step;
(6) checking the IO request: and (3) the sub token bucket module periodically and sequentially checks whether the number of new tokens required by the IO request at the head of the queue in the IO request set queue is less than or equal to the number of tokens in the sub token bucket module, if so, the tokens with the same number as the new tokens required by the IO request at the head of the queue are taken out from the sub token bucket module and the IO request is processed, the IO request exits from the IO request set queue and returns to the execution step (4), otherwise, the sub token bucket module exits from the check.
The method for processing the IO request between each sub-token bucket module and each client operates according to the steps (1) to (6).
Further, the storing, by the server, the IO request into the corresponding IO request set queue includes:
(1) the server side sequentially stores the IO requests into an IO request set queue according to the time sequence of the IO requests sent by the client side;
(2) and the server side correspondingly adjusts the arrangement sequence of the IO requests according to the scheduling priority of each IO request in the IO request set queue.
Further, the IO request set queue includes a read operation IO request set queue and a write operation IO request set queue, where the read operation IO request set queue is used to store read operations of IO requests, and the write operation IO request set queue is used to store write operations of IO requests.
The invention has the following technical effects: the invention provides limit limitation in QoS, when a plurality of clients (users) perform IO request operation, the maximum IOPS of each client can be limited by setting the token generation rate in each sub-token bucket module, so that the phenomenon that some users occupy a large number of IOPS and other users are hungry can be avoided; meanwhile, the capacity of processing the burst is provided, the depth of the bucket, namely the maximum token number kept by the sub-token bucket module, can process a larger IO request which comes suddenly, and the problems of jitter and the like are avoided. The invention establishes the priority for different IO requests, and preferentially allocates IOPS according to the priority, so that the emergency and important tasks can obtain enough IOPS when the resource competition is severe; and maximize the utilization of the IOPS as much as possible when the resource competition is relaxed.
Drawings
FIG. 1 is a schematic structural diagram of the present invention.
Fig. 2 is a flow chart of the operation of the present invention.
Detailed Description
The following further illustrates embodiments of the invention with reference to fig. 1 and 2:
referring to fig. 1, a QoS setting method for a Ceph cloud storage system based on a token bucket algorithm provides limit requirements in QoS guarantees, and can handle certain emergencies, allowing a customer IOPS to be temporarily higher than a limit value. The Ceph cloud storage system comprises a plurality of clients and a server end in communication connection with the clients, wherein the server end is provided with a total token bucket module, the total token bucket module comprises a plurality of sub-token bucket modules, each client and each sub-token bucket module are in one-to-one correspondence, the total token bucket module is a total token bucket and comprises a plurality of small token buckets (sub-token bucket modules), the total token bucket module corresponds to each client, the sum of the token generation rates of the clients is not greater than the maximum rate of the total token bucket, and the sum of the sub-IOPS represents the total IOPS.
The sub-token bucket module corresponds to each client, and has the functions of obtaining tokens, requesting tokens, setting the maximum value (the depth of the bucket), setting the generation rate of the tokens, checking IO requests and the like.
The token acquisition is carried out according to the set token generation speed n/T, and T is unit time, so that n x (T/T) tokens are generated after T time is passed and are put into the sub-token bucket module, and the quantity of the tokens in the sub-token bucket module is ensured not to exceed the set maximum value.
When the request token is used for processing an IO request, the number of tokens required by the request token is judged according to the size, the type and the like of the IO request, then a corresponding number of tokens are tried to be taken out from the sub-token bucket module, and if the number of tokens is enough, the tokens are taken out and the IO request is processed; if the number of tokens is insufficient, all the remaining tokens are taken out and marked to the IO, and the IO continues to wait for the processing when the number of tokens is sufficient.
The maximum value is set, namely, the maximum number of tokens in the total token bucket module is set, and when the number of tokens in the total token bucket module is greater than the maximum value, the maximum value is automatically adjusted.
The token generation rate is the number of tokens added in an inner barrel in unit time, namely the value is used for providing the limit guarantee of QoS, the greater the value is, the greater the limit value is, and the greater the maximum IOPS obtained by a user is; whereas the user's IOPS is limited to some small average value.
The IO request is sequentially checked, namely, the IO requests waiting to be processed in the IO request set queue are sequentially checked, and if the request token is successful, the next IO request is processed and checked; and exiting if the failure occurs.
The IO request set queue is a queue for storing IO requests, and each time a user has a new IO request, the new IO request is added into the queue to wait for being processed.
The burst is an unexpected occurrence of a relatively large number of IOs in a short time, and the ability of the algorithm to process the burst is related to the set token generation rate v and bucket depth h, h/(M-v), where M is the maximum processing rate of the physical machine.
To sum up, the QoS setting method specifically includes: with reference to figure 2 of the drawings,
(1) set maximum and token generation speed: presetting the maximum value of the number of tokens contained in the total token bucket module and the speed of generating the tokens by the sub token bucket module;
(2) generating an IO request: the client generates an IO request, and the server stores the IO request into a corresponding IO request set queue, wherein the sub-token bucket modules and the IO request set queue are in one-to-one correspondence;
(3) obtaining a token: the sub-token bucket module in the server side continuously generates tokens according to the token generation speed and puts the tokens into the sub-token bucket module, meanwhile, the total number of the tokens contained in all the sub-token bucket modules is not more than the maximum value of the number of the tokens contained in the total token bucket module, and if the total number of the tokens exceeds the preset maximum value, redundant tokens are discarded according to the preset maximum value;
(4) a queue head IO request: judging whether the IO request set queue is empty, if so, ending, otherwise, taking out the IO request at the head of the queue by the sub token bucket module according to the arrangement sequence in the IO request set queue;
(5) requesting the token: the sub token bucket module sets the number of tokens required by the IO request according to the size, the type and the token generation speed of the IO request at the head of the queue, if the number of tokens in the sub token bucket module is larger than or equal to the number of tokens required by the IO request, the same number of tokens are taken out of the sub token bucket module and the IO request is processed, and the IO request exits the IO request set queue and returns to the execution step (4); if the number of tokens in the sub token bucket module is smaller than that of tokens required by the IO request, taking out all the tokens left in the sub token bucket module, subtracting the number of tokens required by the IO request from the number of tokens left in the sub token bucket module, marking the calculated result to the IO request, updating the result to be the new number of tokens required by the IO request, putting the IO request back to the head position of the IO request set queue, and executing the next step;
(6) checking the IO request: the sub-token bucket module regularly and sequentially checks whether the number of new tokens required by the IO request at the head of the queue in the IO request set queue is smaller than or equal to the number of tokens in the sub-token bucket module, if so, the tokens with the number same as that of the new tokens required by the IO request at the head of the queue are taken out from the sub-token bucket module and the IO request is processed, the IO request exits from the IO request set queue and returns to the execution step (4) and the execution step (5), the sub-token bucket module checks the next IO request, otherwise, the sub-token bucket module exits from the check, and after the check exits, the sub-token bucket module continuously generates the tokens according to the token generation speed in a certain preset period and puts the tokens into the sub-token bucket module, and the sub-token bucket module checks again.
The step of storing the IO request into the corresponding IO request set queue by the server includes:
(1) the server side sequentially stores the IO requests into an IO request set queue according to the time sequence of the IO requests sent by the client side;
(2) and the server side correspondingly adjusts the arrangement sequence of the IO requests according to the scheduling priority of each IO request in the IO request set queue. The IO request set queue can be selected as a priority queue, so that IO requests with different priorities can be queued according to the priority order, and priority scheduling can be realized.
The IO request set queue comprises a read operation IO request set queue and a write operation IO request set queue, the read operation IO request set queue is used for storing read operation of IO requests, and the write operation IO request set queue is used for storing write operation of IO requests; therefore, when the write operation is blocked, the normal processing of the read operation is not influenced.
The IO requests may be classified into different types, such as simply read and write, or may be allocated by function, such as scrub (erase), client (from client), etc., and the IO requests may have different priorities or enter different sub-queues according to different types. And the IO request enters an IO request set queue and then waits.
As shown in fig. 1, when a user (or other structures, processes, etc.) needs to read and write, an IO request is generated, and then the IO request enters a corresponding IO request set queue to queue, and waits for processing by a server; the sub-token bucket module of the server performs a series of operations (including adding a certain number of tokens (determined by user configuration) and processing the IO requests in the IO request set queue as much as possible) at regular time, and finally returns the processing result to the client. The sub token bucket module of the server side can perform a series of operations regularly when the sub token bucket module judges to perform subsequent operations; the token adding means that redundant tokens are discarded according to a set maximum value. The processing as much as possible means that as long as enough tokens can meet the IO request at the head of the queue, the IO request is continuously processed and output to the O request set queue until the IO request set queue is empty or can not meet the IO at the head of the queue, and when the IO request set queue can not be met, the rest tokens are taken out and given to the IO request, the number of tokens required by the IO request is marked to be subtracted by the corresponding number, and then the IO is put back to the head of the queue again to wait for the next round of processing. The processing result comprises information of processing success or failure and the like, and if the processing result fails, the client considers resending the request and the like; if the success is achieved, corresponding information (such as read information) is returned to the client.
Because of the bucket's accumulability, a token bucket can handle a certain degree of burstiness when a certain number of tokens are in the bucket, the ability to handle being related to the number of tokens accumulated by the bucket and the speed at which the bucket generates tokens.
In this example, by implementing the token bucket, the Ceph cloud storage supports limit (limit) in QoS, and can handle some degree of burst IO, so that the Ceph is more adaptive to the production environment.
The scope of the present invention includes, but is not limited to, the above embodiments, and the present invention is defined by the appended claims, and any alterations, modifications, and improvements that may occur to those skilled in the art are all within the scope of the present invention.
Claims (3)
1. A QoS setting method of a Ceph cloud storage system based on a token bucket algorithm is characterized in that the Ceph cloud storage system comprises a plurality of clients and a server which is in communication connection with the clients, a total token bucket module is arranged at the server, a plurality of sub-token bucket modules are arranged in the total token bucket module, a one-to-one correspondence relationship is formed between each client and each sub-token bucket module, and the QoS setting method comprises the following steps:
(1) set maximum and token generation speed: presetting the maximum value of the number of tokens contained in the total token bucket module and the speed of generating the tokens by the sub token bucket module;
(2) generating an IO request: the client generates an IO request, and the server stores the IO request into a corresponding IO request set queue, wherein the sub-token bucket modules and the IO request set queue are in one-to-one correspondence;
(3) obtaining a token: the sub-token bucket module in the server side continuously generates tokens according to the token generation speed n/T, wherein T is unit time, n x (T/T) tokens generated after T time are put into the sub-token bucket module, and the total number of the tokens contained in all the sub-token bucket modules is not more than the maximum value of the number of the tokens contained in the total token bucket module;
(4) a queue head IO request: judging whether the IO request set queue is empty, if so, ending, otherwise, taking out the IO request at the head of the queue by the sub token bucket module according to the arrangement sequence in the IO request set queue;
(5) requesting the token: the sub token bucket module sets the number of tokens required by the IO request according to the size, the type and the token generation speed of the IO request at the head of the queue, if the number of tokens in the sub token bucket module is larger than or equal to the number of tokens required by the IO request, the same number of tokens are taken out of the sub token bucket module and the IO request is processed, and the IO request exits the IO request set queue and returns to the execution step (4); if the number of tokens in the sub token bucket module is smaller than that of tokens required by the IO request, taking out all the tokens left in the sub token bucket module, subtracting the number of tokens required by the IO request from the number of tokens left in the sub token bucket module, marking the calculated result to the IO request, updating the result to be the new number of tokens required by the IO request, putting the IO request back to the head position of the IO request set queue, and executing the next step;
(6) checking the IO request: the sub-token bucket module periodically and sequentially checks whether the number of new tokens required by the IO request at the head of the queue in the IO request set queue is less than or equal to the number of tokens in the sub-token bucket module, if so, the sub-token bucket module takes out the tokens with the same number as the new tokens required by the IO request at the head of the queue and processes the IO request, and the IO request exits from the IO request set queue and returns to the execution step (4), otherwise, the sub-token bucket module exits from the check; a relatively large number of IO's occur in a short time, and the ability of this algorithm to process bursts is related to the set token generation rate v and bucket depth h, h/(M-v), where M is the maximum processing rate of the physical machine.
2. The QoS setting method for the Ceph cloud storage system based on the token bucket algorithm of claim 1, wherein the step of the server storing the IO requests into the corresponding IO request set queues comprises:
(1) the server side sequentially stores the IO requests into an IO request set queue according to the time sequence of the IO requests sent by the client side;
(2) and the server side correspondingly adjusts the arrangement sequence of the IO requests according to the scheduling priority of each IO request in the IO request set queue.
3. The QoS setting method for the Ceph cloud storage system based on the token bucket algorithm of claim 1, wherein the IO request set queue comprises a read operation IO request set queue and a write operation IO request set queue, the read operation IO request set queue is used for storing read operations of IO requests, and the write operation IO request set queue is used for storing write operations of IO requests.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710986526.5A CN107579926B (en) | 2017-10-20 | 2017-10-20 | QoS setting method of Ceph cloud storage system based on token bucket algorithm |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710986526.5A CN107579926B (en) | 2017-10-20 | 2017-10-20 | QoS setting method of Ceph cloud storage system based on token bucket algorithm |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107579926A CN107579926A (en) | 2018-01-12 |
| CN107579926B true CN107579926B (en) | 2021-02-09 |
Family
ID=61038010
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710986526.5A Active CN107579926B (en) | 2017-10-20 | 2017-10-20 | QoS setting method of Ceph cloud storage system based on token bucket algorithm |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107579926B (en) |
Families Citing this family (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108494703B (en) * | 2018-03-08 | 2022-05-06 | 腾讯科技（深圳）有限公司 | Access frequency control method, device and storage medium |
| CN108848038B (en) * | 2018-08-30 | 2021-01-29 | 华为技术有限公司 | Token bucket-based traffic management method and token bucket node |
| CN109542643B (en) * | 2018-11-16 | 2021-04-30 | 北京金山云网络技术有限公司 | Method and device for recovering messages in OpenStack system |
| CN110417677B (en) * | 2019-07-29 | 2021-03-09 | 北京易捷思达科技发展有限公司 | QoS control method based on Ceph distributed storage Osd end data Recovery |
| CN110891089B (en) * | 2019-11-29 | 2022-04-29 | 中国经济信息社有限公司 | Token bucket algorithm-based Ceph block memory mirror image synchronization QoS optimization method |
| CN111343102B (en) * | 2020-02-03 | 2023-09-26 | ***股份有限公司 | Flow rate control method, server, client server and system |
| CN111314238B (en) * | 2020-02-03 | 2023-12-05 | 网银在线（北京）科技有限公司 | Token management method and device, storage medium and electronic device |
| CN113472681A (en) * | 2020-03-30 | 2021-10-01 | 阿里巴巴集团控股有限公司 | Flow rate limiting method and device |
| CN111290858B (en) * | 2020-05-11 | 2020-08-11 | 腾讯科技（深圳）有限公司 | Input/output resource management method, device, computer equipment and storage medium |
| CN112363673A (en) * | 2020-11-12 | 2021-02-12 | 深圳大普微电子科技有限公司 | Flow management method and system, solid state disk controller and solid state disk |
| CN112751878B (en) * | 2020-12-30 | 2023-03-24 | 北京天融信网络安全技术有限公司 | Page request processing method and device |
| CN112698790B (en) * | 2020-12-31 | 2023-03-28 | 浪潮云信息技术股份公司 | QoS control method and system for processing burst I/O in storage system |
| CN113645150B (en) * | 2021-06-11 | 2023-06-27 | 天翼云科技有限公司 | Transmission rate control method, apparatus, electronic device, and readable storage medium |
| CN113296717B (en) * | 2021-07-26 | 2021-10-29 | 紫光恒越技术有限公司 | Optimization method of object storage distributed service quality, server and storage equipment |
| CN113709063A (en) * | 2021-08-05 | 2021-11-26 | 浪潮云信息技术股份公司 | Fine-grained QoS control method of Rados Gateway |
| US11979341B2 (en) | 2021-09-28 | 2024-05-07 | Red Hat, Inc. | Adaptive message queue timeouts for message queues related to storage systems |
| CN114500406B (en) * | 2022-02-11 | 2024-05-14 | 浪潮云信息技术股份公司 | Cloud file storage fine granularity QoS control method and system |
| CN114760327B (en) * | 2022-03-30 | 2024-03-26 | 阿里巴巴（中国）有限公司 | Cloud disk resource allocation adjusting method and device |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104111800A (en) * | 2013-04-18 | 2014-10-22 | 阿里巴巴集团控股有限公司 | Virtual disk IO port scheduling method and scheduling device |
| CN105144161A (en) * | 2013-03-13 | 2015-12-09 | 亚马逊科技公司 | Token-based admission control for replicated writes |
| CN106462601A (en) * | 2014-03-31 | 2017-02-22 | 亚马逊科技公司 | Atomic writes for multiple-extent operations |
-
2017
- 2017-10-20 CN CN201710986526.5A patent/CN107579926B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105144161A (en) * | 2013-03-13 | 2015-12-09 | 亚马逊科技公司 | Token-based admission control for replicated writes |
| CN104111800A (en) * | 2013-04-18 | 2014-10-22 | 阿里巴巴集团控股有限公司 | Virtual disk IO port scheduling method and scheduling device |
| WO2014172475A1 (en) * | 2013-04-18 | 2014-10-23 | Alibaba Group Holding Limited | Method and device for scheduling virtual disk input and output ports |
| CN106462601A (en) * | 2014-03-31 | 2017-02-22 | 亚马逊科技公司 | Atomic writes for multiple-extent operations |
Non-Patent Citations (2)
| Title |
|---|
| A New Disk I/O Scheduler Module with QoS Guarantee for Cloud Platform;Yubin Wu 等;《2012 Fourth International Symposium on Information Science and Engineering》;20121231;全文 * |
| ceph基于令牌桶算法的image的流量IOPS上限限制;小史;《https://blog.csdn.net/a1454927420/article/details/72865016?locationNum=7&fps=1》;20170605;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107579926A (en) | 2018-01-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107579926B (en) | QoS setting method of Ceph cloud storage system based on token bucket algorithm | |
| US20230039191A1 (en) | Throttling queue for a request scheduling and processing system | |
| US10185592B2 (en) | Network storage device using dynamic weights based on resource utilization | |
| US10318467B2 (en) | Preventing input/output (I/O) traffic overloading of an interconnect channel in a distributed data storage system | |
| US8719297B2 (en) | System for managing data collection processes | |
| CN112165691B (en) | Content delivery network scheduling method, device, server and medium | |
| CN109697122B (en) | Task processing method, device and computer storage medium | |
| CN109104373B (en) | Method, device and system for processing network congestion | |
| US10884667B2 (en) | Storage controller and IO request processing method | |
| CN104092756A (en) | Cloud storage system resource dynamic allocation method based on DHT mechanism | |
| US10496282B1 (en) | Adaptive port management to meet service level objectives using reinforcement learning | |
| WO2023226948A1 (en) | Traffic control method and apparatus, electronic device and readable storage medium | |
| CN111190541B (en) | Flow control method of storage system and computer readable storage medium | |
| CN115174535A (en) | POD scheduling method, system and device for realizing file transcoding based on Kubernetes and storage medium | |
| CN112684988A (en) | QoS method and system based on distributed storage | |
| CN110955522A (en) | Resource management method and system for coordination performance isolation and data recovery optimization | |
| CN116521234B (en) | Method and device for polling and scheduling processor pipeline instructions | |
| CN116320031A (en) | Server response method, device and medium | |
| CN117492992A (en) | Data scheduling method, device, electronic equipment and computer readable storage medium | |
| CN116074274A (en) | Message receiving optimization method and device, electronic equipment and storage medium | |
| KR101308182B1 (en) | Data Receiving Apparatus and Method for Controlling Stream and Memory, and Data Transmitting Apparatus | |
| CN115914119A (en) | File downloading current limiting method and device | |
| CN114760327A (en) | Method and device for adjusting cloud disk resource allocation | |
| CN112698790A (en) | QoS control method and system for processing burst I/O in storage system | |
| CN117851035A (en) | Resource cluster scheduling method based on multi-tenant sharing, computer and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20221012 Address after: 100094 107-2, 1st Floor, Building 1, East Yard, No. 10, Xibeiwang East Road, Haidian District, Beijing Patentee after: Beijing easy Star Technology Development Co.,Ltd. Address before: 210012 room 109, building 4, No. 168, software Avenue, Yuhuatai District, Nanjing City, Jiangsu Province Patentee before: NANJING EASYSTACK SOFTWARE TECHNOLOGY CO.,LTD. |
|
| TR01 | Transfer of patent right |