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

сервер не отвечает

Сервер не отвечает, и верхний вывод показывает следующее: mysql использует более 500% ЦП

Решит ли перезапуск сервера эту проблему? Столкнусь ли я с той же проблемой после перезагрузки?

# top
top - 06:30:38 up 82 days, 17:43,  1 user,  load average: 117.87, 105.81, 85.65
Tasks: 328 total,  27 running, 299 sleeping,   0 stopped,   2 zombie
Cpu(s):  0.1%us, 99.4%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.5%st
Mem:  35847720k total, 35823272k used,    24448k free,      788k buffers
Swap:        0k total,        0k used,        0k free,    39552k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
15661 mysql     21   0 1192m 282m  904 R 550.8  0.8   1304:06 mysqld
  118 root      17  -5     0    0    0 D 69.4  0.0  27:03.12 kswapd0
26835 root      18   0 10992  936  416 R 62.8  0.0   0:13.51 top
26831 root      19   0 72872  864  224 R 37.2  0.0   0:07.18 php
26881 root      18   0 79944 1528  228 R 18.3  0.0   0:04.96 php

Обновить:

Я добавил буфер ключей myisam до 8 ГБ, кеш запросов до 100 МБ и кеш таблицы до 256 динамически (без добавления его в my.cnf) в поле размером 34 ГБ. Это привело к тому, что ящик перестал отвечать в течение дня.

Я перезапустил службу mysql, но проблема все еще существует.

Фрагментируется ли память из-за динамического изменения этого параметра?

Мне нужно перезапустить сервер?

В вашей коробке не хватает памяти, и происходят странные вещи. У вас ~ 34 ГБ оперативной памяти, и почти вся она занята. Оставшаяся свободная сумма скорее всего зарезервирована в min_free_kbytes.

Поскольку у вас почти не хватает памяти, ядро, вероятно, сходит с ума, пытаясь дефрагментировать вашу память и освободить несколько больших блоков (см. /proc/buddyinfo чтобы получить карту того, как выглядит фрагментация). Итак, что происходит, когда mysql запрашивает память, это то, что ядро ​​заставляет процесс ждать, пока он идет, и дефрагментирует память (пытаясь освободить достаточно большой блок), тем самым отправляя процессорное время на процесс через крышу.

Итак, настоящая проблема здесь в том, куда пропала вся ваша память? Вы можете отсортировать по памяти вверху, нажав M (shift + m).

Изменить (чтобы ответить на ваши дополнительные вопросы):
Перезагрузка сервера мощь помочь в решении проблемы, но, скорее всего, это будет временно. Динамическое изменение настроек MySQL не должно приводить к такому эффекту (если только в коде нет ГЛАВНЫХ ошибок, что маловероятно). Таким образом, независимо от того, был ли параметр изменен во время выполнения или при холодном запуске, вы, скорее всего, снова окажетесь в этой ситуации.
Что касается того, являются ли эти настройки причиной, я не могу на это ответить. Я не знаком с настройкой производительности MySQL.

У вас есть две проблемы:

  1. У вас нет свопа. Это лишает систему возможности удалить бесполезные данные из физической памяти. Это то, что вызывает kswapd крутить и брызгать.

  2. Что-то потребляет большой объем памяти. Что бы это ни было, этого нет в показанном вами фрагменте.

Проверьте свою подсистему хранения. Проблема с дисками в системе?