You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Mike Matrigali (JIRA)" <de...@db.apache.org> on 2006/01/28 18:38:33 UTC
[jira] Created: (DERBY-888) improve performance of page allocation
improve performance of page allocation
--------------------------------------
Key: DERBY-888
URL: http://issues.apache.org/jira/browse/DERBY-888
Project: Derby
Type: Improvement
Reporter: Mike Matrigali
Assigned to: Mike Matrigali
Priority: Minor
Improve performance of page allocation by no longer requiring sync of the allocated pages. The reason for the sync
currently is so that during redo recovery we did not have to handle the case of redoing the allocate and finding no space
available on the disk. During tasks like single user load this sync allocation is a significant performance issue - in the
case where one does 1000 insert per transaction the total time aproaches very close to durability=test where no syncing
is done in the whole system.
For instance in a test of loading a 150 meg db with a number of tables and indexes, on a 1.7 ghz laptop with one ide disk,
sun jdk1.4.2, windows XP
i got the following types of results:
default system: 6 minutes
no alloc sync: 1 minute, 43 seconds
no syncing: 1 minute , 1 second
Once syncing is disabled then recovery must be enhanced to handle the possible out of space condition. Recovery already
handles out of space during undo, so this will just handle the error the same as that. It will stop recovery and produce an error
indicating that user must add disk space and rerun recovery before system can be brought online. I actually think on most
JVM's/OS's this won't happen as the system will still be asking the JVM/OS for the space, just not syncing the values in those
pages to disk. Most OS's at this point will reserve the space in the file tables and not let others grab that space.
This project will make sure that out of space recovery path has tests. It will also make sure that redo recovery encountering garbage
in a newly allocated page during redo of an create page is tested.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Created: (DERBY-888) improve performance of page allocation
Posted by Daniel John Debrunner <dj...@apache.org>.
Suresh wrote:
>> Without sync on allocation, How to make sure recovery never sees good
>> old page on a new allocation because some OS/Hardware does zero out a
>> new page to a file that was used earlier by the same file or some
>> other file ?. I think in most generic Operating Systems one will never
>> give the user a old page on new page allocation to the file. But I am
>> not sure how it works on small devices with FLASH memory ..etc.
Giving back old data would be a security hole in a multi-user operating
system, so it *should* not happen there. Though, as you say, it could be
a possibility in a simple os.
Dan.
Re: [jira] Created: (DERBY-888) improve performance of page allocation
Posted by Mike Matrigali <mi...@sbcglobal.net>.
thanks, I was writing from memory - I'll check the code. My plan is to
make sure any exception during that phase of rollforward, while getting
the page during redo for the purpose of redoing the initialization of
the page goes through the existing path of just creating a new page if
it did not exist.
Basically for "garbage" I expect either a bad checksum or bad format id
exception. I'll make sure to add these test cases.
Your second point I am having a harder time with. If the "random" bits
found on disk happen to map to a valid checksum'd page which isn't the
right one, there will be a problem. At this point I think I would
consider it a bug in the OS to return data on a page that we never wrote
- and seems ok to assume this won't happen. The code will handle all
cases of this bug except when the page of data happens to be a valid
derby page.
Suresh Thalamati wrote:
> I am not sure rollforward recovery fixes a page if there is a garbage on
> the page. I think there is a small difference between the rollforward
> from backup and the not syncing on allocation case u are trying to
> handle. During rollforward recovery from the backup , redo is happening
> on the the container from the backup. During redo if page is not found
> means it was not allocated before, so it just goes and creates new page
> and does a sync. I think rollforward recovery will never see a garbage
> or a old valid page.
>
> Without sync on allocation, How to make sure recovery never sees good
> old page on a new allocation because some OS/Hardware does zero out a
> new page to a file that was used earlier by the same file or some other
> file ?. I think in most generic Operating Systems one will never give
> the user a old page on new page allocation to the file. But I am not
> sure how it works on small devices with FLASH memory ..etc.
>
>
> Thanks
> -suresht
>
> Mike Matrigali wrote:
>
>> This first step is not going all the way to buffering with no
>> file system interaction. The system is still going to request
>> the space from the file before allowing the insert. In java
>> the way you do this is write the file to the OS. What I am
>> changing is that we use to sync the empty page. This means the
>> user will get the normal immediate feedback if it is his inserts
>> that cause the filesystem to fill up.
>>
>> The current system already has the sync every 8 page optimization,
>> rather than every page. (I think it actually sync's every page
>> until there are 8 and then does 8 at a time - a left over from
>> when it was important to conserve disk space for running on small
>> systems and many apps had tables less than 8 pages). I considered
>> some sort of dynamic changing of the preallocate size, but it
>> seemed too complicated - and the bigger the preallocate grew
>> the more likely we would grow the file TOO much.
>>
>> As you say the sync every N seconds is like a checkpoint. In
>> the current system checkpoint will sync every file so the sync
>> will happen at that point no matter what.
>>
>> We did the sync for 2 reasons. One was that we use to not be
>> able to handle redo recovery of version 0 of the page if the
>> system read "garbage" from the disk. This was fixed by
>> requirements of recent rollforward recovery project. The
>> system can now handle redo where it reads
>> garbage from disk while creating version 0 of the page, and
>> it also handles if trying to read page and finds it needs
>> to extend the file.
>>
>> The second is that we guessed that some OS might require the
>> sync to insure the space on disk. There is no info one way or
>> the other in the JVM documentation so it was just a guess on
>> our part. My belief is that the write call we are doing will
>> force the OS to allocate the space to our file, and no other
>> file will be able use that space, so the space is ours until
>> OS/machine crashes at least.
>>
>> I think in general users will almost never see out of space
>> during redo recovery. I think it might take an OS crash,
>> on an OS with no filesystem logging, and a subsequent process
>> using up al the disk space on the machine before derby gets
>> to run redo.
>>
>> So the upside is inserts go much faster. The downside is that
>> in some rare (and maybe on some/most OS's never) cases the user
>> will see an out of disk space message during database boot that
>> tells him that he has to free up some disk space. The system
>> will boot once the disk space is available. This error exists
>> today if the disk is full, and undo needs to write some CLR's -
>> so the error isn't even new for derby.
>>
>>
>>
>> Bryan Pendleton wrote:
>>
>>> Mike Matrigali (JIRA) wrote:
>>>
>>>> ... the total time aproaches very close to durability=test ...
>>>
>>>
>>>
>>>
>>> Wow! This is great; looks like a very big win. Cool!
>>>
>>> I had two questions:
>>>
>>> 1) It seems like a really common scenario would be:
>>> - a single enormous "batch" application is trying to insert
>>> many, many rows into a table.
>>> - there's enough room in memory, so we just buffer up a bunch
>>> of pages in the cache and let the application insert as it pleases.
>>> - the application completes, and commits,
>>> - then we discover there's not enough space on the disk.
>>>
>>> Is this the problem you're trying to solve?
>>>
>>> If so, I'm a little confused as to what the "external view" of the
>>> system will be -- how will the user know that the disk has become
>>> full and that space needs to be added?
>>>
>>> 2) Is there any advantage that you can see to have some sort of
>>> intermediate behavior in between the extremes of:
>>> - always sync every freshly allocated page, and
>>> - never sync freshly allocated pages
>>>
>>> For example, is there any point in a "sync every N pages", or
>>> "sync every N seconds"? (I guess the latter is sort of like a
>>> checkpoint?)
>>>
>>> thanks,
>>>
>>> bryan
>>>
>>>
>>>
>>>
>>
>>
>
>
>
Re: [jira] Created: (DERBY-888) improve performance of page allocation
Posted by Suresh Thalamati <su...@gmail.com>.
I am not sure rollforward recovery fixes a page if there is a garbage
on the page. I think there is a small difference between the
rollforward from backup and the not syncing on allocation case u are
trying to handle. During rollforward recovery from the backup , redo
is happening on the the container from the backup. During redo if
page is not found means it was not allocated before, so it just goes
and creates new page and does a sync. I think rollforward recovery
will never see a garbage or a old valid page.
Without sync on allocation, How to make sure recovery never sees good
old page on a new allocation because some OS/Hardware does zero out a
new page to a file that was used earlier by the same file or some
other file ?. I think in most generic Operating Systems one will never
give the user a old page on new page allocation to the file. But I am
not sure how it works on small devices with FLASH memory ..etc.
Thanks
-suresht
Mike Matrigali wrote:
> This first step is not going all the way to buffering with no
> file system interaction. The system is still going to request
> the space from the file before allowing the insert. In java
> the way you do this is write the file to the OS. What I am
> changing is that we use to sync the empty page. This means the
> user will get the normal immediate feedback if it is his inserts
> that cause the filesystem to fill up.
>
> The current system already has the sync every 8 page optimization,
> rather than every page. (I think it actually sync's every page
> until there are 8 and then does 8 at a time - a left over from
> when it was important to conserve disk space for running on small
> systems and many apps had tables less than 8 pages). I considered
> some sort of dynamic changing of the preallocate size, but it
> seemed too complicated - and the bigger the preallocate grew
> the more likely we would grow the file TOO much.
>
> As you say the sync every N seconds is like a checkpoint. In
> the current system checkpoint will sync every file so the sync
> will happen at that point no matter what.
>
> We did the sync for 2 reasons. One was that we use to not be
> able to handle redo recovery of version 0 of the page if the
> system read "garbage" from the disk. This was fixed by
> requirements of recent rollforward recovery project. The
> system can now handle redo where it reads
> garbage from disk while creating version 0 of the page, and
> it also handles if trying to read page and finds it needs
> to extend the file.
>
> The second is that we guessed that some OS might require the
> sync to insure the space on disk. There is no info one way or
> the other in the JVM documentation so it was just a guess on
> our part. My belief is that the write call we are doing will
> force the OS to allocate the space to our file, and no other
> file will be able use that space, so the space is ours until
> OS/machine crashes at least.
>
> I think in general users will almost never see out of space
> during redo recovery. I think it might take an OS crash,
> on an OS with no filesystem logging, and a subsequent process
> using up al the disk space on the machine before derby gets
> to run redo.
>
> So the upside is inserts go much faster. The downside is that
> in some rare (and maybe on some/most OS's never) cases the user
> will see an out of disk space message during database boot that
> tells him that he has to free up some disk space. The system
> will boot once the disk space is available. This error exists
> today if the disk is full, and undo needs to write some CLR's -
> so the error isn't even new for derby.
>
>
>
> Bryan Pendleton wrote:
>
>> Mike Matrigali (JIRA) wrote:
>>
>>> ... the total time aproaches very close to durability=test ...
>>
>>
>>
>> Wow! This is great; looks like a very big win. Cool!
>>
>> I had two questions:
>>
>> 1) It seems like a really common scenario would be:
>> - a single enormous "batch" application is trying to insert
>> many, many rows into a table.
>> - there's enough room in memory, so we just buffer up a bunch
>> of pages in the cache and let the application insert as it pleases.
>> - the application completes, and commits,
>> - then we discover there's not enough space on the disk.
>>
>> Is this the problem you're trying to solve?
>>
>> If so, I'm a little confused as to what the "external view" of the
>> system will be -- how will the user know that the disk has become
>> full and that space needs to be added?
>>
>> 2) Is there any advantage that you can see to have some sort of
>> intermediate behavior in between the extremes of:
>> - always sync every freshly allocated page, and
>> - never sync freshly allocated pages
>>
>> For example, is there any point in a "sync every N pages", or
>> "sync every N seconds"? (I guess the latter is sort of like a
>> checkpoint?)
>>
>> thanks,
>>
>> bryan
>>
>>
>>
>>
>
>
Re: [jira] Created: (DERBY-888) improve performance of page allocation
Posted by Mike Matrigali <mi...@sbcglobal.net>.
This first step is not going all the way to buffering with no
file system interaction. The system is still going to request
the space from the file before allowing the insert. In java
the way you do this is write the file to the OS. What I am
changing is that we use to sync the empty page. This means the
user will get the normal immediate feedback if it is his inserts
that cause the filesystem to fill up.
The current system already has the sync every 8 page optimization,
rather than every page. (I think it actually sync's every page
until there are 8 and then does 8 at a time - a left over from
when it was important to conserve disk space for running on small
systems and many apps had tables less than 8 pages). I considered
some sort of dynamic changing of the preallocate size, but it
seemed too complicated - and the bigger the preallocate grew
the more likely we would grow the file TOO much.
As you say the sync every N seconds is like a checkpoint. In
the current system checkpoint will sync every file so the sync
will happen at that point no matter what.
We did the sync for 2 reasons. One was that we use to not be
able to handle redo recovery of version 0 of the page if the
system read "garbage" from the disk. This was fixed by
requirements of recent rollforward recovery project. The
system can now handle redo where it reads
garbage from disk while creating version 0 of the page, and
it also handles if trying to read page and finds it needs
to extend the file.
The second is that we guessed that some OS might require the
sync to insure the space on disk. There is no info one way or
the other in the JVM documentation so it was just a guess on
our part. My belief is that the write call we are doing will
force the OS to allocate the space to our file, and no other
file will be able use that space, so the space is ours until
OS/machine crashes at least.
I think in general users will almost never see out of space
during redo recovery. I think it might take an OS crash,
on an OS with no filesystem logging, and a subsequent process
using up al the disk space on the machine before derby gets
to run redo.
So the upside is inserts go much faster. The downside is that
in some rare (and maybe on some/most OS's never) cases the user
will see an out of disk space message during database boot that
tells him that he has to free up some disk space. The system
will boot once the disk space is available. This error exists
today if the disk is full, and undo needs to write some CLR's -
so the error isn't even new for derby.
Bryan Pendleton wrote:
> Mike Matrigali (JIRA) wrote:
>
>> ... the total time aproaches very close to durability=test ...
>
>
> Wow! This is great; looks like a very big win. Cool!
>
> I had two questions:
>
> 1) It seems like a really common scenario would be:
> - a single enormous "batch" application is trying to insert
> many, many rows into a table.
> - there's enough room in memory, so we just buffer up a bunch
> of pages in the cache and let the application insert as it pleases.
> - the application completes, and commits,
> - then we discover there's not enough space on the disk.
>
> Is this the problem you're trying to solve?
>
> If so, I'm a little confused as to what the "external view" of the
> system will be -- how will the user know that the disk has become
> full and that space needs to be added?
>
> 2) Is there any advantage that you can see to have some sort of
> intermediate behavior in between the extremes of:
> - always sync every freshly allocated page, and
> - never sync freshly allocated pages
>
> For example, is there any point in a "sync every N pages", or
> "sync every N seconds"? (I guess the latter is sort of like a checkpoint?)
>
> thanks,
>
> bryan
>
>
>
>
Re: [jira] Created: (DERBY-888) improve performance of page allocation
Posted by Bryan Pendleton <bp...@amberpoint.com>.
Mike Matrigali (JIRA) wrote:
> ... the total time aproaches very close to durability=test ...
Wow! This is great; looks like a very big win. Cool!
I had two questions:
1) It seems like a really common scenario would be:
- a single enormous "batch" application is trying to insert
many, many rows into a table.
- there's enough room in memory, so we just buffer up a bunch
of pages in the cache and let the application insert as it pleases.
- the application completes, and commits,
- then we discover there's not enough space on the disk.
Is this the problem you're trying to solve?
If so, I'm a little confused as to what the "external view" of the
system will be -- how will the user know that the disk has become
full and that space needs to be added?
2) Is there any advantage that you can see to have some sort of
intermediate behavior in between the extremes of:
- always sync every freshly allocated page, and
- never sync freshly allocated pages
For example, is there any point in a "sync every N pages", or
"sync every N seconds"? (I guess the latter is sort of like a checkpoint?)
thanks,
bryan
[jira] Resolved: (DERBY-888) improve performance of page allocation
Posted by "Mike Matrigali (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-888?page=all ]
Mike Matrigali resolved DERBY-888:
----------------------------------
Fix Version: 10.2.0.0
Resolution: Fixed
> improve performance of page allocation
> --------------------------------------
>
> Key: DERBY-888
> URL: http://issues.apache.org/jira/browse/DERBY-888
> Project: Derby
> Type: Improvement
> Reporter: Mike Matrigali
> Assignee: Mike Matrigali
> Priority: Minor
> Fix For: 10.2.0.0
>
> Improve performance of page allocation by no longer requiring sync of the allocated pages. The reason for the sync
> currently is so that during redo recovery we did not have to handle the case of redoing the allocate and finding no space
> available on the disk. During tasks like single user load this sync allocation is a significant performance issue - in the
> case where one does 1000 insert per transaction the total time aproaches very close to durability=test where no syncing
> is done in the whole system.
> For instance in a test of loading a 150 meg db with a number of tables and indexes, on a 1.7 ghz laptop with one ide disk,
> sun jdk1.4.2, windows XP
> i got the following types of results:
> default system: 6 minutes
> no alloc sync: 1 minute, 43 seconds
> no syncing: 1 minute , 1 second
> Once syncing is disabled then recovery must be enhanced to handle the possible out of space condition. Recovery already
> handles out of space during undo, so this will just handle the error the same as that. It will stop recovery and produce an error
> indicating that user must add disk space and rerun recovery before system can be brought online. I actually think on most
> JVM's/OS's this won't happen as the system will still be asking the JVM/OS for the space, just not syncing the values in those
> pages to disk. Most OS's at this point will reserve the space in the file tables and not let others grab that space.
> This project will make sure that out of space recovery path has tests. It will also make sure that redo recovery encountering garbage
> in a newly allocated page during redo of an create page is tested.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-888) improve performance of page allocation
Posted by "Mike Matrigali (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-888?page=all ]
Mike Matrigali closed DERBY-888:
--------------------------------
> improve performance of page allocation
> --------------------------------------
>
> Key: DERBY-888
> URL: http://issues.apache.org/jira/browse/DERBY-888
> Project: Derby
> Type: Improvement
> Components: Store
> Reporter: Mike Matrigali
> Assignee: Mike Matrigali
> Priority: Minor
> Fix For: 10.2.0.0
>
> Improve performance of page allocation by no longer requiring sync of the allocated pages. The reason for the sync
> currently is so that during redo recovery we did not have to handle the case of redoing the allocate and finding no space
> available on the disk. During tasks like single user load this sync allocation is a significant performance issue - in the
> case where one does 1000 insert per transaction the total time aproaches very close to durability=test where no syncing
> is done in the whole system.
> For instance in a test of loading a 150 meg db with a number of tables and indexes, on a 1.7 ghz laptop with one ide disk,
> sun jdk1.4.2, windows XP
> i got the following types of results:
> default system: 6 minutes
> no alloc sync: 1 minute, 43 seconds
> no syncing: 1 minute , 1 second
> Once syncing is disabled then recovery must be enhanced to handle the possible out of space condition. Recovery already
> handles out of space during undo, so this will just handle the error the same as that. It will stop recovery and produce an error
> indicating that user must add disk space and rerun recovery before system can be brought online. I actually think on most
> JVM's/OS's this won't happen as the system will still be asking the JVM/OS for the space, just not syncing the values in those
> pages to disk. Most OS's at this point will reserve the space in the file tables and not let others grab that space.
> This project will make sure that out of space recovery path has tests. It will also make sure that redo recovery encountering garbage
> in a newly allocated page during redo of an create page is tested.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-888) improve performance of page allocation
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-888?page=all ]
Kathey Marsden updated DERBY-888:
---------------------------------
Component: Store
> improve performance of page allocation
> --------------------------------------
>
> Key: DERBY-888
> URL: http://issues.apache.org/jira/browse/DERBY-888
> Project: Derby
> Type: Improvement
> Components: Store
> Reporter: Mike Matrigali
> Assignee: Mike Matrigali
> Priority: Minor
> Fix For: 10.2.0.0
>
> Improve performance of page allocation by no longer requiring sync of the allocated pages. The reason for the sync
> currently is so that during redo recovery we did not have to handle the case of redoing the allocate and finding no space
> available on the disk. During tasks like single user load this sync allocation is a significant performance issue - in the
> case where one does 1000 insert per transaction the total time aproaches very close to durability=test where no syncing
> is done in the whole system.
> For instance in a test of loading a 150 meg db with a number of tables and indexes, on a 1.7 ghz laptop with one ide disk,
> sun jdk1.4.2, windows XP
> i got the following types of results:
> default system: 6 minutes
> no alloc sync: 1 minute, 43 seconds
> no syncing: 1 minute , 1 second
> Once syncing is disabled then recovery must be enhanced to handle the possible out of space condition. Recovery already
> handles out of space during undo, so this will just handle the error the same as that. It will stop recovery and produce an error
> indicating that user must add disk space and rerun recovery before system can be brought online. I actually think on most
> JVM's/OS's this won't happen as the system will still be asking the JVM/OS for the space, just not syncing the values in those
> pages to disk. Most OS's at this point will reserve the space in the file tables and not let others grab that space.
> This project will make sure that out of space recovery path has tests. It will also make sure that redo recovery encountering garbage
> in a newly allocated page during redo of an create page is tested.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira