|
|
|
|
Joined: Oct 2007
Posts: 531 Likes: 13
Addict
|
|
Addict
Joined: Oct 2007
Posts: 531 Likes: 13 |
I don't know if our hosting company has that available. I'll check. They just posted this: hanks for your response.
We found that the server load was alarmingly high, ranging between 40 and 50 , primarily caused by the MySQL service utilising almost all available CPU resources .
Top resource utilising MySQL process:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5385 mysql 20 0 4969428 484784 38516 S 796.4 3.0 106:33.43 /usr/sbin/mysqld
Additionally, we noticed multiple connection hits originating from the IP ranges 45.228.0.0/16 and 179.49.0.0/16 , which appeared to resemble a DDoS-style attack targeting port 443 on your server. To mitigate this, we have blocked both IP ranges in the firewalld service on your server.
Connection hits: https://hw-screenshots.sea-proxy.wi...ac3842b3-2ab7-4c6a-a067-c557df0401e5.png
Afterwards, we restarted both the httpd and MySQL services. Upon further inspection, we observed that MySQL was executing multiple long-running queries for the database “ubbthreads ”, which were continuously looping and consuming excessive CPU resources.
SQL long-running queries: https://hw-screenshots.sea-proxy.wi...a143b5d3-c303-461b-8dcf-9c823908d36f.png
We have attached two files for your reference, named SQL_QUERY.txt and IP_HITS.txt , which contain details of the long-running SQL queries and IP connections hitting the server.
It appears that the issue may be related to application-level code looping or inefficient database queries . We recommend having your developer review and optimise the application code and database related to the domain “stovebolt.com ”.
In addition, we suggest implementing rate limiting for MySQL connections and adjusting interactive timeout values in the MySQL configuration to prevent long-running queries from continuously executing.
Please note that the server did not have the sar utility installed earlier, which made it difficult to analyse historical resource usage and traffic trends. We have now installed sar, which will start collecting system activity data to help analyse future performance and load patterns.
Regarding the conversion of MyISAM to InnoDB, since the issue is being caused by long-running SQL queries in your database, this conversion will not fix inefficient or looping queries in the application;, those queries still need to be optimised by your developer.
Additionally, the conversion can be risky on large tables, as it may lock the tables during the process and impact your live site.
We recommend focusing first on optimising the slow queries and application code loop with the help of a developer to resolve the performance issues effectively.
Last edited by Baldeagle; 10/15/2025 11:50 PM.
|
|
|
|
0 members (),
270
guests, and
100
robots. |
|
Key:
Admin,
Global Mod,
Mod
|
|
|
|
|
|
