Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


PAGELATCH_UP suggestions


PAGELATCH_UP suggestions

Author
Message
Lexa
Lexa
SSC-Enthusiastic
SSC-Enthusiastic (169 reputation)SSC-Enthusiastic (169 reputation)SSC-Enthusiastic (169 reputation)SSC-Enthusiastic (169 reputation)SSC-Enthusiastic (169 reputation)SSC-Enthusiastic (169 reputation)SSC-Enthusiastic (169 reputation)SSC-Enthusiastic (169 reputation)

Group: General Forum Members
Points: 169 Visits: 508
We're experiencing high waits for this type on a user database during high volume inserts on a partitioned table. What are the general recommendations for preventing this type of wait?
Grant Fritchey
Grant Fritchey
SSCoach
SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)

Group: General Forum Members
Points: 17619 Visits: 32268
You're experiencing I/O waits during I/O operations... The only way to speed that up is to get faster/more disks.

----------------------------------------------------
The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood...
Theodore Roosevelt

The Scary DBA
Author of: SQL Server Query Performance Tuning and SQL Server Execution Plans
Product Evangelist for Red Gate Software
Lexa
Lexa
SSC-Enthusiastic
SSC-Enthusiastic (169 reputation)SSC-Enthusiastic (169 reputation)SSC-Enthusiastic (169 reputation)SSC-Enthusiastic (169 reputation)SSC-Enthusiastic (169 reputation)SSC-Enthusiastic (169 reputation)SSC-Enthusiastic (169 reputation)SSC-Enthusiastic (169 reputation)

Group: General Forum Members
Points: 169 Visits: 508
Grant Fritchey (8/15/2012)
You're experiencing I/O waits during I/O operations... The only way to speed that up is to get faster/more disks.


That's what I thought. Thanks.
Orlando Colamatteo
Orlando Colamatteo
SSCrazy Eights
SSCrazy Eights (8.3K reputation)SSCrazy Eights (8.3K reputation)SSCrazy Eights (8.3K reputation)SSCrazy Eights (8.3K reputation)SSCrazy Eights (8.3K reputation)SSCrazy Eights (8.3K reputation)SSCrazy Eights (8.3K reputation)SSCrazy Eights (8.3K reputation)

Group: General Forum Members
Points: 8259 Visits: 14368
Grant Fritchey (8/15/2012)
You're experiencing I/O waits during I/O operations... The only way to speed that up is to get faster/more disks.

Are you sure you're not thinking of PAGEIOLATCH_UP? I think PAGELATCH_UP is a memory latch (buffer, i.e. not I/O) caused when doing an update. At a guess there is potential for allocation contention issues when you see this wait. Can you provide the DDL for the partitioned table? How many rows are you inserting?

__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community. --Plato
Lexa
Lexa
SSC-Enthusiastic
SSC-Enthusiastic (169 reputation)SSC-Enthusiastic (169 reputation)SSC-Enthusiastic (169 reputation)SSC-Enthusiastic (169 reputation)SSC-Enthusiastic (169 reputation)SSC-Enthusiastic (169 reputation)SSC-Enthusiastic (169 reputation)SSC-Enthusiastic (169 reputation)

Group: General Forum Members
Points: 169 Visits: 508
opc.three (8/15/2012)
Grant Fritchey (8/15/2012)
You're experiencing I/O waits during I/O operations... The only way to speed that up is to get faster/more disks.

Are you sure you're not thinking of PAGEIOLATCH_UP? I think PAGELATCH_UP is a memory latch (buffer, i.e. not I/O) caused when doing an update. At a guess there is potential for allocation contention issues when you see this wait. Can you provide the DDL for the partitioned table? How many rows are you inserting?


It wasn't many rows about 40K but I think the main issue was the fact that our dynamic re-indexing process started to rebuild an index in the middle of the insert process. That specific partition itself had only about 30K rows initially + the 40K that got added.

Partition is by store, and a store can have any number of items from 0 to 22 mil. It's not the best partitioning strategy so we're working on a new one to replace the current one.

Wouldn't PAGELATCH_UP be also tied to IO perhaps indirectly? This link gives some good info but we can't implement this type of partitioning. http://sqlcat.com/sqlcat/b/technicalnotes/archive/2009/09/22/resolving-pagelatch-contention-on-highly-concurrent-insert-workloads-part-1.aspx
GilaMonster
GilaMonster
SSC-Forever
SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)

Group: General Forum Members
Points: 47311 Visits: 44392
Typically no, Pagelatch is a wait for a latch on a page in memory. Need some idea what pages the latch waits are on to say much more.


Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass


Orlando Colamatteo
Orlando Colamatteo
SSCrazy Eights
SSCrazy Eights (8.3K reputation)SSCrazy Eights (8.3K reputation)SSCrazy Eights (8.3K reputation)SSCrazy Eights (8.3K reputation)SSCrazy Eights (8.3K reputation)SSCrazy Eights (8.3K reputation)SSCrazy Eights (8.3K reputation)SSCrazy Eights (8.3K reputation)

Group: General Forum Members
Points: 8259 Visits: 14368
Lexa (8/15/2012)
opc.three (8/15/2012)
Grant Fritchey (8/15/2012)
You're experiencing I/O waits during I/O operations... The only way to speed that up is to get faster/more disks.

Are you sure you're not thinking of PAGEIOLATCH_UP? I think PAGELATCH_UP is a memory latch (buffer, i.e. not I/O) caused when doing an update. At a guess there is potential for allocation contention issues when you see this wait. Can you provide the DDL for the partitioned table? How many rows are you inserting?


It wasn't many rows about 40K but I think the main issue was the fact that our dynamic re-indexing process started to rebuild an index in the middle of the insert process. That specific partition itself had only about 30K rows initially + the 40K that got added.

If you have multiple processes competing to open latches on the same pages, especially one as intense as an index rebuild/org routine, that could be the problem. When doing a mass insert you'll likely be doing lots of random allocations in your nonclustered indexes, and depending on your DDL lots of sequential or random allocations in your clustered index. Can you please provide the DDL for the table (incl indexes and partition scheme and function)? Does it have an identity or sequential GUID column?

Partition is by store, and a store can have any number of items from 0 to 22 mil. It's not the best partitioning strategy so we're working on a new one to replace the current one.

Wouldn't PAGELATCH_UP be also tied to IO perhaps indirectly?

Not necessarily. The buffer pool does just that, it buffers us from the I/O subsystem so when you're waiting on a buffer latch it has to do with memory, not disk. I think your system would be in a world of hurt if you were seeing buffer latch waits as a result of upstream IO latch waits.

This link gives some good info but we can't implement this type of partitioning. http://sqlcat.com/sqlcat/b/technicalnotes/archive/2009/09/22/resolving-pagelatch-contention-on-highly-concurrent-insert-workloads-part-1.aspx

Use the query in the article to find out what exactly your query is waiting on.

__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community. --Plato
Grant Fritchey
Grant Fritchey
SSCoach
SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)

Group: General Forum Members
Points: 17619 Visits: 32268
Oops. Missed the missing 'IO' & responded too quickly.

----------------------------------------------------
The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood...
Theodore Roosevelt

The Scary DBA
Author of: SQL Server Query Performance Tuning and SQL Server Execution Plans
Product Evangelist for Red Gate Software
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search