Author Topic: SlickEdit and SSD storage  (Read 3985 times)

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
SlickEdit and SSD storage
« on: November 17, 2009, 06:14:49 AM »
On one of my main computers I replaced two RAID0 7200 RPM SATA II drives with two RAID0 solid state drives (rated at 260MB/s seq read, 180MB/s seq write).

SlickEdit screams.  No pauses or hiccups.

(Common Sense Warning:  Your Mileage May Vary, Don't Quote Me, etc).

On the one hand, this is great (SE is not why I got the SSDs, but it is a great perk).
On the other hand, it cost me $1,400 so it's not a general solution.

The SlickTeam is working on threading to push more stuff into the background to avoid blocking the foreground.  IO profiling might help things that still need to happen in the foreground.  IO profiling might even turn up non-optimal IO patterns in unexpected places.  It seems large vtgs are often assumed to be the reason for slowness, but it seems like a btree ought to be able to perform extremely well at any size unless it is serving up unindex/unoptimized linear scan queries.  Anyway, IO profiling might reveal other non-vtg places where tweaks could boost performance.  Just a thought.

buggyfunbunny

  • Senior Community Member
  • Posts: 233
  • Hero Points: 4
Re: SlickEdit and SSD storage
« Reply #1 on: November 17, 2009, 02:49:38 PM »
On one of my main computers I replaced two RAID0 7200 RPM SATA II drives with two RAID0 solid state drives (rated at 260MB/s seq read, 180MB/s seq write).

SlickEdit screams.  No pauses or hiccups.

(Common Sense Warning:  Your Mileage May Vary, Don't Quote Me, etc).

On the one hand, this is great (SE is not why I got the SSDs, but it is a great perk).
On the other hand, it cost me $1,400 so it's not a general solution.

The SlickTeam is working on threading to push more stuff into the background to avoid blocking the foreground.  IO profiling might help things that still need to happen in the foreground.  IO profiling might even turn up non-optimal IO patterns in unexpected places.  It seems large vtgs are often assumed to be the reason for slowness, but it seems like a btree ought to be able to perform extremely well at any size unless it is serving up unindex/unoptimized linear scan queries.  Anyway, IO profiling might reveal other non-vtg places where tweaks could boost performance.  Just a thought.

SSD has been one of my interests (in the database world, not so much standalone PC).  Which ones did you get?  Intel is reviewed as "best".  And are you running linux?

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
Re: SlickEdit and SSD storage
« Reply #2 on: November 17, 2009, 10:28:58 PM »
Patriot Torqx 256GB (Torqx, not M28 or Warp), 1571 firmware, with an Intel RAID controller.
Running on Windows 2008 R2 (i.e. Windows 7 Server).

Intel has a bit lower write speed, but more importantly (in my case) Intel does not yet have a 256GB unit.

Neither the wiper.exe tool nor TRIM can currently penetrate through the RAID controller.  Word is that Intel has a RAID controller firmware update in the works to address that.  Hopefully performance will not degrade significantly before the firmware stars align -- without updated firmware the only way to restore performance on a RAIDed SSD is to wipe the drive and reinstall.  But degraded SSD performance is still well above spindle drive performance, so...  /shrug