• SSD seems very slow - How to fix?


    Hi again,

    I’m experiencing a big performance issue: if a program does a lot of writing to the disk, my machine slows down a lot. It even becomes unresponsive for some minutes. For example, if I’m install a big package or copying a lot files (~ 1GB+ ).

    Because there is this relation between performance and disk-writing, I did a small benchmark with dd. According to results from other people, my harddrive performance indeed pretty poor, especially in writing.

    I didn’t had this performance problem in my previous Fedora install, so I guess it’s a software problem?

    Does anyone has an idea, on how I get better SSD performance? Or at least stop antergos from becoming unresponsive during disk-activity?

    Thanks!

    Details of Benchmark

    Write

     $ dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc
     1024+0 Datensätze ein
     1024+0 Datensätze aus
     1073741824 Bytes (1,1 GB) kopiert, 53,1188 s, 20,2 MB/s
    

    Read (buffer cleaned)

    $ dd if=tempfile of=/dev/null bs=1M count=1024
    1024+0 Datensätze ein
    1024+0 Datensätze aus
    1073741824 Bytes (1,1 GB) kopiert, 6,27428 s, 171 MB/s
    

    Re-Read (from buffer)

     $ dd if=tempfile of=/dev/null bs=1M count=1024
    1024+0 Datensätze ein  
    1024+0 Datensätze aus
    1073741824 Bytes (1,1 GB) kopiert, 0,29896 s, 3,6 GB/s
    

    SSD-Info

    ATA device, with non-removable media
    	Model Number:       OCZ-AGILITY3                            
    	Serial Number:      OCZ-G1WR4245C7WP8N3A
    	Firmware Revision:  2.15    
    	Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
    Standards:
    	Used: unknown (minor revision code 0x0110) 
    	Supported: 8 7 6 5 
    	Likely used: 8
    Configuration:
    	Logical		max	current
    	cylinders	16383	16383
    	heads		16	16
    	sectors/track	63	63
    	--
    	CHS current addressable sectors:   16514064
    	LBA    user addressable sectors:  234441648
    	LBA48  user addressable sectors:  234441648
    	Logical  Sector size:                   512 bytes
    	Physical Sector size:                   512 bytes
    	Logical Sector-0 offset:                  0 bytes
    	device size with M = 1024*1024:      114473 MBytes
    	device size with M = 1000*1000:      120034 MBytes (120 GB)
    	cache/buffer size  = unknown
    	Nominal Media Rotation Rate: Solid State Device
    Capabilities:
    	LBA, IORDY(can be disabled)
    	Queue depth: 32
    	Standby timer values: spec'd by Standard, no device specific minimum
    	R/W multiple sector transfer: Max = 16	Current = 16
    	Advanced power management level: 254
    	DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
    	     Cycle time: min=120ns recommended=120ns
    	PIO: pio0 pio1 pio2 pio3 pio4 
    	     Cycle time: no flow control=120ns  IORDY flow control=120ns
    Commands/features:
    	Enabled	Supported:
    	   *	SMART feature set
    	    	Security Mode feature set
    	   *	Power Management feature set
    	   *	Write cache
    	    	Look-ahead
    	   *	Host Protected Area feature set
    	   *	WRITE_BUFFER command
    	   *	READ_BUFFER command
    	   *	NOP cmd
    	   *	DOWNLOAD_MICROCODE
    	   *	Advanced Power Management feature set
    	    	Power-Up In Standby feature set
    	   *	SET_FEATURES required to spinup after power up
    	   *	48-bit Address feature set
    	   *	Mandatory FLUSH_CACHE
    	   *	FLUSH_CACHE_EXT
    	   *	SMART error logging
    	   *	SMART self-test
    	   *	General Purpose Logging feature set
    	   *	WRITE_{DMA|MULTIPLE}_FUA_EXT
    	   *	64-bit World wide name
    	   *	IDLE_IMMEDIATE with UNLOAD
    	    	Write-Read-Verify feature set
    	   *	WRITE_UNCORRECTABLE_EXT command
    	   *	{READ,WRITE}_DMA_EXT_GPL commands
    	   *	Segmented DOWNLOAD_MICROCODE
    	   *	Gen1 signaling speed (1.5Gb/s)
    	   *	Gen2 signaling speed (3.0Gb/s)
    	   *	Gen3 signaling speed (6.0Gb/s)
    	   *	Native Command Queueing (NCQ)
    	   *	Host-initiated interface power management
    	   *	Phy event counters
    	   *	Device automatic Partial to Slumber transitions
    	   *	READ_LOG_DMA_EXT equivalent to READ_LOG_EXT
    	   *	DMA Setup Auto-Activate optimization
    	    	Device-initiated interface power management
    	   *	Software settings preservation
    	   *	SMART Command Transport (SCT) feature set
    	   *	SCT Data Tables (AC5)
    	   *	DOWNLOAD MICROCODE DMA command
    	   *	SET MAX SETPASSWORD/UNLOCK DMA commands
    	   *	WRITE BUFFER DMA command
    	   *	READ BUFFER DMA command
    	   *	Data Set Management TRIM supported (limit 1 block)
    	   *	Deterministic read data after TRIM
    Security: 
    	Master password revision code = 65534
    		supported
    	not	enabled
    	not	locked
    		frozen
    	not	expired: security count
    	not	supported: enhanced erase
    	2min for SECURITY ERASE UNIT. 
    Logical Unit WWN Device Identifier: 5e83a97e9abf2cff
    	NAA		: 5
    	IEEE OUI	: e83a97
    	Unique ID	: e9abf2cff
    Checksum: correct
  • @Jacky-B. said:

    OCZ-AGILITY3

    Looks like your drive’s firware version is more than a few versions behind the latest. I recommend that you update to the latest version. You can find it here:

    http://ocz.com/consumer/download

    There is also a PKGBUILD in the AUR for the OCZ Toolbox software which is used to install firmware updates:

    https://aur.archlinux.org/packages/ocztoolbox/

    Cheers!

  • @Jacky-B
    Have you enabled TRIM for your SSD. This sounds like maybe you haven’t and your symptoms are exactly what you would see if the drive was not being trimmed. If you haven’t enabled trim, then my recommendation would be to have the drive trimmed on a weekly schedule.
    https://wiki.archlinux.org/index.php/Solid_State_Drives#TRIM

    If you’re not seeing the performance that you want after trimming the drive, it might be to the point where a wipe and refresh of the cells thus resetting the drive to its factory state might help. There are various ways to do this, and this is different than just writing 0’s to the drive!!! Do NOT just DD or DBAN (Darik’s Boot and Nuke) to wipe an SSD drive. DON’T do it, they work differently compared to spinning drives. Wiping a drive or installing new operating systems will not increase the performance of the drive unless the drive is being trimmed. I think fedora has a weekly trim setup by default and could be why you never experienced the issue.

    Also note: Raid and drive encryption will require extra work and setup to get it to function properly and will depend on your implementation.

    Hope this helps

ssd18 performance6 Posts 3Views 1269
Log in to reply