Hardware Checklist

Networking

MinIO recommends high speed networking to support the maximum possible throughput of the attached storage (aggregated drives, storage controllers, and PCIe busses). The following table provides a general guideline for the maximum storage throughput supported by a given physical or virtual network interface. This table assumes all network infrastructure components, such as routers, switches, and physical cabling, also supports the NIC bandwidth.

Networking has the greatest impact on MinIO performance, where low per-host bandwidth artificially constrains the potential performance of the storage. The following examples of network throughput constraints assume spinning disks with ~100MB/S sustained I/O

• 1GbE network link can support up to 125MB/s, or one spinning disk

• 10GbE network can support approximately 1.25GB/s, potentially supporting 10-12 spinning disks

• 25GbE network can support approximately 3.125GB/s, potentially supporting ~30 spinning disks

Memory

Memory primarily constrains the number of concurrent simultaneous connections per node.

You can calculate the maximum number of concurrent requests per node with this formula:

\(totalRam / ramPerRequest\)

To calculate the amount of RAM used for each request, use this formula:

\(((2MiB + 128KiB) * driveCount) + (2 * 10MiB) + (2 * 1 MiB)\)

10MiB is the default erasure block size v1. 1 MiB is the default erasure block size v2.

The following table lists the maximum concurrent requests on a node based on the number of host drives and the free system RAM:

The following table provides general guidelines for allocating memory for use by MinIO based on the total amount of local storage on the node:

Storage

MinIO recommends selecting the type of drive based on your performance objectives. The following table highlights the general use case for each drive type based on cost and performance:

Format drives as XFS and present them to MinIO as a JBOD array with no RAID or other pooling configurations.

Ensure a consistent drive type (NVMe, SSD, HDD) for the underyling storage. MinIO does not distinguish between storage types. Mixing storage types provides no benefit to MinIO.

Use the same capacity of drive across all nodes in each MinIO server pool. MinIO limits the maximum usable size per drive to the smallest size in the deployment. For example, if a deployment has 15 10TB drives and 1 1TB drive, MinIO limits the per-drive capacity to 1TB.

MinIO Diagnostics

Run the built in health diagnostic tool. If you have access to SUBNET, you can upload the results there.

mc support diag ALIAS --airgap

Replace ALIAS with the alias defined for the deployment.

MinIO Support Diagnostic Tools

For deployments registered with MinIO SUBNET, you can run the built-in support diagnostic tools.

Run the three mc support perf tests.

These server-side tests validate network, drive, and object throughput. Run all three tests with default options.

1. Network test

   Run a network throughput test on a cluster with alias minio1.

   mc support perf net minio1
   

2. Drive test

   Run drive read/write performance measurements on all drive on all nodes for a cluster with alias minio1. The command uses the default blocksize of 4MiB.

   mc support perf drive minio1
   

3. Object test

   Measure the performance of S3 read/write of an object on the alias minio1. MinIO autotunes concurrency to obtain maximum throughput and IOPS (Input/Output Per Second).

   mc support perf object minio1
   

Operating System Diagnostic Tools

If you cannot run the mc support diag or the results show unexpected results, you can use the operating system’s default tools.

Test each drive independently on all servers to ensure they are identical in performance. Use the results of these OS-level tools to verify the capabilities of your storage hardware. Record the results for later reference.

1. Test the drive’s performance during write operations

   This tests checks a drive’s ability to write new data (uncached) to the drive by creating a specified number of blocks at up to a certain number of bytes at a time to mimic how a drive would function with writing uncached data. This allows you to see the actual drive performance with consistent file I/O.

   dd if=/dev/zero of=/mnt/driveN/testfile bs=128k count=80000 oflag=direct conv=fdatasync > dd-write-drive1.txt
   

   Replace driveN with the path for the drive you are testing.

   dd	The command to copy and paste data.
   if=/dev/zero	Read from /dev/zero, an system-generated endless stream of 0 bytes used to create a file of a specified size
   of=/mnt/driveN/testfile	Write to /mnt/driveN/testfile
   bs=128k	Write up to 128,000 bytes at a time
   count=80000	Write up to 80000 blocks of data
   oflag=direct	Use direct I/O to write to avoid data from caching
   conv=fdatasync	Physically write output file data before finishing
   > dd-write-drive1.txt	Write the contents of the operation’s output to dd-write-drive1.txt in the current working directory

   The operation returns the number of files written, total size written in bytes, the total length of time for the operation (in seconds), and the speed of the writing in some order of bytes per second.

2. Test the drive’s performance during read operations

   dd if=/mnt/driveN/testfile of=/dev/null bs=128k iflag=direct > dd-read-drive1.txt
   

   Replace driveN with the path for the drive you are testing.

   dd	The command to copy and paste data
   if=/mnt/driveN/testfile	Read from /mnt/driveN/testfile; replace with the path to the file to use for testing the drive’s read performance
   of=/dev/null	Write to /dev/null, a virtual file that does not persist after the operation completes
   bs=128k	Write up to 128,000 bytes at a time
   count=80000	Write up to 80000 blocks of data
   iflag=direct	Use direct I/O to read and avoid data from caching
   > dd-read-drive1.txt	Write the contents of the operation’s output to dd-read-drive1.txt in the current working directory

   Use a sufficiently sized file that mimics the primary use case for your deployment to get accurate read test results.

   The following guidelines may help during performance testing:

   • Small files: < 128KB

   • Normal files: 128KB – 1GB

   • Large files: > 1GB

   You can use the head command to create a file to use. The following command example creates a 10 Gigabyte file called testfile.

   head -c 10G </dev/urandom > testfile
   

   The operation returns the number of files read, total size read in bytes, the total length of time for the operation (in seconds), and the speed of the reading in bytes per second.

Third Party Diagnostic Tools

IO Controller test

Use IOzone to test the input/output controller and all drives in combination. Document the performance numbers for each server in your deployment.

iozone -s 1g -r 4m -i 0 -i 1 -i 2 -I -t 160 -F /mnt/sdb1/tmpfile.{1..16} /mnt/sdc1/tmpfile.{1..16} /mnt/sdd1/tmpfile.{1..16} /mnt/sde1/tmpfile.{1..16} /mnt/sdf1/tmpfile.{1..16} /mnt/sdg1/tmpfile.{1..16} /mnt/sdh1/tmpfile.{1..16} /mnt/sdi1/tmpfile.{1..16} /mnt/sdj1/tmpfile.{1..16} /mnt/sdk1/tmpfile.{1..16} > iozone.txt