Spec: 8 GB memory / 4 vCPUs / 25 GB ssd
Ubuntu 20.04
My website got hit with a DDoS recently and had this continuous high CPU usage error for 4 days and the site will not load up, I take a look using top -c and it showed 200% CPU usage. I tried SQL tuner but I did not see any significant differences and my site is not able to load up
MySQL Tuner:
>> MySQLTuner 1.8.5 - Major Hayden <major@mhtx.net>
>> Bug reports, feature requests, and downloads at http://mysqltuner.pl/
>> Run with '--help' for additional options and output filtering
[
[OK] Logged in using credentials from Debian maintenance account.
[OK] Currently running supported MySQL version 8.0.27-0ubuntu0.20.04.1
[OK] Operating on 64-bit architecture
[OK] Log file /var/log/mysql/error.log exists
[
[OK] Log file /var/log/mysql/error.log is not empty
[OK] Log file /var/log/mysql/error.log is smaller than 32 Mb
[OK] Log file /var/log/mysql/error.log is readable.
[!!] /var/log/mysql/error.log contains 649 warning(s).
[!!] /var/log/mysql/error.log contains 13 error(s).
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[OK] Total fragmented tables: 0
[
[OK] No stat updates during querying INFORMATION_SCHEMA.
[
[
[
[
[
[
[
[
[
[
[
[!!] Maximum reached memory usage: 9.9G (127.46% of installed RAM)
[!!] Maximum possible memory usage: 9.8G (126.23% of installed RAM)
[!!] Overall possible memory usage with other process exceeded memory
[OK] Slow queries: 0% (15/1M)
[!!] Highest connection usage: 100% (101/100)
[OK] Aborted connections: 0.00% (0/12875)
[!!] name resolution is active : a reverse name resolution is made for each new connection and can reduce performance
[
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 50K sorts)
[OK] No joins without indexes
[OK] Temporary tables created on disk: 0% (0 on disk / 12K total)
[OK] Thread cache hit rate: 89% (1K created / 12K connections)
[OK] Table cache hit rate: 99% (3M hits / 3M requests)
[OK] table_definition_cache(2000) is upper than number of tables(382)
[OK] Open file limit used: 0% (3/10K)
[OK] Table locks acquired immediately: 100% (4 immediate / 4 locks)
[OK] Binlog cache memory access: 100.00% (7 Memory / 7 Total)
[
[
[
[
[
[
[OK] InnoDB File per table is activated
[OK] InnoDB buffer pool / data size: 128.0M/114.8M
[!!] Ratio InnoDB log file size / InnoDB Buffer pool size (75 %): 48.0M * 2/128.0M should be equal to 25%
[OK] InnoDB buffer pool instances: 1
[
[OK] Innodb_buffer_pool_size aligned with Innodb_buffer_pool_chunk_size & Innodb_buffer_pool_instances
[OK] InnoDB Read buffer efficiency: 100.00% (58007737 hits/ 58009344 total)
[!!] InnoDB Write Log efficiency: 89.57% (799 hits/ 892 total)
[OK] InnoDB log waits: 0.00% (0 waits / 93 writes)
[
[
[
[
[
[
[
[
[
[
[
General recommendations:
Check warning line(s) in /var/log/mysql/error.log file
Check error line(s) in /var/log/mysql/error.log file
MySQL was started within the last 24 hours - recommendations may be inaccurate
Reduce your overall MySQL memory footprint for system stability
Dedicate this server to your database for highest performance.
Reduce or eliminate persistent connections to reduce connection usage
Configure your accounts with ip or subnets only, then update your configuration with skip-name-resolve=1
Before changing innodb_log_file_size and/or innodb_log_files_in_group read this:
Variables to adjust:
*** MySQL's maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***
max_connections (> 100)
wait_timeout (< 30)
interactive_timeout (< 28800)
innodb_log_file_size should be (=16M) if possible, so InnoDB total log files size equals to 25% of buffer pool size.
