Review: Thecus 1U4500S 1U rackmount NAS

Performance analysis

It's testing time. For our benchmarking of the 1U4500 we sought to find out if it can take a hammering, and also if there are any particular scenarios it might thrive in.

We did our benchmarking with IOMeter version 2006.07.27 on an SMB share created on the 1U4500. To verify the performance seen with IOMeter over SMB, we did some less scientific testing using FTP and NFS.

Setup

The host machine for IOMeter was as follows:

As mentioned previously, the 1U4500 had 8000byte frames enabled, versus the host's 9000byte frames.

And here are the tests run with IOMeter:

When IOMeter doesn't have block-level access to a device, it must create a test file on the target filesystem. As part of our testing we varied the size of this. However, most tests were conducted with a 1GB test file. All IOMeter tests on the 1U4500 were run a minimum of three times, with three results taken and averaged (mean) for our graphing.

Test results

First up, let's see what happens with a varying test file size. Bear in mind that the 1U4500 has 512MiB of RAM. Once we identified the quickest test file size, we re-ran tests with jumbo frames disabled, to see how much performance would be affected by a network not supporting it.

A 1GB test file (too big to cache, of course), showed the slowest performance, with 22.32MB/sec reads and 31.32MB/sec writes. In our 'general' test, which throws in some random read/writes at smaller transfer sizes, the 1GB test file showed 7.32MB/sec average read/write throughput. Halving the test file size lead to an increase in performance. However, halving it again to 250MB allowed the 1U4500 to thrive in read operations. The 250MB file appears to fit nicely into the system's cache. It is in cases like this that jumbo frames help. Jumbo frames didn't have much impact on write or 'general' performance, however.

It looks to us as though the 1U4500 can serve up a collection of smaller files to clients rather nicely, thanks to its generous helping of RAM. For those of you interested, here's a graph of network usage during an IOMeter test run.

Next up, time to throw more than one IOMeter worker into the fray. Ordinarily, a NAS box will be serving multiple hosts simultaneously. For our tests, we ran several workers from the same test host.

Pushing up the number of workers appears to yield slightly more throughput. Of course, in reality this total throughput will be shared between the connected hosts. However, it's good to see the 1U4500 doesn't perform worse when extra transfer requests are added.

We did note some unusual behaviour in our IOMeter results file. For every run with extra workers, the first worker would get 80-90% of the throughput, while the others would grab a megabyte here or there. We fired up Filezilla and tried multiple , concurrent FTP transfers to see if the problem was IOMeter related, or a problem with the 1U4500.

Transferring four 2GB files over FTP, we obtained ~30MB/sec writes and ~40MB/sec reads, spread evenly across the files. No cause for concern there, then.

Now, what happens when one of the disks goes tits up?

This isn't the first RAID array we've seen read quicker when degraded, and this is after three tests runs, don't forget. Still, balance out read and write performance (look at 'General') and a degraded array performs about the same as a healthy one.

Our poor Thecus box wasn't happy with a broken hard drive, so we fixed it up with a working one (well, we re-installed the disk we rudely removed). We had the 1U4500 configured to do a fast rebuild, which turns out to take 6 hours. Fast, eh? Anyway, while rebuilding, performance takes a big hit. A slower rebuild would likely yield better performance results, but we can't be waiting forever to get a healthy array back now, can we!

We've changed the testing a little since we reviewed the N5200, but we made sure we could put a comparison together between it and the 1U4500. Here it is:

Our 1U4500 was tested with a 250MB test file and jumbo packets off - similar to when we tested the N5200. The 1U4500 looks to perform marginally better. That makes sense, given it has a speedier CPU and more RAM.

While we're talking about the CPU, we did some casual analysis of the CPU utilisation during our tests. Solid reading saw the 1U4500's CPU hover around the 80-100% mark. Writes, however were lower.

NFS

For our final bit of testing, we wanted to verify that NFS was working all hunky dory, so we switched to a Linux-powered system. A fresh install of Ubuntu Feisty Fawn Herd 4 (a testing release of the next version of Ubuntu). The system in question was an Acer TravelMate 4500WLMi, with a 1.6GHz Dothan, 1GiB PC2700 and a Mobility Radeon 9700. Unfortunately, it only has a 100Mbit network interface, but we've done our serious benchmarking already.

With the correct NFS packages installed on the system, mounting the NFS share was as easy as typing `mount host:/share/path /mount/point`. Easy as pie, in fact. We read and wrote a 2GiB file to the NFS share, timing it using a shell...

The read operation was done at a very impressive 11MiB/sec... that's damn good for a 100Mbit interface. The write operation ran at 9MiB/sec... also very good. From what we can see over a slower than best network connection, NFS works just fine.

Thoughts

Performance of the 1U4500 is mostly good. It's great at dealing with smaller files and it looks like it can handle several requests without getting bogged down. FTP and NFS work nicely.

With larger files, we think performance could be better. The disks and network can read/write quicker than we're seeing, so the bottleneck must sit somewhere else.