Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I am facing an High CPU load due to MySQL process. I googled to get rid of this error but no luck.

I found solutions on Google like its happening due to low disk space however on my machine the df -f showing below. Its just 77% full.

[root@mydomain log]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                       87G   63G   19G  77% /
/dev/sda1              99M   24M   71M  26% /boot
tmpfs                1014M     0 1014M   0% /dev/shm

I apologies for inconvenience. Actually I moved the large /var/log/mysqld.log to /var/log/mysqld.log.bak. Now there is no such error in /var/log/mysqld.log as posted below.

[ERROR] /usr/libexec/mysqld: Error writing file '/var/run/mysqld/mysqld.pid' (Errcode: 28)
[ERROR] Can't start server: can't create PID file: No space left on device
[ERROR] /usr/libexec/mysqld: Table './db_name/table_name' is marked as crashed and should be repaired

Now /var/log/mysqld.log lists:

[root@mydomain log]# tail -5 /var/log/mysqld.log

130724 08:33:53  mysqld started
130724  8:33:54  InnoDB: Started; log sequence number 0 94462
130724  8:33:54 [Note] /usr/libexec/mysqld: ready for connections.

TOP command output.

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 7831 mysql     18   0  179m  64m 4492 S 95.6  3.2   1168:01 mysqld
12231 root      16   0  2592 1328  900 R  1.8  0.1   0:00.13 top
  136 root      10  -5     0    0    0 S  1.5  0.0  94:19.68 kswapd0

df -i command output:

[root@mydomain log]# df -i
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/mapper/VolGroup00-LogVol00
                     23298048 1235574 22062474    6% /
/dev/sda1              26104      43   26061    1% /boot
tmpfs                 224005       1  224004    1% /dev/shm

Can anyone please help me on this??

share|improve this question
1  
What about inodes? –  Ignacio Vazquez-Abrams Jul 2 '13 at 6:19
    
Thanks Ignacio for your prompt response. I didn't get what you are saying. Could you please elaborate? –  meMangesh Jul 2 '13 at 6:31
    
2  
How can you have a high CPU load due to MySQL if the log says that MySQL could not start? Are you sure you're reading the relevant errors? And what's the system doing (i.e. is it idle, is MySQL responding to queries, ...?) –  lserni Jul 2 '13 at 6:39
    
After I restarts /etc/init.d/mysqld its wents well. however after certain time the same issue raises. I have updated the output of top command in question above. –  meMangesh Jul 2 '13 at 6:43

2 Answers 2

To display actually processed queries, log in to MySQL and type the following command:

show processlist

If no queries are being run, then you can use the following commands to trace what the server is doing:

ltrace -p PID   # trace library calls
strace -p PID   # trace system calls
share|improve this answer

Your system (like most) is likely using a tmpfs (temporary file system) for /var/run (look at the path on the error).

Try the df command without any aliases:

\df -h

(including the backslash). I have aliased my own df to not show tmpfs stuff, keeping the output relatively clean, but you need to see the full output. You can also see what mounts are active by having a look at /proc/mounts, but it won't show usage and space free.

From my system:

xenon-lornix:~> \df -h
Filesystem                 Size  Used Avail Use% Mounted on
rootfs                     451G   23G  406G   6% /
udev                        10M     0   10M   0% /dev
tmpfs                      372M  748K  371M   1% /run
/dev/disk/by-label/xenon   451G   23G  406G   6% /
tmpfs                      5.0M     0  5.0M   0% /run/lock
tmpfs                      2.3G  712K  2.3G   1% /run/shm

But wait! you say... there's no /var/run there... You're correct, let's look where /var/run is in the file structure:

xenon-lornix:~> ls -l /var/
total 40,960
# extra stuff deleted for clarity
drwxrwxrwt  5 root root  4,096 Jul 24 16:02 tmp/
lrwxrwxrwx  1 root root      9 Jul 18 18:44 lock -> /run/lock/
lrwxrwxrwx  1 root root      4 Jul 18 18:44 run -> /run/

And there's the answer: /var/run is a symlink to /run, which is on a 372Meg tmpfs filesystem.

tmpfs                      372M  748K  371M   1% /run

Have a look in /run, I imagine it's got some junk in it that's eating the space. No, I won't recommend changing the size, that doesn't fix the problem, just puts a band-aid on it. Figure out what is filling /run... this default size works for zillions of other machines, so what's going on with yours?

IF you cannot figure out what is eating the space, you can cause /run to be larger, but remember that the tmpfs shares ram with processes. It's fast, temporary, but can impact running processes if it's too large. It's currently (default) set to 10% of core-ram (physical ram), this is a maximum size. More details can be found in /etc/default/tmpfs and the tmpfs(5) manpage. (Debian system, other flavors may vary, check tmpfs(5) manpage first for clues.)

Due to tmpfs being used, the contents are not preserved over a reboot, meaning that a reboot of this server will fix the problem immediately. But unless you figure out why it happened, it could happen again. Find out what's filling /run (/var/run).

/var/lock (/run/lock) & /var/shm (/run/shm) are separate mounts and not related to size of /run (/var/run).

share|improve this answer
    
Thanks a ton lornix. I apologies for inconvenience. I update the question as per. –  meMangesh Jul 25 '13 at 9:48

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.