I understand that the SQLite tells the OS all the correct things, but as I described earlier, that may just produce way too much IOPS, even if everything in the chain does the correct thing down to the last silicon transistor. That is why I was asking about a way how to go around it by holding part of the newest data in memory only and manually checkpoint (and I hoped WAL will be a way). And I got some very good suggestions earlier.

In my last mail, I have outlined a calculation suggesting the SSD may wear out pretty soon with the described load. Yesterday I have found a way how not to speculate and get some real data - Samsung's Enterprise SSDs which we use provide a diagnostics which measures a real world load and using their drive's SMART capabilities calculates the estimated SSD's lifetime, in other words saying how bad the load really is. It is actually a very useful thing, so if somebody else needs it as well, here is the link: https://www.slideshare.net/SamsungBusinessUSA/using-smart-attributes-to-estimate-enterprise-ssd-lifetime


On 04/09/2018 02:47 PM, Simon Slavin wrote:
On 9 Apr 2018, at 8:41am, Pavel Cernohorsky <pavel.cernohor...@appeartv.com> 

if you use bigger pro-level SSD, you get on a bit less that 1 year.. still not 
good enough. Of course, big unknown in this is the constant representing the 
ability of the SSD controller to merge requests and minimize block re-writes.
If you compiled SQLite with standard options, and have the correct settings for

PRAGMA fullfsync  (Macintosh only)
PRAGMA journal_mode
PRAGMA synchronous

then SQLite tells the operating system all the correct things.

Whether the operating system, the storage driver, and the storage subsystem 
itself do the right things is out of control of software.  Not only can you not 
tell what's being done, but it can change with what looks like a minor change 
in driver or hardware.

sqlite-users mailing list

sqlite-users mailing list

Reply via email to