it-swarm.asia

ممكن أن تستخدم MySQL أكثر من جوهر واحد؟

لقد تم تقديم بعض خوادم MySQL المخصصة التي لا تستخدم أكثر من مركز واحد. أنا مطور أكثر من DBA لـ MySQL لذا أحتاج إلى بعض المساعدة

اقامة

الخوادم ضخمة للغاية مع نوع تحميل OLAP/DataWarehouse (DW):

  • أساسي: 96 جيجابايت من ذاكرة الوصول العشوائي ، 8 نوى + مجموعة RAID 10 واحدة
  • اختبار: 32 جيجابايت RAM مع 4 نوى
  • أكبر قاعدة بيانات هي 540 غيغابايت ، ويبلغ الإجمالي حوالي 1.1 تيرابايت ومعظم جداول إنودب
  • سولاريس 10 إنتل -64
  • MySQL 5.5.x

ملحوظة: أكبر قاعدة بيانات هي النسخة المنسوخة من خادم OLTP DR ويتم تحميل DW من هذا. ليس DW كامل: فقط من 6 أشهر إلى 6 أسابيع لذا فهو أصغر من OLTP DB.

ملاحظات على خادم اختبار

  • 3 اتصالات منفصلة
  • لكل منها متزامن (ومختلف) ALTER TABLE...DROP KEY...ADD INDEX
  • تحتوي الجداول الثلاثة على 2.5 و 3.8 و 4.5 مليون صف
  • يرتفع استخدام وحدة المعالجة المركزية إلى 25٪ (يبلغ الحد الأقصى للنواة الواحدة) وليس أعلى
  • 3 ALTERs تستغرق 12-25 دقيقة (واحدة على الأصغر تستغرق 4.5)

الأسئلة

  1. ما هو الإعداد أو التصحيح المطلوب للسماح باستخدام أكثر من قلب واحد؟
    هذا هو ، لماذا لا تستخدم MySQL جميع النوى المتاحة؟ (مثل RDBMS أخرى)
  2. هل هي نتيجة للنسخ المتماثل؟

الملاحظات الأخرى

  • أنا أفهم الفرق بين "مؤشر ترابط" RDBMS و "مؤشر ترابط" نظام التشغيل
  • أنا لا أسأل عن أي شكل من أشكال التوازي
  • بعض متغيرات النظام لـ InnoDB وسلاسل العمليات دون المستوى الأمثل
    (تبحث عن فوز سريع)
  • على المدى القصير ، لا يمكنني تغيير تخطيط القرص
  • يمكن تعديل نظام التشغيل إذا لزم الأمر
  • يستغرق جدول ALTER واحد على أصغر طاولة 4.5 دقيقة (IMO صادم)

تحرير 1

  • تم تعيين innodb_thread_concurrency على 8 على كليهما. نعم ، هذا خطأ ولكن لن يجعل MySQL يستخدم نوى متعددة
  • innodb_buffer_pool_size هو 80 غيغابايت في المرحلة الأساسية ، و 10 غيغابايت في الاختبار (تم إيقاف تشغيل مثيل آخر). هذا جيد الآن.
  • innodb_file_per_table = قيد التشغيل

تحرير 2

  • innodb_flush_log_at_trx_commit = 2
  • innodb_use_sys_malloc = تشغيل
  • يجب أن يكون innodb_flush_method O_DIRECT (ولكن SHOW VARIABLES لا تعرض هذا)
  • innodb_doublewrite = إيقاف
  • نظام الملفات = ZFS (وجد مسؤول النظام الخاص بي هذا: http://blogs.Oracle.com/realneel/entry/mysql_innodb_zfs_best_practices )

لاختبار

  • innodb_flush_method لا يتم عرضه كـ O_DIRECT في الوقت الذي يجب أن يكون فيه
  • سيتبع إعدادات RolandoMySQLDBA

اسمحوا لي أن أعرف إذا فاتني أي شيء مهم

في صحتك

تحديث

تم تغيير إعدادات innodb_flush_method + 3 x thread في إجابة RolandoMySQLDBA
النتيجة:> نواة واحدة مستخدمة للاختبارات = نتيجة إيجابية

136
gbn

لقد ناقشت بالفعل innodb_thread_concurrency مع خبير MySQL في مؤتمر Percona Live NYC في مايو 2011 .

تعلمت شيئًا مدهشًا: بالرغم من التوثيق من الأفضل أن تغادر innodb_thread_concurrency عند 0 (التزامن اللانهائي). بهذه الطريقة يقرر InnoDB أفضل عدد من innodb_concurrency_tickets لفتح إعداد مثيل MySQL معين.

بمجرد تعيين innodb_thread_concurrency إلى 0 ، يمكنك ضبط innodb_read_io_threads و innodb_write_io_threads (كلاهما منذ MySQL 5.1.38) إلى أقصى قيمة 64. وهذا يجب أن يشرك المزيد من النوى.

130
RolandoMySQLDBA

سيستخدم MySQL تلقائيًا نوى متعددة ، لذلك إما أن يكون حملك بنسبة 25 ٪ صدفة1 أو تكوين خاطئ محتمل في سولاريس. لن أتظاهر بأنني أعرف كيفية ضبط الطاقة الشمسية ، ولكن إليك مقال يتناول بعض معلومات ضبط خاصة بال سولاريس .

لقد تم إجراء إصلاح شامل لصفحات ضبط InnoDB في MySQL 5.5 ، لذا هناك بعض المعلومات الجيدة هناك أيضًا. من قرص InnoDB IO :

إذا أظهرت أداة Unix top أو إدارة مهام Windows أن نسبة استخدام وحدة المعالجة المركزية مع حمل العمل الخاص بك أقل من 70٪ ، فربما يكون حمل العمل مرتبطًا بالقرص. ربما تقوم بتنفيذ عدد كبير جدًا من عمليات تنفيذ المعاملات ، أو أن تجمع المخزن المؤقت صغير جدًا. صنع التجمع المؤقت أكبر يمكن أن يساعد ، لكن لا تجعله يساوي أكثر من 80٪ من الذاكرة الفعلية.

بعض الأشياء الأخرى للتحقق:

  • تبديل innodb_flush_method إلى O_DIRECT يستحق الاختبار. إذا كان هذا يساعدك ، فقد تحتاج إلى تحميل نظام الملفات مع خيار forcedirectio

  • قم بتغيير innodb_flush_log_at_trx_commit من 1 إلى 0 (إذا كنت لا تمانع في فقدان الثانية الأخيرة عند تعطل الخلية) أو 2 (إذا كنت لا تمانع في فقدان الثانية الأخيرة عند تعطل نظام التشغيل).

  • تحقق من قيمة innodb_use_sys_malloc . تحتوي هذه المقالة على مزيد من المعلومات على المتغير.

    في ذلك الوقت ، لم تكن هناك مكتبات تخصيص ذاكرة تم ضبطها لوحدات المعالجة المركزية متعددة النواة. لذلك ، قام InnoDB بتطبيق مخصص الذاكرة الخاص به في النظام الفرعي لـ mem. يخضع هذا الموزع للحراسة من خلال كائن مزامنة واحد ، والذي قد يصبح عنق الزجاجة.

    ولكن هناك بعض التحذيرات في نهاية القسم حول معنى تشغيل المتغير (يتم تشغيله افتراضيًا في 5.5).

    لاحظ أنه عند تعطيل مخصص ذاكرة InnoDB ، سيتجاهل InnoDB قيمة المعلمة innodb_additional_mem_pool_size.

  • من الممكن أن النسخ المتماثل يسبب بعض المشكلة. أدرك أنك لست مهتمًا بالتوازي ، ولكن من وصف مدونة العمل هذه :

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

في نهاية المطاف ، قد لا يكون InnoDB أفضل محرك لبيانات البيانات ، بسبب العمليات القائمة على القرص التي تحدث. يمكنك التفكير في تغيير جدول (جداول) مستودع البيانات ليكون MyISAM مضغوط .

1بالصدفة ، أعني أن هناك اختناقًا يمنع زيادة حمولتك فوق 25 ٪ ، ولكنه ليس بالضرورة مشكلة مفردة جوهرية.

31
Derek Downey

ملاحظة: هذه الإجابة تدور حول اتصال واحد باستخدام نوى متعددة. كان سؤال OP غامضًا ؛ فقد افترض بشكل خاطئ أن MySQL ككل لا يمكنه استخدام أكثر من قلب واحد. وتشير الإجابات الأخرى بشكل صحيح إلى أن 3-Alter حالة الاختبار مرتبطة حقًا بـ I/O ، وبالتالي فشل في إثبات سؤال العنوان.

سوف يستخدم اتصال واحد فقط جوهر واحد. (حسنًا ، يستخدم InnoDB مؤشرات ترابط أخرى ، وبالتالي النوى ، لبعض عمليات الإدخال/الإخراج ، ولكن هذا ليس مهمًا.)

لقد حصلت على 3 ALTERs ، لذلك لم تكن تستخدم أكثر من 3 قيم أساسية.

للأسف ، حتى PARTITION يستخدم نوى متعددة.

حتى وقت قريب ، كانت أقصى اتصالات بعد 4-8 نوى. يستخدم Xtradb من Percona (المتضمن في MariaDB) استخدامًا متعددًا للنوى المتعددة ، ولكن لا يزال واحدًا فقط لكل خيط. يصل الحد الأقصى لحوالي 32 نوى.

(تحديث في عام 2015 :) اتصالات متعددة مع 5.6 كحد أقصى في حوالي 48 النوى. 5.7 يعد بأن يكون أفضل. (هكذا تقول معايير أوراكل.) ولكن حتى الآن لا يوجد استخدام متعدد النوى لاتصال واحد.

تحديث (بعد الانتقال إلى Oracle OpenWorld): لن يكون للإصدار الجديد 8.x أي توازي.

مزيد من التحديث - 8.0.17 يحتوي على حالات حيث سيستخدم نوى متعددة في عدد قليل جدًا من الاستعلامات المحددة. (أي ، لا تحمس.)

17
Rick James

IMHO وفي حالة الاستخدام الموصوفة ، لن تستخدم أبدًا أكثر من قلب واحد. والسبب هو أن عبء العمل الخاص بك هو IO غير مقيد بوحدة المعالجة المركزية. نظرًا لأن اتصالاتك الثلاثة تنشئ مؤشرًا جديدًا ، يحتاج كل واحد من هؤلاء إلى قراءة الجدول بأكمله من القرص: هذا هو ما يستغرقه الوقت ، وليس حساب الفهارس.

10
jfg956

ضع في اعتبارك أن عنق الزجاجة الخاص بك يمكن أن يكون أداء نظام الملفات IO.

بالإضافة إلى الإعدادات المقترحة منRolandoMySQLDBA ، قمت أيضًا بتعيين إعدادات التحميل noatime في /etc/fstab للقسم الذي يحتوي على دليل بيانات الخلية (/data01/mysql في حالتي مع /dev/sdb1 تم التثبيت على /data01).

بشكل افتراضي ، يسجل لينكس وقت الوصول لكل قرص للقراءة أو الكتابة مما يؤثر سلبًا على الأداء IO الأداء ، خاصة بالنسبة للتطبيقات العالية IO مثل قواعد البيانات. وهذا يعني أنه حتى القراءة البيانات من ملف تؤدي إلى الكتابة على القرص ... WAT!

لتعطيل هذا ، أضف خيار التحميل noatime في /etc/fstab لنقطة التحميل المطلوبة كما يلي (مثال في حالتي):

/dev/sdb1  /data01  ext4  defaults,noatime  0  2

ثم أعد تحميل القسم:

mount -o,remount /data01

سيؤدي هذا إلى تعزيز أداء القراءة/الكتابة للتطبيقات التي تستخدم هذا القسم. ولكن ... لا شيء يضاهي الاحتفاظ بكل بياناتك في الذاكرة.

9
OkezieE