ฉันมีปัญหากับการใช้งาน CPU บนเว็บไซต์ที่ใช้ WordPress, Apache และ MySQL ในระหว่างวัน การใช้งาน CPU ของ MySQL และ Apache สูงถึง 2400% เป็นครั้งคราว (ฉันมีทั้งหมด 24 คอร์) เซิร์ฟเวอร์หยุดทำงาน โหลดเฉลี่ยสูงถึง 24
เมื่อเร็ว ๆ นี้มีการจราจรหนาแน่นกว่าปกติเล็กน้อย แต่สิ่งนี้ไม่น่าจะถาวรใช่ไหม? ฉันได้อัปเดตเคอร์เนล ฐานข้อมูล ไลบรารี รีสตาร์ทหลายครั้ง และยังคงค้าง ฉันได้ดูรายการกระบวนการของ DB แล้ว แต่ไม่มีอะไรพิเศษ ในฐานข้อมูลมีข้อมูลค่อนข้างมาก เมื่อสองสามสัปดาห์ก่อนมันใช้ได้ดี แต่ตอนนี้มันไม่ได้แล้ว ดังนั้นจึงไม่ควรเป็นข้อความค้นหาที่ไม่ได้เพิ่มประสิทธิภาพ
อะไรคือสาเหตุของพฤติกรรมดังกล่าว?
อัปเดต:
ผลลัพธ์ของ A) แสดงสถานะทั่วโลกเช่น 'com_%r%_table';
+----------------------+------+
| ชื่อตัวแปร | ค่า |
+----------------------+------+
| Com_alter_table | 5 |
| Com_create_table | 34 |
| Com_drop_table | 0 |
| Com_rename_table | 0 |
| Com_show_create_table | 0 |
+----------------------+------+
5 แถวในชุด (3.04 วินาที)
B) แสดงสถานะทั่วโลกเช่น 'uptime%';
+------------------------------+++++
| ชื่อตัวแปร | ค่า |
+------------------------------+++++
| เวลาทำงาน | 455524 |
| Uptime_since_flush_status | 455524 |
+------------------------------+++++
2 แถวในชุด (0.01 วินาที)
C) แสดงสถานะทั่วโลก เช่น '%dirty%';
+-------------------------------- +++++
| ชื่อตัวแปร | ค่า |
+-------------------------------- +++++
| Innodb_buffer_pool_pages_dirty | 0 |
| Innodb_buffer_pool_bytes_dirty | 0 |
+-------------------------------- +++++
2 แถวในชุด (0.00 วินาที)
ป.ล. ฉันยังคงมีปัญหากับเซิร์ฟเวอร์ ฉันจำเป็นต้องเปลี่ยนชุดอักขระบนฐานข้อมูลใดฐานข้อมูลหนึ่ง และใช้เวลามากกว่าหนึ่งวันจึงจะเสร็จ โดยมีเพียง 400,000 แถว เมื่อก่อนก็ใช้เวลาบ้างแต่ไม่มาก ฉันสงสัย เป็นไปได้ไหมว่าหลังจากการโจมตี DDOS อาจมีการเปลี่ยนแปลงบางอย่างกับฐานข้อมูลเพื่อให้ทำงานได้แย่ลง
อัปเดต 2:
ผลลัพธ์ mysqltuner:
[--] ข้ามการตรวจสอบเวอร์ชันสำหรับสคริปต์ MySQLTuner
[ตกลง] เข้าสู่ระบบโดยใช้ข้อมูลรับรองจากบัญชีบำรุงรักษา Debian
[ตกลง] ขณะนี้รองรับ MySQL เวอร์ชัน 8.0.26-0ubuntu0.20.04.2
[ตกลง] ทำงานบนสถาปัตยกรรม 64 บิต
-------- คำแนะนำไฟล์บันทึก --------------------------------------- ---------------------------
[ตกลง] ไฟล์บันทึก /var/log/mysql/error.log มีอยู่
[--] ไฟล์บันทึก: /var/log/mysql/error.log(0B)
[--] ไฟล์บันทึก /var/log/mysql/error.log ว่างเปล่า สมมติว่าบันทึกการหมุน ใช้ --server-log={file} สำหรับไฟล์ที่ชัดเจน
-------- สถิติเครื่องมือจัดเก็บข้อมูล --------------------------------------- --------------------------
[--] สถานะ: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MEMORY +MRG_MYISAM +MyISAM +PERFORMANCE_SCHEMA
[--] ข้อมูลในตาราง InnoDB: 262.4G (ตาราง: 179)
[ตกลง] ตารางที่แยกส่วนทั้งหมด: 0
-------- ตัวชี้วัดประสิทธิภาพการวิเคราะห์ --------------------------------------- -----------------------
[--] innodb_stats_on_metadata: ปิด
[ตกลง] ไม่มีการอัปเดตสถิติระหว่างการสืบค้น INFORMATION_SCHEMA
-------- คำแนะนำด้านความปลอดภัย ---------------------------------------- --------------------------
[--] ข้ามไปเนื่องจากคุณสมบัติที่ไม่รองรับสำหรับ MySQL 8
-------- คำแนะนำด้านความปลอดภัย CVE --------------------------------------- -----------------------
[ตกลง] ไม่พบ CVE ด้านความปลอดภัยสำหรับเวอร์ชันของคุณ
-------- การวัดประสิทธิภาพ ---------------------------------------- -------------------------------
[--] เพิ่มขึ้นสำหรับ: 5d 11h 4m 6s (15M q [31.945 qps], 191K conn, TX: 80G, RX: 2G)
[--] อ่าน / เขียน: 99% / 1%
[--] เปิดใช้งานการบันทึกไบนารี (โหมด GTID: ปิด)
[--] หน่วยความจำกายภาพ : 31.4G
[--] หน่วยความจำ MySQL สูงสุด : 9.8G
[--] หน่วยความจำกระบวนการอื่น: 0B
[--] บัฟเฟอร์ทั้งหมด: 176.0M ทั่วโลก + 65.1M ต่อเธรด (สูงสุด 151 เธรด)
[--] P_S การใช้หน่วยความจำสูงสุด: 72B
[--] การใช้หน่วยความจำสูงสุดของ Galera GCache: 0B
[ตกลง] การใช้หน่วยความจำสูงสุด: 9.8G (31.14% ของ RAM ที่ติดตั้ง)
[ตกลง] การใช้หน่วยความจำสูงสุดที่เป็นไปได้: 9.8G (31.14% ของ RAM ที่ติดตั้ง)
[ตกลง] การใช้หน่วยความจำที่เป็นไปได้โดยรวมกับกระบวนการอื่นนั้นเข้ากันได้กับหน่วยความจำที่มีอยู่
[ตกลง] ข้อความค้นหาช้า: 0% (0/15M)
[!!] การใช้งานการเชื่อมต่อสูงสุด: 100% (151/151)
[ตกลง] การเชื่อมต่อที่ถูกยกเลิก: 0.09% (174/191712)
[!!] การจำแนกชื่อเปิดใช้งานอยู่ : การจำแนกชื่อแบบย้อนกลับถูกสร้างขึ้นสำหรับการเชื่อมต่อใหม่แต่ละครั้ง และสามารถลดประสิทธิภาพการทำงานได้
[--] ลบแคชแบบสอบถามใน MySQL 8 แล้ว
[ตกลง] การเรียงลำดับที่ต้องการตารางชั่วคราว: 0% (การเรียงลำดับอุณหภูมิ 0 ครั้ง / การเรียงลำดับ 5M)
[ตกลง] ไม่มีการรวมโดยไม่มีดัชนี
[ตกลง] ตารางชั่วคราวที่สร้างขึ้นบนดิสก์: 0% (0 บนดิสก์ / ทั้งหมด 2M)
[ตกลง] อัตราการเข้าถึงแคชของเธรด: 92% (สร้าง 15K / เชื่อมต่อ 191K)
[ตกลง] อัตราการเข้าถึงแคชของตาราง: 99% (การเข้าถึง 21M / คำขอ 21M)
[ตกลง] table_definition_cache(2000) สูงกว่าจำนวนตาราง (506)
[ตกลง] ขีดจำกัดการเปิดไฟล์ที่ใช้: 0% (6/10K)
[ตกลง] ได้รับล็อคโต๊ะทันที: 100% (9 ทันที / 9 ล็อค)
[ตกลง] การเข้าถึงหน่วยความจำแคช Binlog: 99.57% (25538 หน่วยความจำ / 25647 ทั้งหมด)
-------- แผนการปฏิบัติงาน ---------------------------------------- --------------------------------
[--] หน่วยความจำที่ใช้โดย P_S: 72B
[--] ติดตั้งสคีมา Sys แล้ว
-------- ตัวชี้วัด ThreadPool ---------------------------------------- --------------------------------
[--] สถานะ ThreadPool ถูกปิดใช้งาน
-------- เมตริก MyISAM ---------------------------------------- ------------------------------------
[--] MyISAM Metrics ถูกปิดใช้งานใน MySQL เวอร์ชันล่าสุด
-------- ตัวชี้วัด InnoDB ---------------------------------------- ------------------------------------
[--] เปิดใช้งาน InnoDB
[--] การทำงานพร้อมกันของเธรด InnoDB: 0
[ตกลง] เปิดใช้งานไฟล์ InnoDB ต่อตารางแล้ว
[!!] บัฟเฟอร์พูล InnoDB / ขนาดข้อมูล: 128.0M/262.4G
[!!] Ratio InnoDB log file size / InnoDB Buffer pool size (75 %): 48.0M * 2/128.0M ควรเท่ากับ 25%
[ตกลง] อินสแตนซ์ของพูลบัฟเฟอร์ InnoDB: 1
[--] จำนวน InnoDB Buffer Pool Chunk : 1 ต่อ 1 Buffer Pool Instance(s)
[ตกลง] Innodb_buffer_pool_size สอดคล้องกับ Innodb_buffer_pool_chunk_size & Innodb_buffer_pool_instances
[ตกลง] ประสิทธิภาพบัฟเฟอร์การอ่าน InnoDB: 98.29% (925392031 ครั้ง/ รวม 941450541 ครั้ง)
[!!] ประสิทธิภาพ InnoDB Write Log: 309.39% (25100125 ครั้ง/ ทั้งหมด 8112662 ครั้ง)
[!!] บันทึก InnoDB รอ: 0.00% (65 รอ / 33212787 เขียน)
-------- Aria เมตริก ---------------------------------------- --------------------------------------
[--] Aria Storage Engine ไม่พร้อมใช้งาน
-------- TokuDB เมตริก ---------------------------------------- ------------------------------------
[--] TokuDB ถูกปิดใช้งาน
-------- ตัวชี้วัด XtraDB ---------------------------------------- ------------------------------------
[--] XtraDB ถูกปิดใช้งาน
-------- Galera เมตริก ---------------------------------------- ------------------------------------
[--] Galera ถูกปิดใช้งาน
-------- เมตริกการจำลองแบบ ---------------------------------------- -------------------------------
[--] การจำลองแบบซิงโครนัสของ Galera: NO
[--] ไม่มีการจำลองแบบทาสสำหรับเซิร์ฟเวอร์นี้
[--] รูปแบบ Binlog: ROW
[--] รองรับ XA: เปิด
[--] ต้นแบบการจำลองแบบกึ่งซิงโครนัส: ไม่ได้เปิดใช้งาน
[--] ทาสการจำลองแบบกึ่งซิงโครนัส: ไม่ได้เปิดใช้งาน
[--] นี่คือเซิร์ฟเวอร์แบบสแตนด์อโลน
-------- ข้อแนะนำ ----------------------------------------- ----------------------------------
คำแนะนำทั่วไป:
ลดหรือกำจัดการเชื่อมต่อแบบถาวรเพื่อลดการใช้การเชื่อมต่อ
กำหนดค่าบัญชีของคุณด้วย ip หรือ subnets เท่านั้น จากนั้นอัปเดตการกำหนดค่าของคุณด้วยskip-name-resolve=1
ก่อนเปลี่ยน innodb_log_file_size และ/หรือ innodb_log_files_in_group โปรดอ่านสิ่งนี้: *link*
ตัวแปรที่จะปรับ:
max_connections (> 151)
wait_timeout (< 28800)
interactive_timeout (< 28800)
innodb_buffer_pool_size (>= 262.4G) ถ้าเป็นไปได้
innodb_log_file_size ควรเป็น (=16M) หากเป็นไปได้ ดังนั้นขนาดไฟล์บันทึกทั้งหมดของ InnoDB จะเท่ากับ 25% ของขนาดบัฟเฟอร์พูล
innodb_log_buffer_size (>= 16M)
อัปเดต 3:
วันนี้เซิร์ฟเวอร์ของฉันหยุดทำงานอีกครั้ง กระบวนการที่โอเวอร์โหลด CPU คือ apache2 ฉันสามารถหยุดบริการได้ และทันใดนั้นทุกอย่างก็เริ่มทำงานได้อย่างราบรื่น ฉันได้พยายามสำรองข้อมูลของฐานข้อมูล ซึ่งเป็นฐานข้อมูลที่มีแถวจำนวนมาก และมันก็ใช้ได้ดี แต่หลังจากนั้นไม่นาน ทุกอย่างก็หยุดทำงานอีกครั้ง: การใช้งาน CPU โดยบางกระบวนการอยู่ที่ 2400% ค่าเฉลี่ยการโหลดเกิน 24 ดังนั้น คำแนะนำของฉันคือ ไม่ใช่ apache ที่โหลด CPU ไม่ใช่ MySQL เช่นกัน กระบวนการบางอย่าง เช่น htop หรือ gzip ที่ฉันใช้สำหรับการสำรองข้อมูล ก็มีการใช้งาน CPU สูงเป็นครั้งคราวเช่นกัน จะเป็นอย่างไร นี่อาจเป็นผลมาจากการโจมตี DDOS และถ้าเป็นเช่นนั้น ฉันจะแก้ไขได้อย่างไร
อัตราต่อวินาที = RPS
คำแนะนำที่ควรพิจารณาสำหรับส่วน my.cnf [mysqld] ของคุณ
innodb_buffer_pool_size=22G # จาก 128M เพื่อรองรับข้อมูล 262G ของคุณได้ดียิ่งขึ้น
max_connections=256 # จาก 151 เนื่องจากคุณใช้การเชื่อมต่อทั้งหมดแล้ว
thread_cache_size=150 # จาก 9 เพื่อลด threads_created RPhr จาก 111
innodb_log_file_size=4G # จาก 50M เพื่อรองรับมากกว่าหนึ่งชั่วโมงก่อนการหมุน
innodb_log_buffer_size=1G # จาก 16M เพื่อรองรับ ~ 30 นาทีก่อนเขียนสื่อ
ควรปรับปรุงประสิทธิภาพอย่างมาก มีโอกาสอีกมากมายในการปรับปรุงประสิทธิภาพ ดูโปรไฟล์สำหรับข้อมูลติดต่อและสคริปต์ยูทิลิตี้ที่ดาวน์โหลดได้ฟรีเพื่อปรับปรุงประสิทธิภาพ
มันพูดยากมาก แต่คุณกำลังบอกว่าคุณกำลังใช้งาน WordPress และมันมีค่าสูงสุด 24 คอร์ของคุณถึง 100% เพียงจำไว้ว่าแบบสอบถามเดียวไม่สามารถใช้เพียง 1 เธรดในแต่ละครั้ง
มีบางอย่างที่ฟังดูแย่และไม่ได้ส่งตรงไปยังเว็บเซิร์ฟเวอร์ Apache ของคุณ คุณได้ลองใช้ปลั๊กอิน "WP Redis Cache" เพื่อแคชข้อความค้นหาของคุณใน Redis เพื่อบันทึกการค้นหาข้อความค้นหาหรือไม่
ปลั๊กอินถัดไปที่คุณสามารถลองติดตั้งได้คือ "Query Monitor" ซึ่งจะแสดงการสืบค้น SQL ที่คุณกำลังเรียกใช้ทันที ซึ่งเป็นเครื่องมือแก้ไขจุดบกพร่องที่ดีมากสำหรับ WordPress
โปรดจำไว้ว่าหากคุณกำลังพัฒนาปลั๊กอินของคุณเองใน WordPress คุณควรดูแล Redis ด้วยตัวเองโดยใช้ฟังก์ชันในตัวเพื่อแคชผลลัพธ์การค้นหาของคุณ
และในตอนท้ายของการดีบักด้วยวิธีนี้ ฉันจะแนะนำให้คุณเปิดใช้งานการสืบค้นแบบบันทึกช้าสำหรับ MySQL สำหรับทุกสิ่งที่เกิน 1 วินาที คุณอาจพบการสืบค้นที่ดัชนีสำหรับคอลัมน์ขาดหายไป
คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา
