Backend Development 11 min read

Why Do MySQL and Java Processes Hit 900% CPU? Proven Diagnosis & Fixes

Learn how to identify and resolve extreme CPU usage spikes—up to 900%—in MySQL and Java applications by using top, show processlist, indexing, caching, thread analysis, and code adjustments, with real‑world examples and step‑by‑step command guides.

Efficient Ops
Efficient Ops
Efficient Ops
Why Do MySQL and Java Processes Hit 900% CPU? Proven Diagnosis & Fixes

Overview

CPU usage exceeding 200% is a common production issue. This article explains why MySQL and Java processes can reach 900% CPU and provides systematic troubleshooting and optimization methods.

Scenario 1: MySQL CPU Spike to 900%

Diagnosis steps:

Run

top

to confirm the high‑CPU process is

mysqld

.

Execute

show processlist

to locate sessions consuming resources.

Identify heavy SQL statements and examine their execution plans for missing indexes or large data scans.

Remediation:

Kill the offending threads and observe CPU reduction.

Add missing indexes, rewrite inefficient SQL, or adjust memory parameters.

Limit excessive connections and use caching (e.g., Redis) to reduce query frequency.

Iteratively apply optimizations and monitor the impact.

Real‑world MySQL case

A production MySQL instance showed CPU usage above 900% due to unindexed queries and an enabled slow‑log that aggravated the load. By disabling the slow‑log, adding the missing index on

user_code

, and moving frequent reads to Redis cache, CPU dropped to a stable 70‑80%.

<code>show processlist;</code>
<code>select id from user where user_code = 'xxxxx';</code>
<code>show index from user;</code>

Key takeaways: avoid enabling slow‑log under high load, use

show processlist

to pinpoint problematic queries, and combine indexing with caching.

Scenario 2: Java CPU Spike to 900%

Diagnosis steps:

Use

top

to find the Java process PID.

Run

top -Hp &lt;PID&gt;

to list threads and identify the thread with highest CPU.

Convert the thread ID to hexadecimal and search the thread dump.

Execute

jstack

to obtain the stack trace and locate the offending code.

Remediation patterns:

If the thread is in an empty loop or spin‑wait, insert

Thread.sleep

or proper locking.

If excessive object creation triggers frequent GC, reduce allocations or use object pools.

For selector busy‑polling, rebuild the selector as shown in Netty source.

Java CPU 700% Optimization Example

A Java service consumed over 700% CPU. The following commands were used to diagnose and fix the issue:

<code>top</code>
<code>top -Hp 23602</code>
<code>printf "%x\n" 30309</code>
<code>jstack -l 29706 &gt; ./jstack_result.txt</code>
<code>cat jstack_result.txt | grep -A 100 7665</code>

The stack trace pointed to

ImageConverter.run()

. The original loop used

poll()

on a

BlockingQueue

, causing a tight empty‑loop when the queue was empty. Replacing it with

take()

blocks until data arrives, eliminating the CPU burn.

<code>while (isRunning) {
    try {
        byte[] buffer = device.getMinicap().dataQueue.take();
        // process buffer
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
}</code>

After the change, CPU usage fell below 10% and the service stabilized.

Summary

High CPU usage in MySQL and Java processes can be mitigated by proper monitoring, identifying resource‑heavy queries or threads, adding missing indexes, leveraging caching layers, and fixing inefficient code patterns such as empty loops or excessive object creation.

JavacachingCPU OptimizationPerformance TuningMySQLdatabase indexing
Efficient Ops
Written by

Efficient Ops

This public account is maintained by Xiaotianguo and friends, regularly publishing widely-read original technical articles. We focus on operations transformation and accompany you throughout your operations career, growing together happily.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.