การปรับ Mariadb - การเขียนช้า


0

พื้นหลัง: ฉันมีเว็บไซต์ที่ฉันกำลังย้ายจากเซิร์ฟเวอร์ MariaDB แบบสแตนด์อะโลนไปยังคลัสเตอร์ Galera MariaDB ส่วนนี้ทำให้ฉันแปลงตารางจาก MyISAM จำนวนมากเป็น InnoDB สำหรับสิ่งที่คุ้มค่าเว็บไซต์คือการติดตั้ง joomla ขนาดใหญ่

ส่วนปลายด้านหน้าของเว็บไซต์ทำงานได้ดี ไม่มีปัญหา ส่วนผู้ดูแลระบบช้าอย่างเจ็บปวดในการบันทึกอะไร - 25-30 วินาทีจากเวลาที่คุณกดบันทึกจนกว่าจะเสร็จสิ้น

เซ็ตอัพเซ็ตอัพ 3 โหนด Galera - 12 คอร์ Intel (R) Xeon (R) CPU E5-1650 v4 @ 3.60GHz 64GB w SSD บน Raid

HA Proxy สำหรับการทำโหลดบาลานซ์

/etc/my.cnf

[mysqld]
innodb_buffer_pool_siz=32Gb
innodb_log_file_size = 2Gb
innodb_flush_method=O_DIRECT
max_connections=750
innodb_flush_log_at_trx_commit=2
innodb_log_buffer_size=2Mb
query_cache_size=0
skip_name_resolve
sync-binlog=0

ตอนนี้ฉันมีเว็บไซต์พัฒนาเพียงไซต์เดียวเท่านั้นดังนั้นฉันสามารถวัดสิ่งที่เกิดขึ้นได้อย่างน่าเชื่อถือ นี่คือสิ่งที่ฉันสังเกตเห็นด้วยรอเมื่อดำเนินการบันทึกเดียว:

ก่อนที่จะบันทึก:

MariaDB [(none)]> show global status like "%waits%";
+-------------------------------+-------+
| Variable_name                 | Value |
+-------------------------------+-------+
| Innodb_log_waits              | 0     |
| Innodb_mutex_os_waits         | 4     |
| Innodb_mutex_spin_waits       | 4     |
| Innodb_row_lock_current_waits | 0     |
| Innodb_row_lock_waits         | 0     |
| Innodb_s_lock_os_waits        | 9     |
| Innodb_s_lock_spin_waits      | 11    |
| Innodb_x_lock_os_waits        | 1     |
| Innodb_x_lock_spin_waits      | 0     |
| Tc_log_page_waits             | 0     |
+-------------------------------+-------+
10 rows in set (0.01 sec)

หลังจากบันทึก:

MariaDB [(none)]> show global status like "%waits%";
+-------------------------------+-------+
| Variable_name                 | Value |
+-------------------------------+-------+
| Innodb_log_waits              | 0     |
| Innodb_mutex_os_waits         | 177   |
| Innodb_mutex_spin_waits       | 1580  |
| Innodb_row_lock_current_waits | 0     |
| Innodb_row_lock_waits         | 0     |
| Innodb_s_lock_os_waits        | 164   |
| Innodb_s_lock_spin_waits      | 687   |
| Innodb_x_lock_os_waits        | 656   |
| Innodb_x_lock_spin_waits      | 905   |
| Tc_log_page_waits             | 0     |
+-------------------------------+-------+

ฉันรู้ว่ามี innodb มากกว่าค่าใช้จ่ายมากกว่า myisam แต่ฉันคิดว่าการปิดใช้งาน sync-binlog และการตั้งค่า innodb_flush_log_at_trx_commit เป็น 2 จะช่วยได้ แต่สิ่งที่ฉันเห็นจริง ๆ แล้วคือประสิทธิภาพในการเขียนลดลง 1,000%

เพียงมองหาคำแนะนำเกี่ยวกับสิ่งที่ต้องตรวจสอบสิ่งที่อาจผิด ฉันไม่แน่ใจว่าการนับ os_waits นั้นสูงในการบันทึกครั้งเดียวในแอปพลิเคชันดูเหมือนว่าจะเป็นของฉัน แต่ฉันไม่ได้ติดตามสิ่งที่จะทำให้เกิดหรือวิธีการแก้ไข

หลังจากตั้งค่าบันทึกคิวรีช้าเป็น 2s นี่เป็นสิ่งเดียวที่ถูกจับได้ในขณะที่พยายามบันทึก:

# Time: 180126 18:03:38
# User@Host: dev[dev] @  [192.168.10.200]
# Thread_id: 136  Schema: dev  QC_hit: No
# Query_time: 6.306918  Lock_time: 0.000000  Rows_sent: 0  Rows_examined: 109438
# Rows_affected: 82677
use dev;
SET timestamp=1517007818;
UPDATE jos_assets
SET lft = lft + 2
WHERE lft > 337711;
# Time: 180126 18:03:48
# User@Host: dev[dev] @  [192.168.10.200]
# Thread_id: 136  Schema: dev  QC_hit: No
# Query_time: 9.985669  Lock_time: 0.000000  Rows_sent: 0  Rows_examined: 109438
# Rows_affected: 82683
SET timestamp=1517007828;
UPDATE jos_assets
SET rgt = rgt + 2
WHERE rgt >= 337711;

ขอบคุณล่วงหน้า


คุณเห็นอะไรในบันทึกการสืบค้นที่ช้า
Michael Hampton

กำลังเพิ่มไปยังโพสต์
Marc

ลองใช้คำอธิบายอธิบายคำค้นหาช้าที่แสดงไว้ที่นั่น แน่นอนว่ามันทำงานได้มากในเวลาอันสั้น
Simon Greenwood

คำตอบ:


0

ปัญหานี้กลายเป็นเฉพาะ Joomla มากและเกี่ยวข้องกับตาราง _assets ที่ไม่มีประสิทธิภาพ ฉันเดาว่าฉันควรจะตรวจสอบบันทึกการสืบค้นที่ช้าก่อนหน้านี้ แต่อย่างที่คุณเห็นในโพสต์ดั้งเดิมมี 2 ข้อความค้นหาที่อัปเดตตารางในหนึ่ง "บันทึก" เมื่อโพสต์บทความใหม่ทำให้แถว 82677 ได้รับการปรับปรุง แม้ในการปรับใช้ที่รวดเร็วที่สุดก็ต้องใช้เวลา

ทำไม Joomla ต้องทำเช่นนี้ทุกครั้งที่โพสต์ได้รับการบันทึกฉันไม่แน่ใจทั้งหมด แต่งานวิจัยบางอย่างชี้ให้เห็นว่าปลอดภัยที่จะลบบทความทั้งหมดที่เกี่ยวข้องในตารางนั้นซึ่งทำให้มันล้มลงไปทั้งหมดประมาณ 4000 แถว ตอนนี้เร็วขึ้นมาก

สำหรับการอ้างอิงหากคุณมีเว็บไซต์ Joomla ที่ช้าหลังจากแปลงเป็น Innodb นี่คือหน้าฉันพบข้อมูลบางอย่างในตารางสินทรัพย์:

https://www.itoctopus.com/creating-new-articles-on-your-joomla-website-is-taking-a-long-time-clean-your-assets-table

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.