It's an ioDrive. We updated the firmware to the just-released version, 
and it made a WORLD of difference. It's now performing at the level we'd 
expect (which is quite impressive!)

Talking with their performance engineer, they do indeed suggest 
disabling the OS cache in some cases. We haven't gone that route yet to 
see what happens.


Ken wrote:
> Interesting....
> 
> Mind if we ask what the SSD device brand and model is?
> 
> Is it a disk backed type of device with equal memory in front, I recall 
> seeing devices like this about 7 years ago. I'm thinking that the sync call 
> is causing the device to write its memory contents back out to disk (ie to be 
> persisted). Just a thought...
> 
> 
> 
> --- On Wed, 9/23/09, Pavel Ivanov <paiva...@gmail.com> wrote:
> 
>> From: Pavel Ivanov <paiva...@gmail.com>
>> Subject: Re: [sqlite] SQLite database on a certain high-performance "SSD"
>> To: "General Discussion of SQLite Database" <sqlite-users@sqlite.org>
>> Date: Wednesday, September 23, 2009, 11:21 AM
>>> Is the only change the absence
>> of a call to "fsync()" when turning
>>> synchronous off? If so, I can conclusively say that
>> fsync() is very slow
>>> on this storage device.
>> Yes, the only action of synchronous = off is to turn off
>> calls to
>> fsync() which is called at least twice during each commit.
>>
>> Pavel
>>
>> On Wed, Sep 23, 2009 at 11:40 AM, Mark <godef...@gmail.com>
>> wrote:
>>> On a RAID-5 array of 4x SAS disks, turning the sync
>> off made it about 2x
>>> faster, give or take.
>>>
>>> On the "SSD", it was about 150x faster.
>>>
>>> Is the only change the absence of a call to "fsync()"
>> when turning
>>> synchronous off? If so, I can conclusively say that
>> fsync() is very slow
>>> on this storage device.
>>>
>>> Thanks for the suggestion.
>>>
>>> Mark
>>>
>>>
>>> Pavel Ivanov wrote:
>>>> If you execute
>>>>
>>>> pragma synchronous = off;
>>>>
>>>> you'll be able to compare performance with syncs
>> and without them. So
>>>> if you make this comparison on standard spinning
>> disk and on SSD
>>>> you'll see if syncs on SSD indeed extra-ordinary
>> slow.
>>>> Pavel
>>>>
>>>> On Wed, Sep 23, 2009 at 10:09 AM, Mark <godef...@gmail.com>
>> wrote:
>>>>> It's very possible, but I don't know how to
>> tell. Is there an easy way
>>>>> to know if the sync() calls are taking
>> inordinately long?
>>>>> Mark
>>>>>
>>>>>
>>>>> Thomas Briggs wrote:
>>>>>>    Is the sync necessary to commit a
>> transaction slow?  Performance of
>>>>>> that sync depends on the OS, file system,
>> hardwar, etc. IIRC, so IOs
>>>>>> may be fast but it's possible that the
>> syncs are killing you.
>>>>>>    -T
>>>>>>
>>>>>> On Tue, Sep 22, 2009 at 5:14 PM, Mark
>> <godef...@gmail.com>
>> wrote:
>>>>>>> Lothar Scholz wrote:
>>>>>>>> Hello Mark,
>>>>>>>>
>>>>>>>> Tuesday, September 22, 2009,
>> 3:53:48 AM, you wrote:
>>>>>>>> M> I've currently got a loaner
>> high-performance flash-based "SSD" (let's
>>>>>>>> M> just say it doesn't connect
>> to any disk controllers) that I'm testing
>>>>>>>> M> for performance. I've run my
>> application against it, and I believe that
>>>>>>>> M> I should see numbers MUCH
>> higher than I do. When I run my test app on a
>>>>>>>> M> normal SATA 7200 RPM disk, I
>> get a certain performance, and on the "SSD"
>>>>>>>> M> I get about 1/10th that
>> speed. On an array of SAS disks I get numbers
>>>>>>>> M> that are about 5x faster
>> than my SATA disk, so my software itself isn't
>>>>>>>> M> (I believe) the bottleneck.
>>>>>>>>
>>>>>>>> M> I'm wondering if anyone has
>> any tips for "optimizing" for this sort of
>>>>>>>> M> storage solution.
>>>>>>>>
>>>>>>>> Throw it into the trash bin and
>> buy a new one which has a 3rd
>>>>>>>> generation controller and at least
>> 64MB fast cache. The old JMicron
>>>>>>>> controller that many low cost SSD
>> still use was developed for Flash
>>>>>>>> USB sticks.
>>>>>>>>
>>>>>>>> With modern SSD like the latest
>> Samsung should give you at least the
>>>>>>>> same performance as the SATA. If
>> it gets better depends on file size
>>>>>>>> and cache. Are you sure that the
>> SAS RAID Controller is not keeping
>>>>>>>> everything in the controller
>> cache?
>>>>>>> This isn't an "SSD". It's connected
>> directly to the PCI Express bus, and
>>>>>>> "low cost" it certainly is NOT. It's
>> much more valuable than the server
>>>>>>> it's plugged into.
>>>>>>>
>>>>>>> I've run benchmark tests (iometer),
>> and the benchmarks show it's as fast
>>>>>>> as the mfgr says it should be
>> (~700MB/sec read and write bandwidth,
>>>>>>>  >115,000 IOPS) but it performs
>> quite poorly when I run my app on it. I
>>>>>>> can't figure out why.
>>>>>>>
>>>>>>> Mark

_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to