Beban CPU tinggi karena MySQL di Linux


1

Saya menghadapi beban CPU yang tinggi karena proses MySQL. Saya googled untuk menyingkirkan kesalahan ini tetapi tidak berhasil.

Saya menemukan solusi di Google seperti itu terjadi karena ruang disk yang rendah namun pada mesin saya yang df -fmenunjukkan di bawah ini. Hanya 77% penuh.

[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

Saya minta maaf atas ketidaknyamanan ini. Sebenarnya saya pindah besar /var/log/mysqld.loguntuk /var/log/mysqld.log.bak. Sekarang tidak ada kesalahan /var/log/mysqld.logseperti yang diposting di bawah ini.

[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

/var/log/mysqld.logDaftar sekarang :

[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 output perintah.

 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 perintah 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

Adakah yang bisa membantu saya dalam hal ini ??


1
Bagaimana dengan inode?
Ignacio Vazquez-Abrams

Terima kasih Ignacio atas tanggapan cepat Anda. Saya tidak mengerti apa yang Anda katakan. Bisakah Anda jelaskan?
MangeshBiradar


2
Bagaimana Anda dapat memiliki beban CPU yang tinggi karena MySQL jika log mengatakan bahwa MySQL tidak dapat memulai ? Anda yakin membaca kesalahan yang relevan? Dan apa sistem melakukan (yaitu apakah menganggur, adalah MySQL menanggapi pertanyaan, ...?)
LSerni

Setelah saya me-restart /etc/init.d/mysqld went dengan baik. Namun setelah waktu tertentu masalah yang sama muncul. Saya telah memperbarui output dari topperintah yang dimaksud di atas.
MangeshBiradar

Jawaban:


4

Untuk menampilkan permintaan yang sebenarnya diproses, masuk ke MySQL dan ketik perintah berikut:

show processlist

Jika tidak ada kueri yang dijalankan, maka Anda dapat menggunakan perintah berikut untuk melacak apa yang sedang dilakukan server:

ltrace -p PID   # trace library calls
strace -p PID   # trace system calls

1

Sistem Anda (seperti kebanyakan) kemungkinan menggunakan tmpfs (sistem file sementara) untuk / var / run (lihat path pada kesalahan).

Coba perintah df tanpa alias:

\df -h

(termasuk backslash). Saya telah alias df saya sendiri untuk tidak menunjukkan hal-hal tmpfs, menjaga output relatif bersih, tetapi Anda perlu melihat output penuh. Anda juga dapat melihat mount apa yang aktif dengan melihat / proc / mounts , tetapi itu tidak menunjukkan penggunaan dan ruang kosong.

Dari sistem saya:

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

Tapi tunggu! Anda mengatakan ... tidak ada / var / jalankan di sana ... Anda benar, mari kita lihat di mana / var / jalankan dalam struktur file:

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/

Dan ada jawabannya: / var / run adalah symlink ke / run , yang ada pada sistem file tmpfs 372Meg.

tmpfs                      372M  748K  371M   1% /run

Lihat / jalankan , saya membayangkan ada beberapa sampah di dalamnya yang memakan ruang. Tidak, saya tidak akan merekomendasikan mengubah ukuran, itu tidak memperbaiki masalah, hanya meletakkan bantuan band di atasnya. Cari tahu apa yang mengisi / menjalankan ... ukuran default ini berfungsi untuk zillions mesin lain, jadi apa yang terjadi dengan Anda?

JIKA Anda tidak tahu apa yang memakan ruang, Anda dapat menyebabkan / menjalankan menjadi lebih besar, tetapi ingat bahwa tmpfs berbagi ram dengan proses. Ini cepat, sementara, tetapi dapat memengaruhi proses yang berjalan jika terlalu besar. Saat ini (default) diatur ke 10% dari core-ram (ram fisik), ini adalah ukuran maksimum. Rincian lebih lanjut dapat ditemukan di manual / etc / default / tmpfs dan tmpfs (5). (Sistem Debian, citarasa lain dapat bervariasi, periksa tmpfs (5) manual terlebih dahulu untuk mendapatkan petunjuk.)

Karena tmpfs sedang digunakan, isinya tidak diawetkan saat reboot, artinya reboot server ini akan segera memperbaiki masalah. Tetapi kecuali Anda mencari tahu mengapa itu terjadi, itu bisa terjadi lagi. Cari tahu apa yang mengisi / menjalankan (/ var / jalankan).

/ var / lock (/ run / lock) & / var / shm (/ run / shm) adalah tunggangan terpisah dan tidak terkait dengan ukuran / run (/ var / run).


Terima kasih banyak lornix. Saya minta maaf atas ketidaknyamanan ini. Saya memperbarui pertanyaan sesuai.
MangeshBiradar
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.