Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to install and simply use the database stress testing tool tiobench,orion,lmbench,netperf

2025-01-25 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

Shulou(Shulou.com)06/01 Report--

This article will explain in detail how to install and use the database stress testing tool tiobench,orion,lmbench,netperf. The content of the article is of high quality, so the editor will share it for you as a reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

Download:

Http://sourceforge.net/projects/tiobench/files/tiobench/0.3.3/tiobench-0.3.3.tar.gz/download

Extract: tar xzvf tiobench-0.3.3.tar.gz

Then go to the tiobench-0.3.3 directory

Make

Make install

The IO test (the read-write test tool for the file system) can be helped using the following command.

. / tiotest-h

Using predefined or configurable tests, you can use the command to get help.

. / tiobench.pl-help

The execution can be as follows: tiobench.pl actually just wraps a layer, which calls tiotest

. / tiobench.pl-block 4-random 10000-numruns 5-threads 10-size 2048

The above sentence means:

1 block size is 4 bytes, 10 threads, execute 10000 random IO, write 2048MB data, a total of 5 times.

After the test, you can see that the resulting test report is as follows:

Unit information=

File size = megabytes

Blk Size = bytes

Rate = megabytes per second

CPU% = percentage of CPU used during the test

Latency = milliseconds

Lat% = percent of requests that took longer than X seconds

CPU Eff = Rate divided by CPU%-throughput per cpu load

Sequential Reads

2.6.18-164.el5 1024 4 10 4.94 8210.% 0.004 7.27 0.00000 0.00000 0

Random Reads

2.6.18-164.el5 1024 4 10 4.64 7483.3% 0.004 0.04 0.00000 0.00000 0

Sequential Writes

2.6.18-164.el5 1024 4 10 2.21 9521.% 0.015 11.56 0.00000 0.00000 0

Random Writes

2.6.18-164.el5 1024 4 10 0.02 98.51% 0.012 0.06 0.00000 0.00000 0

To know what each line represents, execute:. / tiosum.pl to get the TIILE of each line. This place feels like a knockoff.

To assemble it is:

Unit information=

File size = megabytes

Blk Size = bytes

Rate = megabytes per second

CPU% = percentage of CPU used during the test

Latency = milliseconds

Lat% = percent of requests that took longer than X seconds

CPU Eff = Rate divided by CPU%-throughput per cpu load

Sequential Reads

File Blk Num Avg Maximum Lat% Lat% CPU

Kernel Size Size Thr Rate (CPU%) Latency Latency > 2s > 10s Eff

2.6.18-164.el5 1024 4 10 4.94 8210.% 0.004 7.27 0.00000 0.00000 0

Random Reads

File Blk Num Avg Maximum Lat% Lat% CPU

Kernel Size Size Thr Rate (CPU%) Latency Latency > 2s > 10s Eff

2.6.18-164.el5 1024 4 10 4.64 7483.3% 0.004 0.04 0.00000 0.00000 0

Sequential Writes

File Blk Num Avg Maximum Lat% Lat% CPU

Kernel Size Size Thr Rate (CPU%) Latency Latency > 2s > 10s Eff

2.6.18-164.el5 1024 4 10 2.21 9521.% 0.015 11.56 0.00000 0.00000 0

Random Writes

File Blk Num Avg Maximum Lat% Lat% CPU

Kernel Size Size Thr Rate (CPU%) Latency Latency > 2s > 10s Eff

2.6.18-164.el5 1024 4 10 0.02 98.51% 0.012 0.06 0.00000 0.00000 0

Found that a read IO only 0.004 milliseconds, very fast, this is because IO is based on the file system cache, in fact, the test is memory, not the file system. So, you can use one of the following tools to test IO.

To download http://www.oracle.com/technetwork/topics/index-089595.html, you need a free account for OTN.

After downloading and installing, you can get help with the following command:

. / orion_linux_x86-64-help

To avoid file system cache, we can first umount the directories that need to be tested

For example, the directory I want to test is / data/, and the corresponding disk is / dev/sda8 (the mapping relationship is saved in / etc/fstab)

Execute first:

Umount / data

Then execute the command, after the command execution is completed, and then execute mount / data to re-mount back.

Mount / data

The tests are as follows:

Database OLTP type, assuming that the IO type is all 8K random operation, pressure type, automatic pressurization, from small to large, all the way to the storage pressure limit. Test the 8KB block with a read-write ratio of 50% 2.2.1 each. This is the database block size.

Create a file named zhoucang8k.lun with the content / dev/sda8

. / orion_linux_x86-64-run advanced-testname zhoucang8k-size_small 8-size_large 8-type rand-write 50 &

Some reports can be obtained here as follows:

The file 1:zhoucang8k_20110520_1757_lat.csv represents the delay of each IO, 1 Large/Small1234503.554.184.775.355.941 2, 3, 4, 5, respectively, the ability to concurrency Large/Small1234503.554.184.775.355.941 2, file 2:zhoucang8k_20110520_1757_iops.csvIOPS, and 1, 2, 3, 4, 5, respectively. Large/Small1234502814786287478421 2 file 3:zhoucang8k_20110520_1757_mbps.csv IO throughput, in MB/ per second Large/Small01234512.14 23.72

There are two other files: the trace file is long, which is not posted here. The other summary file is as follows:

File 4:zhoucang8k_20110520_1757_summary.txtORION VERSION 11.1.0.7.0Commandline:

-run advanced-testname zhoucang8k-size_small 8-size_large 8-type rand-write 50

This maps to this test:

Test: zhoucang8k

Small IO size: 8 KB

Large IO size: 8 KB

IO Types: Small Random IOs, Large Random IOs

Simulated Array Type: CONCAT

Write: 50%

Cache Size: Not Entered

Duration for each Data Point: 60 seconds

Small Columns:, 0

Large Columns:, 0, 1, 2

Total Data Points: 8

Name: / dev/sda8 Size: 1053115467264

1 FILEs found.

Maximum Large MBPS=3.72 @ Small=0 and Large=2

Maximum Small IOPS=842 @ Small=5 and Large=0

Minimum Small Latency=3.55 @ Small=1 and Large=0

2.2.2 Test the random IO of 128KB, which is the default value of db_file_multiblock_read_count.

Create a file named zhoucang128k.lun with the content / dev/sda8

. / orion_linux_x86-64-run advanced-testname zhoucang128k-size_small 128-size_large 128-type rand-write 50 &

Results (see annex):

Maximum Large MBPS=29.11 @ Small=0 and Large=2

Maximum Small IOPS=311 @ Small=5 and Large=0

Minimum Small Latency=5.93 @ Small=1 and Large=0

2.2.3 Test 1MB's random IO, which is the largest IO that can be supported on the operating system.

Create a file named zhoucang1024k.lun with the content / dev/sda8

. / orion_linux_x86-64-run advanced-testname zhoucang1024k-size_small 1024-size_large 1024-write 50-type rand &

Results (see annex):

Maximum Large MBPS=109.76 @ Small=0 and Large=2

Maximum Small IOPS=135 @ Small=5 and Large=0

Minimum Small Latency=11.49 @ Small=1 and Large=0

2.2 IO throughput testing, related to database archiving, etc. 2.2.1 Database throughput test, assuming that the IO is all 1m sequential IO

. / orion_linux_x86-64-run advanced-testname zhoucang1m-size_small 1024-size_large 1024-write 50-type seq &

IOPS:

Large/Small12345083110123129133

Lat:

Large/Small12345011.9218.1224.3330.8637.56

After finishing this, you may need to recreate the file system. Because the label header information of / dev/sda8 is overwritten.

/ etc/fstab is as follows

LABEL=/data / data ext3 defaults 1 2

Execute the following command to create a file system.

Mkfs-t ext3 / dev/sda8

/ etc/fstab to add:

/ dev/sda8 / data ext3 defaults 1 2

Mount-a

Download a Lmbench:

Www.bitmover.com/lmbench

Http://www.bitmover.com/bitkeeper (the link inside cannot be opened)

Tar xzvf lmbench-3.0-a9.tgz

Lmbench-3.0-a9

Make results

Enter 1000, about 1 GB of memory test. (the higher the value, the more accurate the test results. At the same time, the higher the value, the longer the test time.)

Other parameters can be selected, here I chose all the default (tuning the size and other parameters), a long process of execution.

After the test, you can get the following four files by executing make see

Under the result directory: percent.errs percent.out summary.errs summary.out

Percent.errs and summary.errs

Other: how exactly do you use this tool? It is found that there are many files in the BIN directory of this tool, and the function is very powerful. For more information, please refer to this linked list:

Http://www.bitmover.com/lmbench/man_lmbench.html

Detailed test results are attached:

This tool is developed by HP, a tool to test the network stack, detailed documentation can be found in the attachment.

Download a netperf from the official website and log in:

Ftp://ftp.netperf.org/netperf/

Copy files: netperf-2.4.5.tar.gz

Execution

Tar xzvf netperf-2.4.5.tar.gz

Cd netperf-4.0.0rc2

Mkdir bin

. / configure-prefix / root/zhoucang/netperf-2.4.5/bin

To detect the target characteristics of the installation platform, you can directly makefile under linux

Then execute make and make install

After the installation is complete, go to the bin directory of the installation directory.

Execute the following command to view help:

. / netperf-help

4.1 performance of batch (bulk) network traffic

Typical examples of bulk data transfer are ftp and other similar network applications (that is, transferring entire files at once). According to the different transmission protocols, batch data transmission can be divided into TCP batch transmission and UDP batch transmission.

4.1.1 Test TCP_STREAM transport:

Netperf performs TCP batch transfer by default, that is,-t TCP_STREAM. During the test, netperf sent batches of TCP data packets to netserver to determine the throughput during the data transfer:

The test results are as follows

[root@tstpay1 bin] #. / netperf-H 10.253.34.8-l 60TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.253.34.8 (10.253.34.8) port 0 AF_INET

Recv Send Send

Socket Socket Message Elapsed

Size Size Size Time Throughput

Bytes bytes bytes secs. 10 ^ 6bits / sec

87380 16384 16384 60.03 949.29

From the result output of netperf, we can know the following information:

1) the remote system (i.e. server) uses a socket receive buffer with a size of 87380 bytes

2) the local system (i.e. client) uses a socket send buffer with a size of 16384 bytes

3) the size of the test packet sent to the remote system is 16384 bytes

4) the test experience time is 60.03 seconds.

5) the test result of throughput is 949.29Mbits/ seconds.

4.1.2 testing of UDP_STREAM

UDP_STREAM is used to test the network performance of UDP batch transmission. It is important to note that the size of the test packet must not be larger than the send and receive buffer size of socket, otherwise netperf will report an error:

Execute:. / netperf-t UDP_STREAM-H 10.253.34.8-l 60

The implementation results are as follows:

[root@tstpay1 bin] #. / netperf-t UDP_STREAM-H 10.253.34.8-l 60UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.253.34.8 (10.253.34.8) port 0 AF_INET

Socket Message Elapsed Messages

Size Size Time Okay Errors Throughput

Bytes bytes secs # # 10 ^ 6bits / sec

262144 65507 60.00 110099 0 961.62

129024 60.00 110098 961.61

There are two lines of test data in the result of the UDP_STREAM mode. The first row shows the sending statistics of the local system, where the throughput represents the ability of the netperf to send packets to the local socket. However, we know that UDP is an unreliable transport protocol, and the number of packets sent is not necessarily equal to the number of packets received.

The second line shows the reception of the remote system. Because client is directly connected to server and there is no other traffic in the network, almost all the packets sent by the local system are correctly received by the remote system, and the throughput of the remote system is almost equal to that of the local system. However, in the actual environment, the socket buffer size of the general remote system is different from the socket buffer size of the local system, and because of the unreliability of the UDP protocol, the receiving throughput of the remote system is far less than the outgoing throughput.

4.2 performance of request / reply (request/response) network traffic

Another common type of network traffic is the request/response pattern applied in the client/server structure. In each transaction (transaction), client sends a small query packet to server, and server receives the request and returns large result data after processing.

4.2.1 TCP_RR

The test object of TCP_RR mode is the transaction process of multiple TCP request and response, but they occur in the same TCP connection, and this pattern often appears in database applications. After the client program of the database establishes a TCP connection with the server program, it transmits multiple transactions of the database in this connection.

[root@tstpay1 bin] #. / netperf-t TCP_RR-H 10.253.34.8TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.253.34.8 (10.253.34.8) port 0 AF_INET

Local / Remote

Socket Size Request Resp. Elapsed Trans.

Send Recv Size Size Time Rate

Bytes Bytes bytes bytes secs. Per sec

16384 87380 11 10.00 11294.81

The result of the Netperf output also consists of two lines. The first line shows the local system, and the second line shows information about the remote system. The average transaction rate (transaction rate) is 11294.81 times per second. Notice that the size of the request and response packets in each transaction is 1 byte, which is not of great practical significance. Users can change the size of request and response packets by testing relevant parameters. The parameters in TCP_RR mode are shown in the following table:

Parameter description-s size sets the socket send and receive buffer size for the local system-S size sets the socket send and receive buffer size for the remote system-r req,resp sets the size of request and reponse packets-D sets the TCP_NODELAY option for the socket of the local and remote systems

By using the-r parameter, we can do a more meaningful test:

#. / netperf-t TCP_RR-H 10.253.34.8-r 32 port 1024TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.253.34.8 (10.253.34.8) port 0 AF_INET

Local / Remote

Socket Size Request Resp. Elapsed Trans.

Send Recv Size Size Time Rate

Bytes Bytes bytes bytes secs. Per sec

16384 87380 32 1024 10.00 8955.26

16384 87380

It can be seen from the results that the increase in the size of request/reponse packets leads to a significant decrease in the transaction rate. Note: compared with the actual system, the calculation of the transaction rate here does not fully take into account the processing delay of the application in the transaction process, so the result is often higher than the actual situation.

4.2.2 TCP_CRR

Unlike TCP_RR, TCP_CRR establishes a new TCP connection for each transaction. The most typical application is HTTP, where each HTTP transaction takes place in a separate TCP connection. Therefore, due to the need to constantly establish new TCP connections and dismantle TCP connections at the end of the transaction, the transaction rate will be greatly affected.

[root@tstpay1 bin] #. / netperf-t TCP_CRR-H 10.253.34.8TCP Connect/Request/Response TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.253.34.8 (10.253.34.8) port 0 AF_INET

Local / Remote

Socket Size Request Resp. Elapsed Trans.

Send Recv Size Size Time Rate

Bytes Bytes bytes bytes secs. Per sec

16384 87380 1 1 10.00 4607.63

16384 87380

Even with an one-byte request/response packet, the transaction rate is significantly lower, only 4607.63 beats per second. TCP_CRR uses the same local parameters as TCP_RR.

4.2.3 UDP_RR

UDP_RR mode uses UDP grouping to carry out the transaction process of request/response. Since there is no burden of TCP connection, we speculate that the trading rate will increase accordingly.

[root@tstpay1 bin] #. / netperf-t UDP_RR-H 10.253.34.8UDP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.253.34.8 (10.253.34.8) port 0 AF_INET

Local / Remote

Socket Size Request Resp. Elapsed Trans.

Send Recv Size Size Time Rate

Bytes Bytes bytes bytes secs. Per sec

262144 262144 11 10.00 11367.45

129024 129024

The results confirm our conjecture that the trading rate is 11367.45 times per second, which is higher than the TCP_RR value. However, if the opposite result occurs, that is, the transaction rate is reduced, there is no need to worry, because this shows that routers or other network devices in the network use different buffer space and processing technology for UDP than TCP.

On how to carry on the database stress testing tool tiobench,orion,lmbench,netperf installation and simple use to share here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 215

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report