หากการหยุดชะงักของเหตุการณ์ Parallelism Exchange นั้นน้อยกว่าเหยื่อจะเป็นปัญหาหรือไม่?


10

เราเห็นจำนวนDeadlocks แบบขนานภายในเธรดเหล่านี้จำนวนมากในสภาพแวดล้อมการผลิตของเรา (SQL Server 2012 SP2 - ใช่ ... ฉันรู้ ... ) อย่างไรก็ตามเมื่อดู Deadlock XML ที่ถูกบันทึกผ่าน Extended Events รายการเหยื่อนั้นว่างเปล่า

<victim-list />

deadlocking ปรากฏอยู่ระหว่าง 4 กระทู้สองกับสองกับWaitType="e_waitPipeNewRow"WaitType="e_waitPipeGetRow"

 <resource-list>
  <exchangeEvent id="Pipe13904cb620" WaitType="e_waitPipeNewRow" nodeId="19">
   <owner-list>
    <owner id="process4649868" />
   </owner-list>
   <waiter-list>
    <waiter id="process40eb498" />
   </waiter-list>
  </exchangeEvent>
  <exchangeEvent id="Pipe30670d480" WaitType="e_waitPipeNewRow" nodeId="21">
   <owner-list>
    <owner id="process368ecf8" />
   </owner-list>
   <waiter-list>
    <waiter id="process46a0cf8" />
   </waiter-list>
  </exchangeEvent>
  <exchangeEvent id="Pipe13904cb4e0" WaitType="e_waitPipeGetRow" nodeId="19">
   <owner-list>
    <owner id="process40eb498" />
   </owner-list>
   <waiter-list>
    <waiter id="process368ecf8" />
   </waiter-list>
  </exchangeEvent>
  <exchangeEvent id="Pipe4a106e060" WaitType="e_waitPipeGetRow" nodeId="21">
   <owner-list>
    <owner id="process46a0cf8" />
   </owner-list>
   <waiter-list>
    <waiter id="process4649868" />
   </waiter-list>
  </exchangeEvent>
 </resource-list>

ดังนั้น:

  1. รายชื่อเหยื่อว่างเปล่า
  2. แอปพลิเคชันที่เรียกใช้แบบสอบถามไม่ได้เกิดข้อผิดพลาดและทำให้แบบสอบถามเสร็จสมบูรณ์
  3. เท่าที่เราเห็นไม่มีประเด็นที่ชัดเจนนอกจากกราฟที่ถูกจับ

ดังนั้นนี่คือสิ่งที่ต้องกังวลเกี่ยวกับนอกเหนือจากเสียงรบกวนหรือไม่

แก้ไข:ขอบคุณคำตอบของ Paul ฉันสามารถดูว่าปัญหาน่าจะเกิดขึ้นที่ใดและดูเหมือนว่าจะแก้ไขตัวเองด้วย tempdb spill ป้อนคำอธิบายรูปภาพที่นี่

คำตอบ:


11

ฉันจะไม่แปลกใจถ้านี่เป็นวิธีที่กราฟเดดล็อกดูเมื่อการเดดล็อกแบบขนานภายในได้รับการแก้ไขโดยการแลกเปลี่ยนหก (ดังนั้นจึงไม่มีเหยื่อยกเว้นการทำงาน)

คุณสามารถยืนยันทฤษฎีนี้ได้โดยจับการรั่วไหลของการแลกเปลี่ยนและจับคู่พวกเขาขึ้น (หรือไม่) กับการหยุดชะงัก

การเขียนบัฟเฟอร์แลกเปลี่ยนไปยังtempdbเพื่อแก้ไขการหยุดชะงักไม่เหมาะ มองหาเพื่อกำจัดลำดับของการดำเนินการรักษาคำสั่งซื้อในแผนการดำเนินการ (เช่นการแลกเปลี่ยนคำสั่งซื้อที่เก็บรักษาไว้ซึ่งเป็นการรวมการผสานผสานเข้าด้วยกัน) นอกจากจะไม่ทำให้เกิดปัญหาประสิทธิภาพการทำงานที่สังเกตได้และคุณมีสิ่งอื่นที่ต้องกังวล

จากความสนใจปัญหานี้มีแนวโน้มที่จะทวีความรุนแรงมากโดยสถิติการกระจายตัวที่สูง / ล้าสมัย?

การกระจายตัวของหมายเลข สถิติที่ล้าสมัย: ไม่เฉพาะเจาะจงเท่าที่ฉันคิดได้ แน่นอนว่าสถิติที่ไม่ค่อยเป็นตัวแทนนั้นเป็นสิ่งที่ดีโดยทั่วไป

ปัญหาพื้นฐานที่นี่คือความเท่าเทียมกันทำงานได้ดีที่สุดเมื่อมีการพึ่งพาระหว่างเธรดน้อยที่สุดเท่าที่จะเป็นไปได้ การสั่งซื้อที่เก็บรักษาไว้นั้นเป็นการอ้างอิงที่น่ารังเกียจ สิ่งที่สามารถได้รับการทากาวขึ้นและวิธีเดียวที่จะล้าง logjam คือการรั่วไหลพวงของแถวที่จัดขึ้นที่การแลกเปลี่ยนการtempdb


-1

เพื่อแยกความแตกต่างที่ไม่สำคัญเหล่านี้ "การแก้ไขตัวเองโดยการรั่วไหล" การหยุดชะงักจากการหยุดชะงักที่สำคัญยิ่งขึ้นความหมายการค้นหาบางอย่างสามารถนำไปใช้กับโครงสร้าง Xdl

ตัวอย่างผลลัพธ์

SP ต่อไปนี้จะไม่ทำงานนอกกรอบเนื่องจากขึ้นอยู่กับ ufn_ExtractSubstringsByPattern () อย่างไรก็ตามวิธีนั้นสามารถถูกแทนที่ด้วยบางสิ่งที่ส่งกลับจำนวนที่แตกต่างกันโดยตรง

ALTER view [Common].[DeadLockRecentHistoryView]
as
/*---------------------------------------------------------------------------------------------------------------------
    Purpose:  List history of recent deadlock events

    Warning:  The XML processing may hit a recursion limit (100), suggest using "option (maxrecursion 10000)".

    Xdl File:
        The SSMS deadlock file format .XDL format (xml) has changed with later versions of SQL Server.  This version tested with 2012.

    Ring Buffer issues:
        https://connect.microsoft.com/SQLServer/feedback/details/754115/xevents-system-health-does-not-catch-all-deadlocks
        https://www.sqlskills.com/blogs/jonathan/why-i-hate-the-ring_buffer-target-in-extended-events/

    Links:
        http://www.sqlskills.com/blogs/jonathan/multi-victim-deadlocks/
        https://www.sqlskills.com/blogs/jonathan/graphically-viewing-extended-events-deadlock-graphs/
        http://www.mssqltips.com/sqlservertip/1234/capturing-sql-server-deadlock-information-in-xml-format/
        http://blogs.msdn.com/b/sqldatabasetalk/archive/2013/05/01/tracking-down-deadlocks-in-sql-database.aspx
        http://dba.stackexchange.com/questions/10644/deadlock-error-isnt-returning-the-deadlock-sql/10646#10646        

    Modified    By           Description
    ----------  -----------  ------------------------------------------------------------------------------------------
    2014.10.29  crokusek     From Internet, http://stackoverflow.com/questions/19817951
    2015.05.05  crokusek     Improve so that the output is consumable by SSMS 2012 as "Open .xdl file"                             
    2015.05.22  crokusek     Remove special character for the cast to Xml (like '&')
    2017.08.03  crokusek     Abandon ring-buffer approach and use event log files.  Filter out internal deadlocks.
    2018.07.16  crokusek     Added field(s) like ProbablyHandledBySpill to help identify non-critical deadlocks.
  ---------------------------------------------------------------------------------------------------------------------*/
with XmlDeadlockReports as
(
  select convert(xml, event_data) as EventData         
    from sys.fn_xe_file_target_read_file(N'system_health*.xel', NULL, NULL, NULL)      
   where substring(event_data, 1, 50) like '%"xml_deadlock_report"%'       
)
select top 10000
       EventData.value('(event/@timestamp)[1]', 'datetime2(7)') as CreatedUtc,
       --(select TimePst from Common.ufn_ConvertUtcToPst(EventData.value('(event/@timestamp)[1]', 'datetime2(7)'))) as CreatedPst,
       DistinctSpidCount,       
       HasExchangeEvent,
       IsVictimless,                  
       --
       -- If the deadlock contains Exchange Events and lists no victims, it probably occurred
       -- during execution of a single query that contained parallellism but got stuck due to 
       -- ordering issues.   /dba/197779
       -- 
       -- These will not raise an exception to the caller and will complete by spilling to tempdb
       -- however they may run much slower than they would without the spill(s).
       --
       convert(bit, iif(DistinctSpidCount = 1 and HasExchangeEvent = 1 and IsVictimless = 1, 1, 0)) as ProbablyHandledBySpill,
       len(et.XdlFileText) as LenXdlFile,
       eddl.XdlFile as XdlFile
  from XmlDeadlockReports
 cross apply 
     ( 
       select eventData.query('event/data/value/deadlock') as XdlFile 
     ) eddl
 cross apply 
     ( 
        select convert(nvarchar(max), eddl.XdlFile) as XdlFileText 
     ) as et
 cross apply 
     (
       select count(distinct Match) as DistinctSpidCount
         from common.ufn_ExtractSubstringsByPattern(et.XdlFileText, 'spid="%%"')
     ) spids
 cross apply
     (
       select convert(bit, iif(charindex('<exchangeEvent', et.XdlFileText) > 0, 1, 0)) as HasExchangeEvent,
              --
              convert(bit, iif(     charindex('<victim-list>', et.XdlFileText) = 0
                                and charindex('<victim-list/>', et.XdlFileText) > 0, 1, 0)) as IsVictimless
     ) as flags        
 order by CreatedUtc desc
GO
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.