MySQL table_cache และ Opened_tables

ฉันเคยเห็นคนใช้การเปรียบเทียบของ Open_tables และ Opened_tables เพื่อประเมินว่า table_cache มีขนาดเล็กเกินไปใน MySQL อย่างไรก็ตามฉันเชื่อว่า Opened_tables สะสมตลอดเวลาดังนั้นนี่จึงไม่ใช่การเปรียบเทียบที่ถูกต้อง ข้อแม้เพียงข้อเดียวที่บางที Opened_tables อาจชนกับการพลาดเท่านั้น - ถึงแม้ว่าถ้าตารางที่เปิดต่อวินาทียังคงมีขนาดเล็กก็อาจไม่เป็นปัญหาสำหรับมันที่จะค่อยๆเติบโต

หากเปรียบเทียบ Open_tables กับ Opened_tables ไม่ถูกต้องมีวิธีอื่นในการรับข้อมูลที่วัดได้จากสิ่งนี้หรือไม่?

นี่คือ MySQL 5.0 แต่ยินดีต้อนรับความแตกต่างระหว่างเวอร์ชันด้วย

เหตุผลที่ดีที่สุดในการมี table_cache ขนาดใหญ่คือLOCK_open mutexนั้นไม่ร้อน MySQL ก่อนหน้า 5.5 มีการโต้แย้งจำนวนมากเมื่อคุณพยายามเปิด / ปิดตารางดังนั้นคุณต้องการ จำกัด การทำเช่นนี้ให้ได้มากที่สุดเช่นมีแคชตารางที่มีขนาดใหญ่

ดังนั้นคุณไม่สนใจอัตราส่วนเฉพาะใด ๆ ของการเข้าชมที่จะพลาด (infact คุณควรละเว้นอัตราส่วนทั้งหมด - โพสต์บล็อกนี้อธิบายว่าทำไม ) สิ่งที่คุณสนใจคืออัตราการพลาดเนื่องจากยิ่งมีสิ่งนี้เกิดขึ้นต่อวินาทียิ่งมีโอกาสที่คุณจะมีความขัดแย้งมากขึ้น (หนึ่งเธรดต้องรออีกเธรดหนึ่งเพื่อปลดล็อก)

คุณมองเห็นอัตราการพลาดได้อย่างไร คุณดึงตัวอย่างของ Opened_Tables สองสามวินาทีออกจากกันในช่วงเวลาที่ยุ่งที่สุดของวันและหากมีการเพิ่มขึ้นของแต่ละตัวอย่างอาจเป็นความคิดที่ดีที่จะดูว่าคุณสามารถชน table_cache ได้หรือไม่

หมายเหตุ: ฉันไม่แนะนำให้ทำการเปรียบเทียบกับเวลาที่ใช้

ก่อนอื่นมาพิจารณาตัวแปรสถานะเหล่านั้น:

Open tables : จำนวนของตารางที่เปิด

Opened_tables : จำนวนตารางที่ถูกเปิด หาก Opened_tables มีขนาดใหญ่ค่า table_open_cache ของคุณอาจเล็กเกินไป

น่าแปลกที่คำตอบสำหรับคำถามของคุณอยู่ในคำถามนั้น

ตัวแปรสองตัวนั้นเหมาะสมกว่าหากคุณเพิ่มตัวแปรสถานะอีกหนึ่งตัวแปรลงในส่วนผสม: สถานะuptime (หรือสถานะ Uptime_since_flushสำหรับค่าเฉลี่ยใหม่หลังจากสถานะล้าง )

คุณควรจะเปรียบเทียบ Open_tables agsinst (opened_tables / Uptime) หาก Open_tables ปีนขึ้นไปด้านบน(Opened_tables / Uptime)ตอนนี้คุณมีข้อกังวลและควรจับตามองสิ่งต่าง ๆ ดังต่อไปนี้:

• netstat
• iostat
• โหลดเซิร์ฟเวอร์
• จำนวนการเชื่อมต่อ (เมื่อใกล้ถึงmax_connections )
• ลูกค้าที่ถูกยกเลิก
• ยกเลิกการเชื่อมต่อ
• ข้อความค้นหาช้า

อัพเดท 2011-08-31 12:18 EDT

โปรดทราบว่าทำไมฉันถึงแนะนำให้ใช้Uptime_since_flush_statusแทนUptimeเพื่อรับรูปแบบการเติบโต Opened_tables สำหรับช่วงเวลาที่กำหนด

ตัวอย่างเช่นหากคุณรันFLUSH STATUS;ทุกวันจันทร์ตอนเที่ยงคืนคุณสามารถสร้าง OpenTableFactor ได้:

SELECT *, (Open_tables * Uptime / Opened_Tables) OpenTableFactor FROM
(SELECT variable_value Uptime FROM information_schema.global_status
WHERE variable_name = 'Uptime_since_flush_status') up,
(SELECT variable_value Open_tables FROM information_schema.global_status
WHERE variable_name = 'Open_tables') opn,
(SELECT IF(variable_value=0,1,variable_value) Opened_tables
FROM information_schema.global_status
WHERE variable_name = 'Opened_tables') opnd;

ปัจจัยตารางที่เปิดนี้มีจำนวนเท่ากับจำนวนที่แสดงถึงจำนวนของตารางที่เปิดในช่วงเวลาใดก็ตามเทียบกับจำนวนเฉลี่ยของตารางที่เปิดอยู่ตลอดระยะเวลาที่กำหนด ด้วยFLUSH HOSTS;ทุกสัปดาห์ / วัน / โฮสต์ค่าเฉลี่ยนั้นเทียบกับสัปดาห์ / วัน / ชั่วโมง

นี่คือตัวอย่างจากลูกค้าของนายจ้างของฉัน:

mysql> SELECT *, (Open_tables * Uptime / Opened_Tables) OpenTableFactor FROM     (SELECT variable_value Uptime FROM information_sc    hema.global_status     WHERE variable_name = 'Uptime_since_flush_status') up,     (SELECT variable_value Open_tables FROM informat    ion_schema.global_status     WHERE variable_name = 'Open_tables') opn,     (SELECT IF(variable_value=0,1,variable_value) Opened_ta    bles     FROM information_schema.global_status     WHERE variable_name = 'Opened_tables') opnd;
+----------+-------------+---------------+-------------------+
| Uptime   | Open_tables | Opened_tables | OpenTableFactor   |
+----------+-------------+---------------+-------------------+
| 14385123 | 16326       | 30429078      | 7717.996519579068 |
+----------+-------------+---------------+-------------------+
1 row in set (0.00 sec)

โดยทั่วไปแล้วไคลเอนต์นี้จะรักษาประมาณ 7745 OpenTableFactor ที่สูงสุด หาก OpenTableFactor ลดลงอย่างกระทันหัน (แม้ว่าจะมีเพียงเล็กน้อย) ก็อาจบ่งบอกถึงรูปแบบการรับส่งข้อมูลที่ต่ำกว่า conenctions ที่ยกเลิกสูงและอื่น ๆ หาก OpenTableFactor ไม่เคยเปลี่ยนแปลง (แม้ว่าจะมีเพียงเล็กน้อย) ก็สามารถนำเสนอโอกาสให้คุณเปลี่ยนการตั้งค่าเหล่านี้:

• open_files_limit
• innodb_open_files
• table_open_cache

เมื่อปรับแล้ว OpenTableFactor อาจเปลี่ยนแปลงตลอดเวลาหรือกระทบเพดานหรือที่ราบสูงอื่น ดังนั้นการใช้หน่วยต่าง ๆ ภายในตัวแปรสถานะจึงมีความสำคัญสำหรับการปรับค่านี้

อัพเดท 2011-08-31 12:42 EDT

แบบสอบถาม SQL ที่ฉันใช้สำหรับ OpenTableFactor ไม่สามารถใช้งานกับ MySQL 5.0 และย้อนกลับได้ หากคุณใช้ผู้ดูแลระบบ MySQLหรือMONyogคุณสามารถปรับแต่งกราฟโดยใช้สูตรในแบบสอบถามและตรวจสอบ MONyog รวบรวมประวัติโดยใช้ SQLLite สำหรับการทำกราฟประวัติในภายหลัง สามารถทำได้สำหรับ MySQL ทุกรุ่น

จากหนึ่งในความคิดเห็นของผู้ใช้ในหน้าเอกสารประกอบtable_cache :

Opened_tables เป็นตัวแปรสถานะที่ทำให้จำนวนของตัวอธิบายไฟล์เพิ่มเติมที่ได้รับการจัดสรรสำหรับการเปิดตารางในช่วงเวลาที่ตัวอธิบายไฟล์ที่มีอยู่ใน table_cache นั้นหมดลง ...

หมายความว่ามันจะเพิ่มขึ้นเมื่อคุณไปเกินtable_cacheค่าของคุณ ดังนั้นวิธีที่ฉันตรวจสอบตามปกตินี้คือการเปรียบเทียบopened_tablesกับuptimeแต่ที่สำคัญที่นี่คือการใช้มันในช่วงเวลาที่กำหนด (เช่นหนึ่งครั้งต่อนาทีในช่วงสิบนาทีเป็นต้น ถ้ามันเพิ่มขึ้นนั้นอาจtable_cacheจะเป็นตัวบ่งชี้ที่คุณต้องการเพิ่มของคุณ

คำเตือนคู่พูดถึง:

• ความคิดเห็นอื่นในเอกสารข้างต้น: "ตัวแปรสถานะ 'Opened_tables' จะเพิ่มขึ้น 2 ครั้งทุกครั้งที่คุณสร้างตารางชั่วคราว opened_tablesดังนั้นหากการค้นหาของคุณมีการกำหนดตารางชั่วคราวจำนวนมากนี้อาจเป็นสาเหตุของการเพิ่มขึ้นอย่างรวดเร็วใน คุณสามารถเห็นการใช้ตารางชั่วคราวโดยใช้แบบสอบถามต่อไปนี้:

  SHOW GLOBAL STATUS LIKE '%tmp%';

• อย่าเพิ่ม table_cache สูงเกินไป

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