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
Pavel
On 04/09/2018 02:47 PM, Simon Slavin wrote:
On 9 Apr 2018, at 8:41am, Pavel Cernohorsky <pavel.cernohor...@appeartv.com>
wrote:
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.
Simon.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
