Skip to contentSkip to conversation

sync guest calls made async on host - SQLite performance

DISCUSSION Matthew Tippett 3 participants 11 messages Sep 23, 2009 – Sep 29, 2009 KVM

lore
Share & tools
lore
#0 lore raw

Hi,

I would like to call attention to the SQLite performance under KVM in the current Ubuntu Alpha.

http://www.phoronix.com/scan.php?page=article&item=linux_2631_kvm&num=3

SQLite's benchmark as part of the Phoronix Test Suite is typically IO limited and is affected by both disk and filesystem performance.

When comparing SQLite under the host against the guest OS, there is an order of magnitude _IMPROVEMENT_ in the measured performance of the guest.

I am expecting that the host is doing synchronous IO operations but somewhere in the stack the calls are ultimately being made asynchronous or at the very least batched for writing.

On the surface, this represents a data integrity issue and I am interested in the KVM communities thoughts on this behaviour. Is it expected? Is it acceptable? Is it safe?

Regards,

Matthew

#1 lore raw
Quoted 6 lines · Matthew Tippett

Hi,

I would like to call attention to the SQLite performance under KVM in the current Ubuntu Alpha.

http://www.phoronix.com/scan.php?page=article&item=linux_2631_kvm&num=3

Quoted 7 lines

SQLite's benchmark as part of the Phoronix Test Suite is typically IO limited and is affected by both disk and filesystem performance.

When comparing SQLite under the host against the guest OS, there is an order of magnitude _IMPROVEMENT_ in the measured performance of the guest.

I am expecting that the host is doing synchronous IO operations but somewhere in the stack the calls are ultimately being made asynchronous or at the very least batched for writing.

On the surface, this represents a data integrity issue and I am interested in the KVM communities thoughts on this behaviour. Is it expected? Is it acceptable? Is it safe?

qemu defaults to write-through caching, so there is no data integrity concern.

Signature · 1 line
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
#2 lore raw

Thanks Avi,

I am still trying to reconcile the your statement with the potential data risks and the numbers observed.

My read of your response is that the guest sees a consistent view - the data is commited to the virtual disk device. Does a synchronous write within the guest trigger a synchronous write of the virtual device within the host?

I don't think offering SQLite users a 10 fold increase in performance with no data integrity risks just by using KVM is a sane proposition.

Regards... Matthew

Quoted 31 lines · Avi Kivity
Quoted 14 lines · Matthew Tippett

Hi,

I would like to call attention to the SQLite performance under KVM in the current Ubuntu Alpha.

http://www.phoronix.com/scan.php?page=article&item=linux_2631_kvm&num=3

SQLite's benchmark as part of the Phoronix Test Suite is typically IO limited and is affected by both disk and filesystem performance.

When comparing SQLite under the host against the guest OS, there is an order of magnitude _IMPROVEMENT_ in the measured performance of the guest.

Quoted 7 lines

I am expecting that the host is doing synchronous IO operations but somewhere in the stack the calls are ultimately being made asynchronous or at the very least batched for writing.

On the surface, this represents a data integrity issue and I am interested in the KVM communities thoughts on this behaviour. Is it expected? Is it acceptable? Is it safe?

qemu defaults to write-through caching, so there is no data integrity concern.

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Signature · 1 line
Sent from my mobile device
#3 lore raw
Quoted 10 lines · Matthew Tippett

Thanks Avi,

I am still trying to reconcile the your statement with the potential data risks and the numbers observed.

My read of your response is that the guest sees a consistent view - the data is commited to the virtual disk device. Does a synchronous write within the guest trigger a synchronous write of the virtual device within the host?

Yes.

Quoted 3 lines

I don't think offering SQLite users a 10 fold increase in performance with no data integrity risks just by using KVM is a sane proposition.

It isn't, my guess is that the test setup is broken somehow.

Signature · 1 line
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
#4 lore raw

The test itself is a simple usage of SQLite. It is stock KVM as available in 2.6.31 on Ubuntu Karmic. So it would be the environment, not the test.

So assuming that KVM upstream works as expected that would leave either 2.6.31 having an issue, or Ubuntu having an issue.

Care to make an assertion on the KVM in 2.6.31? Leaving only Ubuntu's installation.

Can some KVM developers attempt to confirm that a 'correctly' configured KVM will not demonstrate this behaviour?
http://www.phoronix-test-suite.com/ (or is already available in newer distributions of Fedora, openSUSE and Ubuntu.

Regards... Matthew

Quoted 25 lines · Avi Kivity
Quoted 10 lines · Matthew Tippett

Thanks Avi,

I am still trying to reconcile the your statement with the potential data risks and the numbers observed.

My read of your response is that the guest sees a consistent view - the data is commited to the virtual disk device. Does a synchronous write within the guest trigger a synchronous write of the virtual device within the host?

Yes.

Quoted 3 lines

I don't think offering SQLite users a 10 fold increase in performance with no data integrity risks just by using KVM is a sane proposition.

It isn't, my guess is that the test setup is broken somehow.

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Signature · 1 line
Sent from my mobile device
#5 lore raw
Quoted 10 lines · Matthew Tippett

The test itself is a simple usage of SQLite. It is stock KVM as available in 2.6.31 on Ubuntu Karmic. So it would be the environment, not the test.

So assuming that KVM upstream works as expected that would leave either 2.6.31 having an issue, or Ubuntu having an issue.

Care to make an assertion on the KVM in 2.6.31? Leaving only Ubuntu's installation.

kvm has nothing to do with it, it's purely qemu. For a long time qemu has defaulted to write-through cacheing. This can be overridden and maybe that's what Ubuntu or Phoronix do.

Quoted 5 lines

Can some KVM developers attempt to confirm that a 'correctly' configured KVM will not demonstrate this behaviour?
http://www.phoronix-test-suite.com/ (or is already available in newer distributions of Fedora, openSUSE and Ubuntu.

A correctly configured kvm will not demonstrate this behaviour.

Signature · 1 line
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
#6 lore raw

First up, Phoronix hasn't tuned. It's observing the delivered state by an OS vendor. I started with what I believe to be the starting point - KVM.

So the position of the KVM now is that it is either QEMU's configuration or Ubuntu's configuration. No further guidance or suggestions? Note that the prevailing response here does not see the 10 fold sqlite performance with guest vs host as a problem.

I'll move this discussion to qemu then, is there any kvm developers who are willing to maintain this position in a discussion with QEMU?

Regards... Matthew

Quoted 29 lines · Avi Kivity
Quoted 10 lines · Matthew Tippett

The test itself is a simple usage of SQLite. It is stock KVM as available in 2.6.31 on Ubuntu Karmic. So it would be the environment, not the test.

So assuming that KVM upstream works as expected that would leave either 2.6.31 having an issue, or Ubuntu having an issue.

Care to make an assertion on the KVM in 2.6.31? Leaving only Ubuntu's installation.

kvm has nothing to do with it, it's purely qemu. For a long time qemu has defaulted to write-through cacheing. This can be overridden and maybe that's what Ubuntu or Phoronix do.

Quoted 5 lines

Can some KVM developers attempt to confirm that a 'correctly' configured KVM will not demonstrate this behaviour?
http://www.phoronix-test-suite.com/ (or is already available in newer distributions of Fedora, openSUSE and Ubuntu.

A correctly configured kvm will not demonstrate this behaviour.

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Signature · 1 line
Sent from my mobile device
#7 lore raw
Quoted 4 lines · Matthew Tippett

First up, Phoronix hasn't tuned. It's observing the delivered state by an OS vendor. I started with what I believe to be the starting point - KVM.

Quoted 8 lines

So the position of the KVM now is that it is either QEMU's configuration or Ubuntu's configuration. No further guidance or suggestions? Note that the prevailing response here does not see the 10 fold sqlite performance with guest vs host as a problem.

I'll move this discussion to qemu then, is there any kvm developers who are willing to maintain this position in a discussion with QEMU?

I suggest you start at the other end - verify with Ubuntu that their configuration is safe.

Signature · 1 line
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
#10 lore raw
In reply to Matthew Tippett
Quoted 7 lines · Matthew Tippett

Hi,

I would like to call attention to the SQLite performance under KVM in the current Ubuntu Alpha.

http://www.phoronix.com/scan.php?page=article&item=linux_2631_kvm&num=3

SQLite's benchmark as part of the Phoronix Test Suite is typically IO limited and is affected by both disk and filesystem performance.

Gotta love Phoronix's transparent methodology...

Ubuntu's Karmic release has _not_ been released yet. For this particular test, Phoronix was probably using an alpha drop before Ubuntu switched from kvm-84 to qemu-kvm-0.11.0.

Before 0.11.0, there were known issues with qcow2 and it was not recommended for use in production environments. If you read the release notes for 0.10.0, we made this very clear. Because of some performance problems, in 0.10.x we made cache=writeback the default for qcow2. We document this pretty thoroughly. See http://www.qemu.org/qemu-doc.html#SEC10 Some other distros that shipped 0.10.x made cache=none the default in order to ensure data integrity (at the cost of performance).

For 0.11.0, Kevin Wolf has fixed the performance/reliability issues in qcow2 and we now set cache=writethrough for qcow2 by default.

And FWIW, Karmic has been on the 0.11.0 tree now for at least a month.

Regards,

Anthony Liguori

#9 lore raw
In reply to Avi Kivity
Quoted 14 lines · Avi Kivity
Quoted 10 lines · Matthew Tippett

The test itself is a simple usage of SQLite. It is stock KVM as available in 2.6.31 on Ubuntu Karmic. So it would be the environment, not the test.

So assuming that KVM upstream works as expected that would leave either 2.6.31 having an issue, or Ubuntu having an issue.

Care to make an assertion on the KVM in 2.6.31? Leaving only Ubuntu's installation.

kvm has nothing to do with it, it's purely qemu. For a long time qemu has defaulted to write-through cacheing. This can be overridden and maybe that's what Ubuntu or Phoronix do.

Quoted 7 lines
Quoted 5 lines

Can some KVM developers attempt to confirm that a 'correctly' configured KVM will not demonstrate this behaviour?
http://www.phoronix-test-suite.com/ (or is already available in newer distributions of Fedora, openSUSE and Ubuntu.

A correctly configured kvm will not demonstrate this behaviour.

It was a very old kvm version (kvm-84). But of course, the version of kvm is not mentioned on the Phoronix site...

Regards,

Anthony Liguori

#8 lore raw
In reply to Matthew Tippett
Quoted 9 lines · Matthew Tippett

First up, Phoronix hasn't tuned. It's observing the delivered state by an OS vendor. I started with what I believe to be the starting point - KVM.

So the position of the KVM now is that it is either QEMU's configuration or Ubuntu's configuration. No further guidance or suggestions? Note that the prevailing response here does not see the 10 fold sqlite performance with guest vs host as a problem.

Again, this isn't a problem. Ubuntu updated to a newer package and the problem has long been resolved upstream.

Regards,

Anthony Liguori