[SOLVED] SSD IO Issue

phyberoptycs · 2013-04-29 15:51:56

Hello.

I am having issues with a Crucial M4 256GB SATA II SSD I have.

My setup is as follows:
1 HDD - WIndows (has boot partition on it)
1 SSD - Linux (has root and home partitions)

The issue I have is that at times, and I don't know what triggers it, everything becomes really slow. Opening a new program, closing an existing program, or waiting for a program to finish a task all become really slow to the point where chrome or system monitor even starts asking me sometimes if I want to kill the window or wait.
Nothing crashes or anything, it just becomes slow. And if I let the system just sit for a while (maybe an hour or two or three), everything goes back to normal speed.

My suspicions lead me to a SSD that I have installed not too long ago.
(I havent really made any other changes.)

Normally my disk speeds are:

/dev/sdb:
 Timing cached reads:   26178 MB in  2.00 seconds = 13105.49 MB/sec
 Timing buffered disk reads: 670 MB in  3.01 seconds = 222.92 MB/sec

But when one of those slow periods kicks in, it looks like this:

/dev/sdb:
 Timing cached reads:   946 MB in  2.00 seconds = 473.00 MB/sec
 Timing buffered disk reads:  12 MB in  3.07 seconds =   3.91 MB/sec

My fstab:

# 
# /etc/fstab: static file system information
#
# <file system>	<dir>	<type>	<options>	<dump>	<pass>
tmpfs		/tmp	tmpfs	nodev,nosuid	0	0
/dev/sda2 /boot ext4 defaults 0 1
/dev/sdb1 / ext4 defaults,noatime,discard 0 1
/dev/sda5 swap swap defaults 0 0
/dev/sdb2 /home ext4 defaults,noatime,discard 0 1

I have looked through the SSD page on the wiki and I have followed the advice as best as I could.
Usually I can get issues like this fixed, but regarding this one, I dont really know where to even begin.
Could it be that the partitions arent aligned? Or maybe outdated firmware issue?

Any help would be much appreciated.

Thank!

Last edited by phyberoptycs (2013-05-02 06:07:05)

Thorsten Reinbold · 2013-04-30 02:29:31

Afaik the "discard" Option isn't a good choice as it slow down speed because it permanently sends discard commands. You should, if that information is still correct, make a cronjob once a day.

phyberoptycs · 2013-04-30 03:22:58

Hey Thorsten,

That is a change I have made among others.
I will keep seeing if this occurs again.

Either way, I will report back soon. Hopefully no more issues like this. It is really maddening having to wait to close a window....

If anyone else has any advice or happens to know what is going on, please do leave a reply.

Thank you and have a nice day,
Phyber

Thorsten Reinbold · 2013-04-30 03:47:30

I will have a look at this thread, got an Sandisk SSD today.

What I did was creating a little cronjob: /etc/cron.daily/fstrimd

#!/bin/sh

NICE='nice -n 19'
IONICE='ionice -c 2 -n 7'

exec ${IONICE} ${NICE} fstrim /

Maybe this helps you.

Last edited by Thorsten Reinbold (2013-04-30 03:58:01)

phyberoptycs · 2013-04-30 05:01:51

Hey, yeah. I setup a similar cronjob, but something peculiar happens.

When I run:

fstrim -v /

It seems to hang and when I run 'ps aux', it shows that it's in 'Uninterruptible sleep':

root      3521  0.0  0.0   6032   348 pts/1    D+   00:39   0:00 fstrim -v /

So yeah...... I do believe that my issue might hang with trying to use TRIM feature. Basically created the slowness on command (literally, fstrim -v /)

Brings everything to a crawl. Like a toddler crawling on duct tape....

Edit:
And just to put it out there, I have trim support, or so I am told:

[phyber@arch ~]$ sudo hdparm -I /dev/sdb |grep 'TRIM'
	   *	Data Set Management TRIM supported (limit unknown)
	   *	Deterministic read data after TRIM

Edit 2:
So it just finished. IO speed seems to be fine again. Maybe the poor performance is due to running TRIM?

Anyone else experience slow disk IO when trimming is occurring??
( Or is this normal? )

Last edited by phyberoptycs (2013-04-30 05:07:37)

phyberoptycs · 2013-05-02 06:06:43

So, here is an update.

From what I am able to tell, when activating TRIM from fstab, I saw very poor performance at times.
But since switching to a manual solution (cronjob with fstrim), I have yet to experience a single event like before.

So, for those who see a massive decrease in SSD IO performance and are using fstab TRIM (discard), then try switching to a cronjob, like Thorsten's.

Hopefully someone can benefit.

smakked · 2013-05-02 09:06:15

I had the same issue on my Crucial till it died, now running a Samsung 830 with no issue , so it must be the feature on the disk that causes it. Or bad implementation of the feature.

Arch Linux

#1 2013-04-29 15:51:56

[SOLVED] SSD IO Issue

#2 2013-04-30 02:29:31

Re: [SOLVED] SSD IO Issue

#3 2013-04-30 03:22:58

Re: [SOLVED] SSD IO Issue

#4 2013-04-30 03:47:30

Re: [SOLVED] SSD IO Issue

#5 2013-04-30 05:01:51

Re: [SOLVED] SSD IO Issue

#6 2013-05-02 06:06:43

Re: [SOLVED] SSD IO Issue

#7 2013-05-02 09:06:15

Re: [SOLVED] SSD IO Issue

Board footer