[DD of the method of LINUX]LINUXI/O testing

Reference HTTP://WWW.THOMAS-KRENN.COM/EN/WIKI/LINUX_I/O_PERFORMANCE_TESTS_USING_DDMeasuring Write Performance

Modern operating systems do not normally write files immediately to RAID systems or hard disks. Temporary memory that isn't currently in use would be used to the cache writes and reads (regarding this, see also Operating S Ystem Caches).

So, I/O performance measurements won't be affected by these caches (temporary memory), the oflag parameter can is U sed. Thereby, the following, the flags is interesting (for details, see and dd --help Dd using direct or synchronized I/O):

• Direct (use direct I/O for data)
• Dsync (use synchronized I/O for data)
• Sync (likewise, but also for metadata)

For measuring write performance, the data to be written should is read From/dev/zero^{[2] and ideally written it to an empty RAID array, hard disk or partition (such as using OF=/DEV/SDA for the first hard disk or of=/dev/sda2 for the second partition on the first hard disk). If This isn't possible, a normal file in the file system (such as using OF=/ROOT/TESTDATEI1GB) can be written. The write performance achieved thereby would be a little slower (because metadata would also be written to the file system).}

Important: When writing to a device (such AS/DEV/SDA), the data stored there would be lost. For this reason, you should only use the empty RAID arrays, hard disks or partitions.

Note:

• When using If=/dev/zero and bs=1g, Linux would need 1GB of free space in RAM. If your test system does not has sufficient RAM available, use a smaller parameter for BS (such as 512MB).
• In order to get results closer to real-life, we recommend performing the tests described several times (three to ten times , for example). By doing so, you can quickly detect outliers. Such outliers can include cron jobs, interrupts or general conditions due to parallel processing, which can all briefly AF Fect performance. An extreme example, which clarifies this issue, would is the parallel execution of UpdateDB by a cron job.

Laptop Example

In this example, the test data would be written to/dev/sda2. The test system (a Thinkpad T43 Type 2668-4gg) had 1.5 gbyte of RAM and a Fujitsu mht2060ah hard disk rotating at 5,400 RP M.

Laptop Throughput (streaming I/O)

One gigabyte is written for the test, first with the cache activated (HDPARM-W1/DEV/SDA):

Then, with the cache deactivated (HDPARM-W0/DEV/SDA):

[Email protected] ~ # DD If=/dev/zero of=/dev/sda2 bs=1g count=1 oflag=direct    

Laptop Latency

In this test, bytes were written one thousand times, first with the cache activated (HDPARM-W1/DEV/SDA):

[Email protected] ~ # DD If=/dev/zero of=/dev/sda2 bs=512 count=1000 oflag=direct1000+0 Records in1000+0 Records out512000 Bytes (MB) copied, 0.36084 s, 1.4 Mb/s[email protected] ~ #

Then, with the cache deactivated (HDPARM-W0/DEV/SDA): One thousand accesses required 11.18 seconds, meaning one access t Ook 11.18 Ms.

Server with RAID10 Example

In this example, the test data is written to an empty partition. The test system is an 2HE Intel dual-cpu SC823 Server with six 147 GB SAS Fujitsu mba3147rc (15,000 rpm) hard disks and a N Adaptec 5805 RAID controller with the cache activated and a BBU.

Server Throughput (streaming I/O)

One gigabyte is written for the test:

Server Latency

In this test, bytes were written one thousand times. Thereby, the 0.084 seconds that were measured for one thousand accesses corresponded to precisely 0.084 MS for each access . This value was so low because of the RAID controller ' s cache:

test-sles10sp2:~ # dd If=/dev/zero of=/dev/sda6 bs=512 count=1000 oflag=dsync1000+0 Records in1000+0 Records out512000 BYT ES (KB) copied, 0.083902 seconds, 6.1 mb/stest-sles10sp2:~ #

[DD of the method of LINUX]LINUXI/O testing