Author Topic: AppServer Sub-benchmark Database Durability  (Read 5511 times)

aakel

  • Newbie
  • *
  • Posts: 17
  • Karma: +3/-0
AppServer Sub-benchmark Database Durability
« on: November 08, 2016, 05:05:47 PM »
I noticed that none of the database VM results reported in the SPEC database make any durability guarantees (in fact, the SPECvirt example guide disables synchronous_commit in PostgreSQL).  I assume this is by design, since the Run and Reporting rules only require atomicity, isolation, and consistency support.  This appears to differ from the SPECjAppServer2004 specification, where all four ACID properties are required.  Would anyone mind elaborating as to why durability is not important in this fraction of the benchmark?  Taken to an extreme, a database that retains a consistent state but commits no transactions to disk would meet the requirements for this portion of the benchmark.
« Last Edit: November 09, 2016, 02:10:27 PM by aakel »

ChrisFloyd

  • Moderator
  • Jr. Member
  • *****
  • Posts: 52
  • Karma: +2/-0
Re: AppServer Sub-benchmark Database Durability
« Reply #1 on: November 09, 2016, 02:19:46 PM »
Aakel,

The SPECvirt_sc2013 run and reporting rules do require durability of data on all VMs. (See clause 2.1.2, "...The SUT must utilize stable storage; additionally, stable and durable storage must be used for all VMs as described in SUT Storage.")

The wording relating to the appserver & DB at the end of  Clause 3.1.2.2 - Storage Requirements: "Application and Database servers: The Atomicity, Consistency, and Isolation properties of transaction processing systems must be supported." was intended to clarify that in addition to durability for all VMs, the database has atomicity, consistency, and isolation requirements.

Let me know if you have any further questions.

aakel

  • Newbie
  • *
  • Posts: 17
  • Karma: +3/-0
Re: AppServer Sub-benchmark Database Durability
« Reply #2 on: November 09, 2016, 05:49:29 PM »
Chris,

Thanks for the clarification.  As a result, what's the outlook on the recommended PostgreSQL configuration (via the example setup scripts provided on this forum and from every PostgreSQL setup reported in the SPECvirt 2013 results) which recommends synchronous_commit=off?  This parameter sacrifices durability for the sake of performance, by allowing a database to lose data in the event of a power loss (~200ms of data loss, with the default setting).  Is this an acceptable tradeoff in the eyes of the SPECvirt specification?

Here's a link to one result in question: https://www.spec.org/virt_sc2013/results/res2013q2/virt_sc2013-20130501-00001-perf.html

Thanks.

AnoopGupta

  • Jr. Member
  • **
  • Posts: 60
  • Karma: +0/-0
Re: AppServer Sub-benchmark Database Durability
« Reply #3 on: November 10, 2016, 01:12:56 PM »
Chris,

Thanks for the clarification.  As a result, what's the outlook on the recommended PostgreSQL configuration (via the example setup scripts provided on this forum and from every PostgreSQL setup reported in the SPECvirt 2013 results) which recommends synchronous_commit=off?  This parameter sacrifices durability for the sake of performance, by allowing a database to lose data in the event of a power loss (~200ms of data loss, with the default setting).  Is this an acceptable tradeoff in the eyes of the SPECvirt specification?

Here's a link to one result in question: https://www.spec.org/virt_sc2013/results/res2013q2/virt_sc2013-20130501-00001-perf.html

Thanks.

Thank you for pointing this out. I believe use of synchronous_commit=off has been an oversight. SPECvirt does require all ACID properties to hold. We are aware that for Postgres fsync=on is required, but it was missed that synchronous_commit=on is also needed. We will discuss this issue in the committee, but I do recommend synchronous_commit=on.

aakel

  • Newbie
  • *
  • Posts: 17
  • Karma: +3/-0
Re: AppServer Sub-benchmark Database Durability
« Reply #4 on: November 10, 2016, 02:00:32 PM »
Also, just to point out, the MariaDB (and probably MySQL) configurations posted as validated results are also configured to use asynchronous commits (via innodb_flush_log_at_trx_commit=0).

AnoopGupta

  • Jr. Member
  • **
  • Posts: 60
  • Karma: +0/-0
Re: AppServer Sub-benchmark Database Durability
« Reply #5 on: November 15, 2016, 05:50:55 PM »
Also, just to point out, the MariaDB (and probably MySQL) configurations posted as validated results are also configured to use asynchronous commits (via innodb_flush_log_at_trx_commit=0).

Thanks for pointing it out, very much appreciated. You are correct. The mysql docs do clearly state innodb_flush_log_at_trx_commit should be 1 for full ACID compliance.