Высокая загрузка системы, низкая загрузка ЦП и ОЗУ в Ubuntu 15.04

Здесь не совсем системный администратор, но он пытается просто настроить сервер (на самом деле, арендованный VDS) для некоторых друзей.

Недавно я перевел в основном игровые серверы / MySQL / веб-сайты с одного VPS на другой - хотя с новым не возникло никаких проблем, я продолжаю наблюдать скачок загрузки системы и загружаю оба процессора; предыдущая нагрузка на серверную систему составляла в среднем около 0,3-5,5. Предыдущий сервер был на Ubuntu 14, я экспортировал список пакетов, которые я установил оттуда, и apt-get установил их на новый сервер; Я также rsync переписал большинство файлов со старого сервера (я думаю, что скопировал что-то плохое, что мешает моему ядру ...)

В любом случае, вот результаты моего uname -a:

 Linux ophq 3.19.0-18-generic #18-Ubuntu SMP Tue May 19 18:31:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

И результаты ландшафтной-sysinfo / регистрации на экране:

  Welcome to Ubuntu 15.04 (GNU/Linux 3.19.0-18-generic x86_64)
  System load:  2.13                Processes:           11
  Usage of /:   22.6% of 196.64GB   Users logged in:     1
  Memory usage: 32%                 IP address for eth0: 123.123.123.123
  Swap usage:   0%

(в настоящее время используется один игровой сервер, поэтому используется память - я должен уменьшить сколько оперативной памяти выделено для Minecraft из значений по умолчанию)

Результат top: http://ericbarber.me/serverproblem/top.png

Добавить в это - если я нажимаю F, а затем нажимаю S в «Process Status» и прибегаю к верхним спискам, у меня есть 2 команды, перечисленные в «D» ... kworker / u30: 0 и kworker / u30: 1, что приводит меня к предположению о ядре ...

Я полностью озадачен, почему средняя нагрузка так высока - мои пользователи тестировали и на MC, и на серверах CS: GO, и они не испытывают никакой задержки - я также протестировал веб-серверы, и они поставляют страницы очень быстрые (по сравнению со старым сервером).

Я подумал, что это может быть проблема с прерыванием, поэтому вот результаты cat / proc / interrupts:

http: / /ericbarber.me/serverproblem/interrupts2.png

Наряду с этим, другой вопрос предложил запустить grep. -r / sys / firmware / acpi / interrupts / и отключить любые значения выше 0 ... хотя все мои значения равны 0, к сожалению.

тот же URL, что и выше serverproblem / interrupts.png

Я установил perf и сделал быстрый 30-секундный отчет - но я не слишком понимаю этот вывод:

тот же URL, что и выше serverproblem / perf.png

Я опущу информацию о процессоре, но это процессор Intel Xeon E5-2690, 2 ядра, 2 ГБ ОЗУ, и я считаю, что жесткий диск на 500 ГБ. Приношу свои извинения, если это глупый вопрос или был задан ранее - я работаю над этим уже несколько часов, и я захожу в тупик с прошлым Google, только начинающим с нуля ... что лучше было бы люблю избегать.

Извинения за ссылки .. новые пользовательские ограничения.

Редактировать: Добавить, результаты mpstat:

Linux 3.19.0-18-generic (ophq)  06/05/2015  _x86_64_    (2 CPU)

02:10:35 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal       %guest  %gnice   %idle
02:10:35 PM  all    7.28    0.00    1.72   47.13    0.00    0.09    0.53        0.00    0.00   43.24

2
задан 06.06.2015, 08:13

3 ответа

Это закончило тем, что было тем, чему я верю, чтобы быть ошибкой ядра. После обновления к 4.0.0-040000-универсальному № 201504121935 ожидает мой ЦП, была нормальная и системная нагрузка под.10 в большинстве случаев, если чего-то не происходит на размещенных серверах.

Так или иначе, я использовал следующую ссылку на справку: http://ubuntuhandbook.org/index.php/2015/04/upgrade-to-linux-kernel-4-0-in-ubuntu/

и только сохранить в соответствии с правилами, я сделал следующее как корень и затем перезагрузил машину:

wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.0-vivid/linux-headers-4.0.0-040000_4.0.0-040000.201504121935_all.deb
wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.0-vivid/linux-image-4.0.0-040000-generic_4.0.0-040000.201504121935_amd64.deb
wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.0-vivid/linux-headers-4.0.0-040000-generic_4.0.0-040000.201504121935_amd64.deb
dpkg -i linux-headers-4.0.0*.deb linux-image-4.0.0*.deb
update-grub

До, как я приехал в это - после прочтения бесчисленных форумов и групп новостей/списков рассылки и получения никуда (пытался смешать с BIOS, параметрами загрузки, commit=60, отключая сервисы, изменяя местоположение физического сервера, и т.д.) Я решил или понизить, или обновить ядро... являющееся этим 15.04, является новым, я обновил. Все еще не уверенный первопричина, поскольку я не видел никакие другие сообщения об этой проблеме, мое предположение, состоит в том, когда я использовал rsync от своих старых 14,10 систем, неисправный драйвер был скопирован или дефектный файл ядра - почему 4.0.0 фиксирует, это вне меня..., но по крайней мере больше kworker, пишущего каждые 5 секунд в kern.log и мои жесткие диски.

0
ответ дан 17.04.2019, 22:39

Я недавно столкнулся с подобной проблемой с 14,10 и 15,04 серверами, проследил его до дешевого адаптера дисплея (PCI-E pny geforce 210), вызывающий nouveau для волнований каждый раз, когда дисплей не был присоединен к карте. может быть не связано с Вашей проблемой, но после удаления карты от моего поля она разрешила для меня

0
ответ дан 17.04.2019, 22:39
  • 1
    К сожалению, мой хост переместился в новое поле, и мы все еще видим ту же проблему - однако, никакие проблемы производительности за выходные..., на которые это действительно походит, 2 просто добавляется к действующей нагрузке - но это doesn' t имеют смысл, поскольку kworker все еще иногда находится на уровне 99,99%. Я думаю, что это может иметь некоторое отношение к тому, что первоначально я rsync' d с другого сервера (исключая большую часть ОС определенные каталоги однако) - возможно, конфликт драйвера где-нибудь по пути... – Styx 09.06.2015, 01:29

Иногда жесткий диск мог быть узким местом и вызвать высокую системную нагрузку, таким образом, Вы могли бы хотеть изучить это.

можно проверить эти ссылки на различные предложения об инструментах, которые можно использовать, чтобы узнать, является ли это проблемой в случае.

https://serverfault.com/questions/9428/how-can-i-monitor-hard-disk-load-on-linux

https://softwarerecs.stackexchange.com/questions/460/command-line-tool-on-ubuntu-server-to-see-disk-io-stats

0
ответ дан 17.04.2019, 22:39
  • 1
    На самом деле после нахождения на экране iotop в течение нескольких минут в конечном счете kworker действительно пузырился IO на 99,99% на обоих ядрах процессора (I' m принимающий оба ядра.. [kworker/u30:0] и [kworker/u31:0] являются преступником. Я вышел и работал, другой перфект - видел Ваше сообщение, проверенный iotop, и это закончилось, ха-ха. – Paul Spiegel 06.06.2015, 09:12

Теги

Похожие вопросы