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 > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
