maria-discuss team mailing list archive

[Jure Sah <dustwolfy@xxxxxxxxx>]

Hi,

It would appear that on a typical webserver, the majority of disk i/o
belongs to the MariaDB database process. It would appear it's mostly
waiting on fsync(), which to my understanding is executed at least once
per commit.

I understand that this is extensively researched in the documentation
and it has to do with the recovery of data in case of an unexpected
server reboot.

The thing is, this has many performance issues because it caps database
performance at whatever the speed of the underlying physical storage is,
even if the changed data fits into the available RAM. It also results in
the circumstance where if anything is impacting performance of the
storage system on the server, this will break MariaDB and cause the
service to go offline (time out), even if there is sufficient RAM in the
machine to continue operating as normal from page cache.

In a typical scenario you have a website which is writing things like
session and page cache data which expires within an hour and would be no
great loss if missing from a backup. Especially if the volume of the
missing data would be 30 seconds (kernel default for committing dirty
pages to disk) and mind you this setting is configurable.

Temporary tables cannot be used in this case, because they are deleted
as soon as the session ends, which is too soon.

Is there a different solution that could be used here?


I've also noticed in the documentation that the options to control fsync
usage are even more limited than in the MySQL server. They are also very
strongly argued against. Considering the point that InnoDB is considered
to be in an inconsistent state in any event, so long as the server is
not cleanly stopped, is there really justification for such strong
opposition here?

Disabling fsync boosts performance of a typical MySQL server by
something like a factor of 3.

LP,
Jure

Attachment: signature.asc
Description: OpenPGP digital signature