Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Optimized disk write sequence with forced writes [CORE754] #1129

Closed
firebird-automations opened this issue Dec 27, 2004 · 5 comments
Closed

Optimized disk write sequence with forced writes [CORE754] #1129

firebird-automations opened this issue Dec 27, 2004 · 5 comments
Labels
component: engine fix-version: 1.5.0 priority: major type: new feature

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @krilbe

SFID: 1091805#⁠
Submitted By: krilbe

With forced writes, on every transaction commit, the
harddisk can clearly be heard to do a large number of
seeks, i.e. the disk head vibrates for a short period
of time. We're talking a tenth of a second or so, but
still clearly audible.

I suspect that these seeks are one of the biggest
bottlenecks in Firebird write performance. In a batch I
ran it sounded as if about 1/10-1/3 of the time was
spent on harddisk writes when committing a couple of
times/second. Trying a few different commit frequencies
seemed to confirm this.

So, would it be possible to reorder the disk operations
on transaction commit to reduce drive seeks? I.e. first
collect (read) all info required for the commit, put
all writes in a queue, put the entries of the write
queue in DB file offset order or something, and the write?
@firebird-automations
Copy link
Collaborator Author

Commented by: Alice F. Bird (firebirds)

Date: 2005-07-24 16:54
Sender: dimitr
Logged In: YES
user_id=61270

There were no replies, so I consider this tracker item closed.

@firebird-automations
Copy link
Collaborator Author

Commented by: Alice F. Bird (firebirds)

Date: 2005-03-23 13:04
Sender: dimitr
Logged In: YES
user_id=61270

Since v1.5, async writes are controlled by the engine. The
cache manager flushes dirty pages accordingly to
MaxUnflushedWrites and MaxUnflushedWriteTime configuration
parameters. This gives you a compromise between
fast-but-never-flushed (old FW=OFF) and low-but-reliable
(FW=ON) page write mechanisms.

@firebird-automations
Copy link
Collaborator Author

Commented by: Alice F. Bird (firebirds)

Date: 2005-03-23 10:23
Sender: krilbe
Logged In: YES
user_id=1185534

Not quite true. On Win32 we currently have two options:

1. Forced writes with disk thrashing.

2. No forced writes with potentially indefinate delays
before data is actually written to disk (caused by the OS if
I'm correctly informed).

What I'm asking is something inbetween. Option 2 is
acceptable only in very rare cases, but option 1 is in many
cases overly protective. What I want is a third option like
"forced but optimized writes". This option would potentially
cause DB corruption on a power failure or other system crash
in the middle of a commit, but once the commit is done,
there's no problem like in option 2.

What does IB:s group commit do? Could that be implemented in FB?

@firebird-automations
Copy link
Collaborator Author

Commented by: Alice F. Bird (firebirds)

Date: 2005-03-23 10:08
Sender: dimitr
Logged In: YES
user_id=61270

Pages are written in special order to ensure database
consistency. Any other write order breaks this rule, so it's
not acceptable. You'll get the same level of reliability
with async writes, along with better speed.

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Workflow: jira [ 10778 ] => Firebird [ 15172 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
component: engine fix-version: 1.5.0 priority: major type: new feature
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@firebird-automations