Before chatting with colleagues, mentioned this hardware aspect (including memory, CPU, and hard disk storage choice), personally think can improve the performance of the underlying hardware from these aspects, thus improve the overall throughput and speed of the website.
A. Host:
(1). CPU: Determines the processing speed, the good CPU can speed up the computation time of the whole program, is the server can respond to requests more quickly.
(2). Memory: The use of large-capacity memory, can effectively improve the data cache efficiency, mainly hot data access speed.
(3). Disk:
-
- Size: Affects how much data is stored.
- Type: SAS or SATA or FC or SSD drive
- RPM: Determines the delay time of each IO request, which is what we often say ioPS and Mbps
(4). RAID Card:
Cache: Cache size has a significant impact on data write speed, and the use of policies can directly affect IO efficiency
Battery: Battery charge and discharge strategy affects instantaneous IO fluctuations
(5). Other: such as bus bandwidth, determines the efficiency of data transfer between the CPU and memory, which is often less attention, but may also appear bottlenecks
Two. Network:
Delay: Different network devices will have a difference in latency, for OLTP devices, the delay is naturally the smaller the better
Throughput: For a DB cluster, network throughput between nodes can directly determine the processing power of the cluster
IOPS: For OLTP systems, data transfer is more in small io multiple concurrency, sometimes the light has a large bandwidth does not necessarily meet the demand
The hardware angle can provide the processing power, must be listed above the various aspects (here is only the main part, there may be other ) the overall ability of the joint decision, any one aspect of the bottleneck, can lead to the overall performance is not going to, that is, we often say the barrel principle.
In previous experiences, the areas where performance bottlenecks are most likely to occur are mainly in the following areas:
- IO resource Bottlenecks
When the bottleneck occurs in IO resources, the main performance is high server iowait, USR accounted for less , the system response is slow, the database often has a large number of execution status of the session.
In the case of IO resource bottlenecks, the hardware-level optimization scenarios we can use are mainly:
- Increased memory to increase the amount of data that can be cached: the effectiveness of this scheme depends on the total amount of hot data in the system, after all, the cost of memory is relatively high, and the amount of memory that a single device can manage is limited.
- Improve the IO capability of the underlying storage device: As described earlier in this article, the improvement of the underlying storage capability depends on several aspects, both the ability of the individual disk itself, and the policy on the number of disks, as well as the bandwidth constraints between the storage itself and the storage and host. Therefore, in the optimization of the underlying storage capacity at the same time need to take into account the 3 factors, good overall analysis and local balance
- CPU Resource bottleneck
When CPU resources encounter bottlenecks, the main performance in the server CPU utilization of USR accounted for a high percentage, iowait is very small. Most of these problems occur in scenarios where the amount of data is not too large and there is enough memory to cache the data. is also the database performance bottleneck faced by most small and medium-sized web sites today.
When encountering CPU resource bottlenecks, it can be caused by two aspects:
- too dependent on the database for logical operations: the best way to optimize this situation is to migrate the operation from the database side to the application side as much as possible. Reduce the computational capacity of the database host. After all, the cost of expanding a stateful system device (database) is much higher than a stateless class system device (application). Of course, if you want to solve the problem from the database side of the hardware, only by increasing the number of device CPUs (if supported), or using a higher CPU capacity of the host to replace the old host
- database logical IO is too large: for this kind of situation, The only thing you can do from a hardware perspective is to improve CPU processing power. Either increase the number of CPUs (if supported) or change the CPU to a more powerful host. But before that, it is recommended that you try to optimize from an application perspective to see if you can minimize unnecessary requests or reduce the amount of data per request. At the same time, from the database perspective for the schema structure and the corresponding optimization of the index, as far as possible to complete a request to retrieve the amount of data to be smaller, so as to reduce the purpose of logic io
- Bottlenecks in network resources
In general, the resources required to interact with the network between the databases are not very large, so it may not be very large for the environment to experience bottlenecks. But in the distributed cluster environment, the network environment between each database node is often called the bottleneck of the system.
More common scenarios such as MySQL Cluster or Oracle RAC environments, the quality of the data Exchange network environment between nodes can directly affect the overall processing power of the system, because there will be a large number of data exchange between nodes, are dependent on network transmission to complete.
In such a scenario, a cheaper solution is to use the Gigabit switch to replace the now-commonly used GBE switch to improve network processing power and reduce network latency. However, the main improvement of this solution is throughput, and the delay may not necessarily meet some of the most demanding scenarios. It is time to consider using a more expensive but more efficient solution: replacing the normal switch with Infiniband greatly reduces the data exchange latency caused by the network.
About the impact of disk CPUs and memory on site performance in high-performance sites
