Назад | Перейти на главную страницу

CentOS: MySQLd иногда работает с 333% ЦП. Высокая загрузка процессора

У меня есть несколько веб-сайтов, работающих на Intel Xeon-Lynnfield 3470-Quadcore [2,93 ГГц].

С этим выделенным сервером кажется, что MySQL все еще не оптимизирован для работы на многих посетителях, которые эти веб-сайты создают.

Оперативная память - 16 ГБ. Но, тем не менее, WHM показывает высокую загрузку процессора.

Я публикую ниже результаты top ударив 1 после этого.

top - 10:07:48 up 15:17,  4 users,  load average: 9.04, 6.77, 8.38
Tasks: 308 total,   1 running, 306 sleeping,   0 stopped,   1 zombie
Cpu0  : 11.2%us,  1.7%sy,  0.0%ni, 86.8%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu1  :  4.3%us,  3.0%sy,  0.0%ni,  0.3%id, 85.4%wa,  0.0%hi,  7.0%si,  0.0%st
Cpu2  :  4.3%us,  0.7%sy,  0.0%ni, 94.0%id,  0.0%wa,  0.3%hi,  0.7%si,  0.0%st
Cpu3  :  6.3%us,  2.7%sy,  0.0%ni, 91.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu4  :  6.3%us,  0.7%sy,  0.0%ni, 93.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  : 10.9%us,  2.0%sy,  0.0%ni, 82.5%id,  4.6%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu6  :  0.7%us,  0.3%sy,  0.0%ni, 98.3%id,  0.7%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu7  :  8.6%us,  3.3%sy,  0.0%ni, 84.1%id,  1.0%wa,  0.3%hi,  2.7%si,  0.0%st
Mem:  16428144k total,  6560376k used,  9867768k free,   714452k buffers
Swap:  2096440k total,        0k used,  2096440k free,  3508028k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
19574 songonly  17   0  165m  41m 7348 S  6.3  0.3   0:00.19 php
 2282 root      10  -5     0    0    0 D  4.0  0.0   9:55.06 kjournald
24262 mysql     15   0 1452m 782m 4180 S  1.7  4.9  41:50.00 mysqld
 5196 root      21   0 4371m 123m 9352 S  1.0  0.8   9:24.01 java
19160 root      15   0 12876 1268  812 R  0.7  0.0   0:00.21 top
 1381 root      15   0 94248 3440 2672 S  0.3  0.0   0:00.76 sshd
 5000 named     25   0  286m 6692 1980 S  0.3  0.0   1:44.91 named
10585 nobody    15   0 74404 3744 1544 S  0.3  0.0   0:00.45 httpd
15638 nobody    15   0 74404 3716 1532 S  0.3  0.0   0:00.20 httpd
16790 nobody    15   0 74404 3688 1532 S  0.3  0.0   0:00.12 httpd
17296 nobody    15   0 74404 3708 1524 S  0.3  0.0   0:00.16 httpd
18519 nobody    15   0 74404 3700 1536 S  0.3  0.0   0:00.09 httpd
18718 nobody    15   0 74404 3712 1532 S  0.3  0.0   0:00.08 httpd
19109 nobody    15   0 74404 3664 1524 S  0.3  0.0   0:00.03 httpd
19333 nobody    15   0 74404 3608 1512 S  0.3  0.0   0:00.01 httpd
19351 nobody    15   0 74404 3616 1512 S  0.3  0.0   0:00.01 httpd
19359 nobody    15   0 74404 3640 1520 S  0.3  0.0   0:00.01 httpd
    1 root      15   0 10352  696  588 S  0.0  0.0   0:01.72 init
    2 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 migration/0
    3 root      34  19     0    0    0 S  0.0  0.0   0:00.01 ksoftirqd/0
    4 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/0
    5 root      RT  -5     0    0    0 S  0.0  0.0   0:00.05 migration/1

Если кому поможет.

Спасибо.

Несколько вещей, которые привлекли мое внимание:

  • Цифры загрузки ЦП - это не просто показатель простоя / использования ЦП. У вас может быть высокая нагрузка при относительно низкой загрузке процессора.
  • В 85.4%wa на CPU2 и "D" в записи kjournald указывают на то, что что-то ожидает завершения ввода-вывода диска. Посмотрите, какие процессы ждут, пока IO определит порядок действий (обычно я просто немного смотрю верхний вывод).
  • Вы используете меньше половины своей оперативной памяти. Это происходит либо из-за того, что система на самом деле не нуждается в этом (что нормально), либо из-за неправильной конфигурации настроек MySQL.
  • Согласно последним данным, средняя загрузка ЦП MySQL составляет всего 5% (41 млн за 15 часов). Казалось бы, это указывает на то, что дело не в недостатке процессора.

Представленная информация, похоже, указывает на проблему ввода-вывода. Используйте что-то вроде iotop, чтобы получить больше информации о причинах этого.