![]() ![]() User $ sysbench -test=mutex -num-threads=64 run sysbench 0.4.12: multi-threaded system evaluation benchmark The random mutex is taken from a pool sized by the -mutex-num parameter. This process is repeated several times identified by the number of locks ( -mutex-locks). This request will first put some stress on the CPU (using a simple incremental loop, through the -mutex-loops parameter) after which it takes a random mutex (lock), increments a global variable and releases the lock again. When using the mutex workload, the sysbench application will run a single request per thread. Or put differently, on average, the lock-yield-unlock process took about 10.54 microseconds on average. In the above case, a single request (of on average 10.54ms) has run the lock-yield-unlock process 1000 times. When using the -max-time option, the number you want to use for comparing systems is the per-request statistic. Total time taken by event execution: 19.9653Įxecution time (avg/stddev): 19.9653/0.00 Thread yields per test: 1000 Locks used: 1 User $ sysbench -test=threads -thread-locks=1 -max-time=20s run sysbench 0.4.12: multi-threaded system evaluation benchmark With the threads workload, each worker thread will be allocated a mutex (a sort of lock) and will, for each execution, loop a number of times (documented as the number of yields) in which it takes the lock, yields (meaning it asks the scheduler to stop itself from running and put it back and the end of the runqueue) and then, when it is scheduled again for execution, unlock.īy tuning the various parameters, one can simulate situations with high concurrent threading with the same lock, or high concurrent threading with several different locks, etc. While older versions of sysbench limit the number of events, sysbench >=1.0 limits the total execution time by default, in which case the total number of events or the number of events per second should be used as a performance indicator instead of the total execution time. Unlike the event execution time, the total time is the duration from start to finish (so no culmination of individual times of the threads). The total time is the end-to-end time, and as such includes the overhead of shared memory access for the threads (although this is usually negligible). ![]() If you run the test with multiple threads, it is the sum of the time of all threads. The event execution time is the pure calculation part. The number to verify with other systems is given by the execution summary: Total time taken by event execution: 36.1322Įxecution time (avg/stddev): 18.0661/0.00 Maximum prime number checked in CPU test: 20000 User $ sysbench -test=cpu -cpu-max-prime=20000 -num-threads=2 run sysbench 0.4.12: multi-threaded system evaluation benchmark The benchmark can be configured with the number of simultaneous threads and the maximum number to verify if it is a prime. As you can imagine, this will put some stress on the CPU, but only on a very limited set of the CPUs features. If any number gives a remainder of 0, the next number is calculated. When running with the CPU workload, sysbench will verify prime numbers by doing standard division of the number by all numbers between 2 and the square root of the number. These numbers can be compared with runs on different file systems, other systems, etc. The important part to look at is the information regarding the operations: Total time taken by event execution: 173.9797Įxecution time (avg/stddev): 173.9797/0.00 Periodic FSYNC enabled, calling fsync() each 100 requests.Ĭalling fsync() at the end of test, Enabled. Read/Write ratio for combined random IO test: 1.50 Number of random requests for random IO: 0 User $ sysbench -test=fileio -file-total-size=32G -file-test-mode=rndrw -max-time=300 -max-requests=0 run sysbench 0.4.12: multi-threaded system evaluation benchmark ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |