2

I am renting two identical physical servers (at Serverloft). These servers come with 2x512 GB SSD disks, and I've set them up with mdadm in a RAID1. The disks are locally installed in the server.

The write performance on these two systems seem to differ dramatically.

According to lshw -short, the controller is :

C610/X99 series chipset 6-Port SATA Controller [AHCI mode]

1st server (2 x SAMSUNG MZ7TE512)

host02:/tmp# dd bs=1M count=8192 if=/dev/zero of=testfile conv=fdatasync
8192+0 records in
8192+0 records out
8589934592 bytes (8.6 GB) copied, 38.4952 s, 223 MB/s

2nd server (2 x SAMSUNG MZ7LN512)

host03:/tmp# dd bs=1M count=8192 if=/dev/zero of=testfile conv=fdatasync
8192+0 records in
8192+0 records out
8589934592 bytes (8.6 GB) copied, 108.284 s, 79.3 MB/s

Besides from the fact that the write performance overall is really bad, what can cause this huge gap in performance. The gap is consistent over several runs.

For comparison, I've got a 3rd server as well with 2x2TB SATA disks.

host01:/tmp# dd bs=1M count=8192 if=/dev/zero of=testfile conv=fdatasync
8192+0 records in
8192+0 records out
8589934592 bytes (8.6 GB) copied, 49.0217 s, 175 MB/s

What have I done?

  • Validated that disk partitions are aligned (parted > align-check opt n)
  • fstrim -v / (fails on 2nd server, succeeds on 1st server)
  • blockdev --getbsz [partition] gives a block size of 4096 (default, I believe)
  • Mounted drives with defaults,errors=remount-ro in /etc/fstab

What (more) can I do to improve write performance on these systems?

Improve this question
9
  • What are the disk controllers?
    – Chopper3
    May 27, 2016 at 13:17
  • @Chopper3 added details about controller.
    – sbrattla
    May 27, 2016 at 14:15
  • where?............
    – Chopper3
    May 27, 2016 at 15:27
  • @Chopper3 : almost at the top of my post. Isn't c610/x99 series the controller? It's a software raid, so there is no RAID controller involved.
    – sbrattla
    May 27, 2016 at 15:43
  • Ah, couldn't see if for some reason! it's software RAID, so you're writing everything twice, even more reason that the consumer disk would be slower
    – Chopper3
    May 28, 2016 at 17:50

2 Answers 2

Reset to default
1

The difference is the SSD's drive used. It exist enterprise grad model and 'client' model.

For enterprise grad model you can expect a longer life, and a better algorith to be sure it will run for the 5 years.

I give an example, in enterprise I seen last week SSD for a SAN, they were sold at around 3K$ each for 500gb only.

1st server (2 x SAMSUNG MZ7TE512)

Meet the 24/7 demands of data center and enterprise storage with Samsung SSD.

2nd server (2 x SAMSUNG MZ7LN512)

Samsung's Client Edition Solid-State Drives (SSDs)

Improve this answer
3
  • I agree that I should expect some difference, but the write performance of the 2nd server is worse than the write performance of the SATA RAID1. I am surprised to see SSDs with much worse performance than SATA disks.
    – sbrattla
    May 27, 2016 at 13:16
  • 1
    @sbrattla If the server are identical (same controller) and not in prod, switch the SSD from server and test again, if the IO stat follow, it point to the disk.
    – yagmoth555 ♦
    May 27, 2016 at 13:26
  • I don't have physical access to these servers so I can't switch any disks...
    – sbrattla
    May 27, 2016 at 13:27
0

Are they new SSDs? If not, do a low level clean up. Not sure on the official term for it... some sites say to do a secure erase. You want to remove all the wear leveling and other data from the device. The manufacturer of your specific SSD is where you should get the tool for it. But maybe just doing fstrim will do something similar if the SSD firmware is smart enough.

This is related to TRIM... trim writes the same data, but slow writing could be because of too few TRIMs in the past. But unless you set -o discard on the mount options, you aren't actually doing any TRIM related operation during your test. (and the better way is to use the fstrim command, eg. once per week, rather than discard which does it far more often).

And I think sometimes TRIM can break things when the firmware is bad. See https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/

Also, 223 MB/s might be normal for some configurations... particularly slow SSDs, or slow controllers like SATA 3Gbps maybe, or something you did wrong with raid, like the alignment of the fs blocks, raid chunk size, partition start sector. 80 MB/s is surprising, but I have heard of some SSDs like this until getting cleaned up.

Improve this answer
3
  • 1
    ps. I disagree with yagmoth555 that a client model should ever go as slow as 80 MB/s with your overly simplistic test of sequential zeros with only one sync forced at the very end (fdatasync rather than sync)
    – Peter
    May 27, 2016 at 13:18
  • My point was more the question tell that both servers are identical, but no, they are not as it's not the same model used. I agree the IO are terrible, but sadly it could be simply a bad bunch of disk
    – yagmoth555 ♦
    May 27, 2016 at 13:24
  • @Peter Imagine if one drive had to do an erase for very write and other had a sufficient pool of erased blocks that no erases were needed. That could easily account for the performance difference.
    – David Schwartz
    May 27, 2016 at 16:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .