A good algorithm, implementation. Ultimately, I'm going to do IO.
The use of traditional mechanical hard disk, the storage of big data is also OK, but the database content acquisition is really poor to a realm. Here is an exploration:
Disk Performance:
Before we understand the disk I/O monitoring command iostat, we need to understand the metrics for disk I/O performance monitoring, and the performance of some aspects of the disk revealed by each indicator. Indicators for disk I/O performance monitoring mainly include:
1) Number of I/Os per second ([r/s w/s])-Number of requests processed per second
IOPS: Continuous read or sequential write of one disk is called a disk I/O.
Key metrics for frequently used random read and write applications such as the main reference relational database:)
SSD This can be optimized to the realm of terror ~ Unfortunately estimate the project is not necessary to use.
IOPS (io per second) = 1s/(seek time + rotation delay + data transfer time)
Can be estimated: 1W rpm HDD Iops:iops = +/(3 + 60000/10000/2 + 32k/136k) = 167
2) throughput ([rkb/s wkb/s])-Request size
Throughput: The speed at which a hard drive transmits data, and transmits data to and from the data being read and written.
Key metrics for continuous requests such as online video
3) Average I/O data size (AVGRQ-SZ)-size of each request
Throughput divided by the number of I/O, Avgrq-sz < 32K random Access is the main. Avgrq-sz > 32K sequential storage primarily
4) Percentage of disk activity time (%UTIL)-Disk utilization
Utilization: The disk is active in data transfer and processing commands (such as Seek).
Disk utilization is proportional to the level of resource contention, inversely related to performance.
5) Service time (SVCTM)-Ability to process requests
Refers to the time when disk reads or writes are performed, including seek, rotational delay, and data transmission. Its size is generally related to disk performance, cpu/memory load will have an impact on it, too many requests will indirectly lead to increased service time. If the value continues to exceed 20ms, it can generally be considered to have an impact on the upper application. The main point here refers to FC, SAS, SATA disks, the speed is usually 5400/7200/1w rpm.
Seek Time Tseek refers to the time required to move a read-write head to the correct track. The shorter the seek time, the faster I/O operation, the average seek time of the disk is usually 3-15ms.
Rotation delay Trotation refers to the time it takes for the disc to rotate to move the sector of the requested data below the read-write head. The rotational delay depends on the disk speed, typically 1/2 of the time it takes to rotate the disk for a week. For example, the average rotational delay of 7200 RPM is approximately 60*1000/7200/2 = 4.17ms, while the average rotational latency of disks with 15000 RPM is approximately 2ms.
Data transfer Time Ttransfer is the amount of time required to complete the transfer of the requested data, depending on the data transfer rate, which is equal to the size divided by the transfer rate. At present, the Ide/ata can achieve the 133mb/s,sata II can reach 300MB/S interface data transmission rate, the data transmission time is usually much smaller than the first two parts of consumption time. Simple calculation can be ignored.
6) I/O wait queue Length (AVGQU-SZ)-Number of requests exceeding processing capacity
Pending I/O requests, the value increases when the request continues to exceed the disk processing power.
Avgqu-sz > 2 can be considered an I/O performance issue.
7) Wait time (await)-time to complete the request
The time to wait for execution, the size of the await typically depends on the service time (SVCTM) and the length of the I/O queue and the emit mode of the I/O request.
A): SVCTM ~ ~ await I/O almost no waiting time
b): await >> SVCTM I/O queue is too long and the application gets slower response time
------------------------------------------------------------------------------
According to the above content, then to see the actual combat
New large file: Time dd if=./test1 of=./test bs=10m count=1000
100+0 Records in
100+0 Records out
1048576000 bytes (1.0 GB) copied, 8.39376 s, + MB/s
Real 0m8.496s
User 0m0.000s
SYS 0m1.341s
Can see reading and writing speed around 125M, processing 1G of data, about 8.5S
Also, use Iostat to count disk IO
Iostat-d-k-x 2
Yesterday encountered a problem, POSTGRES continued to occupy a CPU run time, began to think is performance on the IO, after viewing, found r/s only around 0.7m/s.
You can exclude IO and turn to query statement optimization.
The original intention of the study is to solve the problem of too slow IO, after observing that the problem is that the query Psql the parent table cannot be applied to the index of the child table.
System disk IO Performance parameter interpretation "reprint"