Высокое использование ЦП, даже без реальной причины

Обнаружено, что проблема связана с ошибкой в ​​usb-creator-gtk. Он устанавливает неправильный размер блока во время создания загрузочного носителя.

Если эта ошибка влияет на вас, вы можете отметить ее здесь: https://bugs.launchpad.net/ubuntu/+source/usb- создатель / + ошибка / 1589028

0
задан 12 May 2018 в 19:42

5 ответов

Я думаю, что ваша основная проблема заключается в том, что вы работаете в режиме рендеринга программного обеспечения. Это использует ваш процессор вместо GPU для рендеринга. Перейдите к Software & amp; Обновления на вкладке «Дополнительные драйверы», чтобы убедиться, что вы используете правильные видеодрайверы.

Я также заметил на вашем исходном снимке экрана htop, что вы использовали 2 ГБ в своем пространстве подкачки. Когда вы начнете заканчивать пространство подкачки, kswapd пережевывает много CPU и IO. Единственные решения здесь - иметь меньше работы или добавить больше памяти на компьютер.

1
ответ дан 17 July 2018 в 14:36

Я вижу браузер Chromium, который отвечает за высокий процессор в соответствии с снимком экрана, предоставленным командой htop. Это просто означает, что с вашим браузером Chromium что-то не так. Чтобы проверить наличие проблем, нажмите Shift + ESC, чтобы использовать Chromium для вызова диспетчера задач Chromium, и проверьте, какой подпроцесс использует самый высокий CPU, это может быть некоторое расширение или вкладка Browser.

Также отключите «Продолжить запуск фоновых приложений при закрытии Google Chrome» в разделе «Настройки хрома»> «Дополнительно». Этот параметр делает работу Chromium даже после закрытия всех вкладок, что может привести к высокому использованию ресурсов в некоторых системах.

2
ответ дан 17 July 2018 в 14:36

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

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

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

в getrlimit() является одним из худших занят-петля "рецидивистов", учитывая огромное количество этих вызовов, которые всегда возвращать те же данные. По крайней мере, для gettimeofday() и clock_gettime(), мы можем сказать, как долго писатель намеревался занят-петля (если это было намеренным, а не просто "побег")

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

из-за размера аргументов каждый процесс хрома, трудно определить назначение каждого из них, но выбирая одну из них наугад, я вижу процесс из 49 нитей. В это один поток периодически вызывает gettid(). Происходит гораздо более высокими темпами и с вкраплениями этих вызовов много, много тысяч неблокируемой функции recvmsg() звонки на 2 дескрипторы (возврат или на обоих) и которые включаются в неблокирующий опрос() вызова. Опрос сразу возвращает 0, после чего есть функции recvmsg() звонки на те же дескрипторы, которые снова равен нулю. (опрос() вызывается с 0 тайм-аут, и хотя возвращаемое значение указывает время ожидания без дескрипторы готовый код выполняет несколько неблокируемых (!) функции recvmsg() звонки на дескрипторы, которые не были готовы, что, естественно, возвращать или каждый раз. Когда это происходит снова и снова, непрерывно, на высокой скорости, они съедают циклов процессора, которые могли быть использованы на производственных производительности программного обеспечения и не имеет никакого выбора, кроме как страдать)

еще один процесс хрома ведет себя аналогично со следующими отличиями: нет gettid() вызов, и есть несколько вызовов фьютекс. Есть также один персонаж пишет в дескриптор, не включенными в опросах процесса. В других процессах, strace показывает, повторил 220 линию последовательности вызовов при успешном выполнении функции clock_gettime(), с sched_yield (), заключенному между каждые 5 из них.

глядя на другой процесс, из 13 нитей, это делает бесконечную череду gettid() вызовы, которые всегда возвращает 1, в то время как диалоги печати выполняется. После того, как диалоговое окно закроется, это будет бесконечная череда приобщены фьютекс()'S и gettid() (пока только 1) вызовы.

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

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

на достаточно быстрой машины, это не так уж заметно, да? :;

[dет, да. Это более чем заметно. Может быть, этот код слишком большой для простых простых решений, но если я мог бы сделать одно предложение, это будет для Google, чтобы отправить тех, кто может прикасаться к коду на "Комбинаторные алгоритмы" класс, чтобы сделать так.]

в ответ на комментарий #1:

двумя способами:

1) это объясняется, по рекомендованной частичное решение (используя "хороший" на Unix/Linux и подобных систем или эквивалент которой доступен на других системах)

[dиода d17]2) можно предположить возможную основу, чтобы помочь исследовать "вылечить" или хотя бы лучше устранить проблему (а "лучше" способ может включать перехват злоупотреблять системные вызовы и, используя эвристику, чтобы душить их - дело не простое, и делается еще труднее, нужно знать, как виновник называет используются по-разному различными хромированными процессов - правда klugey подход, но он может быть работоспособным кем-то, кто действительно понимает хромированные внутренние - без такого понимания, Я имел функционирующая Chrome, которые работали эффективно, не постоянно крутили несколько лет назад (выполняется с помощью LD_PRELOAD), но сдался после того, как укусила крайние случаи я не ожидал, при открытии страниц, осуществивший код пути, которые ранее открытые страницы не успел (в результате странное поведение и/или зависает). Мой подход грубой силы, пластырем пластырь. Единственный надежный подход должен был бы тайм-аут правильное решение, а не перебирая по одному. .... Да, правда было бы лучше, чем обходной путь, но там не так много поваров, вовлеченных в этот бульон (и это не Ричард Столлман соблюдения последовательности, как Столмен сделал с emacs**** код взносам), что я не вижу истинного фиксировать происходящее. )[!dиода d17]

[ **** в emacs можно найти такую же эффективность, проблемы, связанные асинхронного ввода/вывода, так как хром у Киоскера не ведется строгий контроль над тем, как различные платформы рассматриваются те же самые вопросы, что Chrome не удается, и как результат позволил emacs для накопления процессорного времени при отсутствии активности является обоснованным. ]

-2
ответ дан 20 July 2018 в 14:40
  • 1
    Хотя ваши наблюдения кажутся интересными, я не вижу, как вы отвечаете на реальный вопрос. – guntbert 19 July 2018 в 22:22
  • 2
    @guntbert Я хотел ответить на ваш комментарий, используя комментарий, но не смог сделать это в пространстве, выделенном для комментариев, поэтому я отредактировал свое оригинальное сообщение, чтобы вместо этого добавить свой ответ вам. – Michael 20 July 2018 в 06:06

Я думаю, что ваша основная проблема заключается в том, что вы работаете в режиме рендеринга программного обеспечения. Это использует ваш процессор вместо GPU для рендеринга. Перейдите к Software & amp; Обновления на вкладке «Дополнительные драйверы», чтобы убедиться, что вы используете правильные видеодрайверы.

Я также заметил на вашем исходном снимке экрана htop, что вы использовали 2 ГБ в своем пространстве подкачки. Когда вы начнете заканчивать пространство подкачки, kswapd пережевывает много CPU и IO. Единственные решения здесь - иметь меньше работы или добавить больше памяти на компьютер.

1
ответ дан 20 July 2018 в 14:40

Я вижу браузер Chromium, который отвечает за высокий процессор в соответствии с снимком экрана, предоставленным командой htop. Это просто означает, что с вашим браузером Chromium что-то не так. Чтобы проверить наличие проблем, нажмите Shift + ESC, чтобы использовать Chromium для вызова диспетчера задач Chromium, и проверьте, какой подпроцесс использует самый высокий CPU, это может быть некоторое расширение или вкладка Browser.

Также отключите «Продолжить запуск фоновых приложений при закрытии Google Chrome» в разделе «Настройки хрома»> «Дополнительно». Этот параметр делает работу Chromium даже после закрытия всех вкладок, что может привести к высокому использованию ресурсов в некоторых системах.

1
ответ дан 20 July 2018 в 14:40
  • 1
    Красные полосы - это потоки ядра, а не Chrome. – rtaft 11 May 2018 в 22:24
  • 2
    Благодаря! Вы только что сказали ядро, но я не понимаю, является ли это системной проблемой, или я могу что-то сделать для ее решения – Giovanni Giampaolo 11 May 2018 в 22:38
  • 3
    @rtaft Обновлен основной текст, можно ли читать выше? – Giovanni Giampaolo 12 May 2018 в 11:57
  • 4
    Чтобы прояснить это, это не обязательно означает, что с самим Chromium что-то не так, но гораздо более вероятно, будет проблема с определенной открытой веб-страницей или расширением браузера. – thomasrutter 20 July 2018 в 08:37

Другие вопросы по тегам:

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