it-swarm.asia

MySQL table_cache و Opened_tables

لقد رأيت أشخاصًا يستخدمون مقارنة Open_tables و Opened_tables لتقييم ما إذا كانت ذاكرة التخزين المؤقت table_cache صغيرة جدًا في MySQL. ومع ذلك ، أعتقد أن Opened_tables تراكمي عبر وقت التشغيل ، لذا فهذه ليست مقارنة صالحة. التحذير الوحيد الذي ربما يكون Opened_tables هو أن يصطدم فقط بالأخطاء - على الرغم من ذلك حتى إذا كانت الجداول التي يتم فتحها في الثانية لا تزال صغيرة ، فربما لا تكون مشكلة في النمو التدريجي.

إذا كانت مقارنة Open_tables مع Opened_tables غير صالحة ، فهل هناك طريقة أخرى للحصول على البيانات المقاسة لهذا؟

هذا على MySQL 5.0 ، ولكن الاختلافات بين الإصدار مرحب بها أيضًا.

14
Sam Brightman

أكبر سبب لوجود ذاكرة تخزين كبيرة في table_cache هو أن LOCK_open mutex ليست ساخنة. لدى MySQL قبل 5.5 الكثير من الخلاف عندما تحاول فتح/إغلاق الجداول ، لذلك تريد تقييد القيام بذلك قدر الإمكان ، أي أن يكون لديك ذاكرة تخزين مؤقت كبيرة في الجدول.

لذلك لا تهتم بأي نسبة معينة من النتائج إلى النتائج المفقودة (في الواقع ، يجب تجاهل النسب تمامًا - توضح مشاركة المدونة هذه السبب ). ما يهمك هو معدل الخطأ ، لأنه كلما حدث هذا في الثانية ، زادت فرصة حصولك على خلاف (يجب أن يكون هناك موضوع واحد انتظر سلسلة أخرى لتحرير القفل.)

كيف تكتشف معدل الضياع؟ يمكنك جلب بعض العينات من Opened_Tables بفارق بضع ثوانٍ خلال الفترة الأكثر ازدحامًا في اليوم ، وإذا كانت هناك زيادات في كل عينة ، فربما يكون من الجيد معرفة ما إذا كان بإمكانك زيادة ذاكرة التخزين المؤقت للجدول.

ملاحظة: لا أوصي على وجه التحديد بمقارنة وقت التشغيل.

7
Morgan Tocker

أولاً ، دعنا نفكر في متغيرات الحالة هذه:

فتح الجداول : عدد الجداول المفتوحة.

Opened_tables : عدد الجداول التي تم فتحها. إذا كان Opened_tables كبيرًا ، فربما تكون قيمة table_open_cache صغيرة جدًا.

والمثير للدهشة أن الإجابة على سؤالك تكمن في السؤال نفسه.

سيكون المتغيران أكثر منطقية فقط إذا قمت بإدخال متغير حالة واحد إضافي في المزيج: وقت التشغيل (أو حالة Uptime_since_flush للمتوسطات الجديدة بعد حالة FLUSH =).

يجب أن تقارن Open_tables agsinst (Opened_tables/Uptime) . إذا كان Open_tables يتسلق فوق (Opened_tables/Uptime) ، الآن لديك سبب للقلق ويجب أن تراقب أشياء مثل ما يلي:

تحديث 2011-08-31 12:18 بتوقيت شرق الولايات المتحدة

يرجى ملاحظة لماذا اقترحت أيضًا استخدام Uptime_since_flush_status بدلاً من وقت التشغيل للحصول على إصلاح نمط 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 فجأة (حتى لو كان قليلاً) ، فقد يشير ذلك إلى أنماط حركة مرور أقل ، وحالات إجهاض عالية ، وما إلى ذلك. إذا لم يتغير OpenTableFactor مطلقًا (حتى لو كان قليلاً) ، فقد يمنحك فرصة لتغيير هذه الإعدادات:

بمجرد التعديل ، قد يتغير OpenTableFactor باستمرار أو يصطدم بسقف أو هضبة أخرى. وبالتالي ، يصبح استخدام وحدات مختلفة ضمن متغيرات الحالة أمرًا حيويًا لهذا النوع من الضبط.

تحديث 2011-08-31 12:42 EDT

لا يعمل استعلام SQL الذي قمت بتشغيله لـ OpenTableFactor لـ MySQL 5.0 والإصدارات السابقة. إذا كنت تستخدم MySQL Administrator أو MONyog ، فيمكنك تخصيص رسم بياني باستخدام الصيغة الموجودة في الاستعلام والشاشة. يقوم MONyog بجمع التاريخ باستخدام SQLLite للرسم البياني التاريخي اللاحق. يمكن القيام بذلك لأي نسخة من MySQL.

5
RolandoMySQLDBA

من أحد تعليقات المستخدم على 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 خوارزمية للعثور على الواصف الأقل استخدامًا وإغلاقه واستبداله مع واصف جديد.

3
Derek Downey