Seems about right to me. If I do 1000 inserts on an SQLite database backed on spinning disk with a 32GB Flash Cache it takes 3 seconds. I would expect that (assuming your SSD are using a Connor interface) you would see at least twice that time used for RAID 1.
Is your new Intel RAID driver the IRST? If so, you can configure it to "dangerous" mode under the performance options so that it will lie to you about disk flushes just like the driver on XP did. You may also need to look under the devmgmt.msc options for the volume -- the IRST driver claims the device cache and "turn off windows control of cache flushing" is located in the IRST management app, but it isn't (since it is correct, I have no volatile volumes) -- those options are set against the volume as they were in the old days -- directly at the windows volume level). In my case, setting the "enable device cache" means that writes (from the windows volume cache) return complete when the write to flash is complete but before the data is committed to spinning disk, and the "turn off windows write-cache flushing" means that forced-flush operations do not force the flash to write to spinning disk (or, on a normal cached disk it would disable forcing a flush from the drive RAM cache to the media), since the data is already preserved in the non-volatile cache and will be preserved in case of a power failure. I don't know what sort of device cache your devices have, or whether it is volatile or not. You would have to check with the manufacturer to see how these settings (assuming they are available) affect the actual writing to the non-volatile storage. --- Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. Sometimes theory and practice are combined: nothing works and no one knows why. >-----Original Message----- >From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users- >bounces at mailinglists.sqlite.org] On Behalf Of Rob van der Stel >Sent: Tuesday, 24 March, 2015 09:44 >To: sqlite-users at mailinglists.sqlite.org >Subject: [sqlite] Very poor SQLite performance when using Win8.1 + Intel >RAID1 > >Hello, > >Currently I am investigating a SQLite performance problem that started to >occur when we switched from using Windows XP to Windows 8.1 for our >applications. >The following information is obtained to comparing two hardware identical >systems one running Win XP the other running Win 8.1. > >*** HW specification System 1 and System 2 >--- HP RP5 Retail PC 5810 >--- Intel Celeron G1820 at 2.7 GHz >--- 4096 MB DDR3 / 1333 MHz >--- Intel ICH8R onboard RAID1 with 2 x Samsung 128 GB SSD > >*** SW specification System 1 >--- Windows XP >--- Intel RAID driver 9.5.0.1037 02/10/2009 > >*** SW specification System 2 >--- Windows 8.1 >--- Intel RAID driver 12.5.0.1066 18/03/2013 > > >=>> When running our applications the performance of SQLite write-access >on System2 (Win 8.1) is at least 10 times slower than on System1 (Win >XP). >=>> Investigations have already shown that the Windows API >FlushFileBuffers() plays an important part regarding this issue. > >The following describes a few comparison tests >--- SQLite 1000 x append in new database *) System >1: 1000 - 1100 msec System 2: 10000 - 11000 msec >--- Binary file 1000 x {append + FlushFileBuffers} *) System 1: >220 - 230 msec System 2: 2600 - 2700 msec > >*) The data size of each write is comparable (106 bytes). Final file >sizes also match. > >Has anyone noticed such a dramatic SQLite performance deterioration under >comparable circumstances? If so were you able to find the root cause of >it and tackle the problem by making improvements such that both systems >perform equally well again (other driver software ? other driver >parameters ? ...) > >It is important that we retain the data integrity provisions that are >required for our system (RAID1 and SQLite using FlushFileBuffers). Using >the "SQLITE_NO_SYNC compile option" or the "PRAGMA synchronous = 0" is >therefore no alternative. > >Regards, >Rob > > >This e-mail and any attachments contain material that is confidential for >the sole use of the intended recipient. Any review, reliance or >distribution by others or forwarding without express permission is >strictly prohibited. If you are not the intended recipient, please >contact the sender and delete all copies. > > >This message has been scanned for malware by Websense. www.websense.com >_______________________________________________ >sqlite-users mailing list >sqlite-users at mailinglists.sqlite.org >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
