เมื่อฉันรันSHOW PROCESSLISTมักจะมีเธรด INSERT / UPDATE จำนวนมากในสถานะ "การปล่อยไอเท็ม"
คู่มือ MySQL แสดงให้เห็นว่าอย่างน้อยส่วนหนึ่งของเหตุผลสำหรับเธรดที่อยู่ในสถานะนี้เกี่ยวข้องกับแคชคิวรี - ซึ่งสันนิษฐานว่ามันจะทำให้คิวรีแคชใช้งานไม่ได้เนื่องจากข้อมูลที่เปลี่ยนแปลง
อย่างไรก็ตามฉันquery_cache_sizeถูกตั้งค่าเป็น 0 ซึ่งควรปิดการใช้งานแคชแบบสอบถามทั้งหมด
มีเหตุผลอื่นอีกไหมที่จะมีเธรดจำนวนมากในสถานะนี้
ตารางที่เกี่ยวข้องใช้เอ็นจิ้นการจัดเก็บข้อมูล InnoDB
คำตอบ:
ตรวจสอบค่าของ innodb_thread_concurrency
สำหรับระบบของฉันเพิ่มค่าจาก 8 เป็น 32 ตามแนวทางในเอกสาร MySqlทำให้จำนวนเธรดลดลงที่สามารถมองเห็นได้พร้อมกันรายงานสถานะ "รายการที่พ้น" นอกจากนี้เวลาสอบถามเฉลี่ย obesrved ลดลงตามลำดับความสำคัญ
ในขณะที่สิ่งนี้สร้างความแตกต่างอย่างมากในประสิทธิภาพการทำงานของเซิร์ฟเวอร์โดยรวม แต่มันไม่ใช่ bullet เงิน ระบบนิเวศฮาร์ดแวร์ของฉันทำให้ฉันตั้งสมมติฐานว่าสถานะนี้ส่วนใหญ่จะเห็นในระบบที่มีดิสก์ "ช้า" (2x10k ดิสก์โจมตี 1) และเป็นที่แพร่หลายน้อยกว่าในระบบที่มีการจัดเก็บข้อมูลได้เร็วขึ้น (12x15k ดิสก์บุก 10) ดังนั้นจึงควรตรวจสอบประสิทธิภาพของดิสก์ด้วย
โชคดี!
นอกจากนี้:
เป็นที่น่าสังเกตว่าค่าเริ่มต้นของ innodb_thread_concurrency นั้นแตกต่างกันอย่างสิ้นเชิงทั้งนี้ขึ้นอยู่กับการใช้งาน 5.0 point release
ค่าเริ่มต้นมีการเปลี่ยนแปลงหลายครั้ง: 8 ก่อน MySQL 5.0.8, 20 (ไม่มีที่สิ้นสุด) จาก 5.0.8 ถึง 5.0.18, 0 (ไม่มีที่สิ้นสุด) จาก 5.0.19 เป็น 5.0.20 และ 8 (จำกัด ) จาก 5.0.21 บน. - แหล่งที่มา
ซึ่งหมายความว่าการอัปเกรดไร้เดียงสาที่ดูเหมือนจะไร้สาระจาก 5.0.20 เป็น 5.0.21 เปลี่ยนค่าเริ่มต้นจากไม่มีที่สิ้นสุดเป็น 8 และนำมาซึ่งการกระจายของประสิทธิภาพ
การเพิ่มไอเท็มเป็นขั้นตอนการดำเนินการเคียวรีที่โครงสร้างชั่วคราวบัฟเฟอร์ ฯลฯ ถูกจัดสรรคืน งานแคชแบบสอบถามบางงานเสร็จสิ้นในขั้นตอนนี้ แต่นั่นไม่ใช่สิ่งเดียวที่เกิดขึ้นที่นั่น ฉันอยากจะแนะนำให้ใช้ SHOW PROFILES เพื่อดูว่าระยะเวลานี้ใช้เวลานานเท่าใดเมื่อเทียบกับขั้นตอนอื่นและหากเวลาที่เหลืออยู่กลายเป็นเรื่องกังวลให้แก้ไขปัญหาด้วยเครื่องมือเช่น profiler ของคนจนและ oprofile
มีรายงานข้อผิดพลาดเกี่ยวกับปัญหานี้เกี่ยวข้องกับรายการ "พ้น" และแคชแบบสอบถามเป็น แม้ว่าข้อผิดพลาดจะปิดไม่มีการพูดถึงไม่มีinnodb_thread_concurrency
บังเอิญฉันได้พูดคุยกับ Ronald Bradford ที่ Percona Live NYC เมื่อเดือนพฤษภาคม ฉันบอกเขาถึงสถานการณ์ที่ฉัน tweeked innodb_thread_concurrency เนื่องจาก MySQL InnoDB Buffer Pool หลายตัวของ 5.5 ทำให้เกิดการล็อกเธรดจำนวนมากและฉันสงสัยว่าข้อมูลแคชที่ฉันต้องการมักจะแพร่กระจายท่ามกลางหลายบัฟเฟอร์พูล
เขาบอกฉันอย่างชัดแจ้งว่าฉันไม่ควรตั้งค่ากับ innodb_thread_concurrency ปล่อยให้เป็นค่าเริ่มต้นเสมอซึ่งขณะนี้เป็นศูนย์ (0) ด้วยการทำเช่นนี้คุณจะให้ที่เก็บข้อมูล InnoDB เป็นผู้ตัดสินว่าจะสร้างInnodb_concurrency_ticketsด้วยตนเองเพียงใด นี่คือสิ่งที่เกิดขึ้นพร้อมกันไม่สิ้นสุด
'การเพิ่มรายการ' มักเกิดขึ้นบ่อยครั้งเมื่อเรากำหนดขีด จำกัด ของ innodb_thread_concurrency นั่นควรจะเป็นศูนย์ (0) ฉันจะรับความเสี่ยงและเพิ่ม innodb_concurrency_tickets และดูว่ามันช่วยได้หรือไม่
เรามีปัญหากับอาการเดียวกัน ปรากฎว่าดิสก์ที่มีไฟล์บันทึกของ InnoDB นั้นเต็มแล้ว การตรวจสอบที่คุ้มค่า
คำแนะนำอื่น: อาจเป็น innodb fsync () ลองตั้งค่า
innodb_flush_log_at_trx_commit = 2
ใน my.cnf
จากนั้นไฟล์บันทึกของ innodb จะถูกลบทิ้งไปที่ดิสก์ทุก 1-2 วินาทีแทนที่จะเป็น ob ทุกการกระทำ โทษเล็กน้อยต่อความถูกต้องของข้อมูลรับความเร็วได้อย่างยอดเยี่ยม