1 Процесс грузится на 100%, но весь CPU загружен на 30%

Надо обратиться к разработчику этого самого процесса.

предположу сей процесс однопоточный ?? :) тогда оно и понятно.

Слушай, ты уже почти двадцать лет на ЛОРе, четыре звезды нафлудил, а что-то вопросы с каждым разом всё тупее и тупее, будто куда-то в обратную сторону обучение идёт. То про VIRT не знает пользователь с 20+летним опытом, то про процессы, потоки и ядра… Или ты аккаунт успел по наследству следующему поколению передать? Если нет, то может книжку какую почитать по основам?

это заговор интела против фуфыкса

там один тред отвечает за API\HTTP - вот он начинает тупить. Есть другие треды, которые другие функции выполняют, но в целом как я понял клиентов на потоки не раскидывает, потому что если падает 1 клиент - падает все ) Но я не понимаю почему процессор то не используется. Если бы процесс сидел на 1 ядре было бы видно, что оно на 100% загружено, но ни все равномерно. Я пробовал через taskset -pc 1 pid устанавливать, вот тогда было точно заметно что например ядро 3 - 100% используется. Не до конца понял почему так

О господи... чего так возбудился то?

Он всё правильно тебе написал, ты тупняк всякий постишь регулярно.

Однопоточному процессу всё равно на какие ядра его будет раскидывать ОС (конечно же не на одно и то же всегда), но тратить больше чем 100% одного ядра он не может.

В данном случае top показывает насколько процесс загружает 1 ядро.

man top:

In a true SMP environment, if a process is multi-threaded and top is not operating in Threads mode, amounts greater than 100% may be reported. You  toggle Threads mode with the `H' interactive command.

А насчет соединений не знаю, может лимит соединений достигнут (/proc/sys/net/core/somaxconn, например).

но тратить больше чем 100% одного ядра он не может

Понятно, не знал. А почему тогда он все ядра «задействует», а «больше чем 100% одного ядра он не может»? То есть без разницы если я через taskset -pc 1 PID установлю процессу конкретное ядро (оно будет загружено на 100% я проверял)?

Смотри, с 0.000 до 0.100 до исполняется на первом ядре, с 0.100 до 0.200 - на пятом, с 0.200 до 0.300 - на третьем итд. Какое ядро - не важно (и почему ОС его именно туда кинула), важно что в каждый момент времени только одно. ОС видимо кидает так чтобы выравнивать нагрузку на все физические ядра, вот они и поровну получаются. Если делаешь taskset то ядра перестают выбираться рандомно и ограничиваются теми что ты указал, но как и раньше одновременно только одно из них.

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

Процент загрузки процессора не очень информативный индикатор. Может шедулер по разным ядрам раскидывает, вряд ли процесс реально грузит проц, скорее всего просто 99% времени ждет память или io.

В нормальных ОС ожидание io за загрузку проца не считается. В линуксе всё плохо с этим разве?

Где какие критерии тупости, озвучьте или в правилах напишите? Диплом может ещё красный при регистрации СИСЪАДМИНЪ нужно предъявлять? Вот уж докопались ей богу на пустом месте. Сидите тут трясетесь над каждым постом...

Почему он не использует ВСЮ МОЩЬ моего дорогого процессора, за который я плачу огромные деньги?

Налог на глупость

То есть что TOP показывает это может быть IO? Кстати приходят отчеты от zabbix постоянно

Disk read/write request responses are too high (read > 20 ms for 15m or write > 20 ms for 15m)

Может из-за этого? Кстати не знаешь что это? )

Забита очередь диска. Либо дохнет диск, либо(если это не реальная железка, а VPS) - ты уперся в лимиты хостера. И да - ожидание ввода-вывода(IOWAIT) это тоже нагрузка и в top она тоже будет отображаться.

somaxconn это не лимит соединений.

А не работают они потому что у него так процесс устроен скорее всего.

Посмотрел график «Disk average queue size» в том же zabbix, все ровно не выше 20% disk utilization. А дохнет диск (ssd) как понять? smartctl -a смотрел бегло, вроде ничего особенного

Может стоит в логи процесса заглянуть? Может там какая-нибудь нештатная сисуация?(например, какой-нибудь вызов функции зациклился)

да там в логах ничего нет, только периодически сообщения о загрузке 100% (внутренний мониторинг). Смотрел через strace -c -p

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 39.73    0.171081           1    116310           sendto
 19.35    0.083307          18      4387           writev
 10.48    0.045136           1     32752     13195 read
  9.82    0.042287           3     11904           write
  7.36    0.031688           0     36902           epoll_ctl
  6.18    0.026606           0     33250      5188 recvfrom
  3.34    0.014399           1     12617           epoll_wait

Это что-то типа отчета о работе. А если перезапустить процесс, использование CPU сильно меняется?

Процесс не то чтобы постоянно загружен, пиками, раз в пол часа как -то, и в эти моменты невозможно от него ничего получить. В целом не критично, но и не приятно. Причем такое бывает в и пик-часы работы сервера и утро и днем иногда. Перезапуск ничего не дает, он и так периодически падает сам раз в 3 дня ))

А процесс случайно не nodejs называется?

пользователь с 20+летним опытом

Может деменция началась?

Я сталкивался с таким поведением в среде Windows - процесс в какой-то момент начинал потреблять 50%, а через некоторое время 100% CPU. Это что-то с программой, т.к. настроили перезапуск процесса, использование CPU приходило в норму. Логов тоже не было.

Нет там си чистый

Сколько у тебя ядер всего?

12

Запусти 11 процессов, будет полная утилизация.

В top нагрузка на процесс может быть больше 100%, процесс может нагрузить например 5 потоков на 100%, тогда процесс будет загружен на 500% в top, а общая нагрузка на ЦП если ядер 12 будет 100/12*5=42%, если другие процессы в 0%. Так top накодили прост. Если есть iowait или softirq, то они в общую нагрузку идут, не процесса, вроде бы.

Можно ли сказать, что 1 процесс не использует всю мощность процессора, если работает в 1 поток? Хотя REDIS например тоже однопоточный.

make тоже однопоточный, но он запускает другие процессы, а не потоки, если передать make -j12 например.

Да тоже норм. Автор того сервера тоже пишет, что не любит многопоточность, она создает проблемы и это не панацея. В общем то там упор в IO в основном. Наверное надо на диск смотреть ил что там ещё

Можно ли сказать, что 1 процесс не использует всю мощность процессора, если работает в 1 поток?

Твоя проблема в том, что ты до сих пор не понимаешь разницу между процессором и ядром

Можно ли сказать

Я разрешаю.

Если бы я понимал, я бы сюда не писал, наверное. У меня вопросы чисто пользовательские, я вижу что у меня процесс грузится на 100%, а сам проц не загружен и у меня возникает недопонимание от этого, почему я деньги плачу, если у меня проц загружен на 30%, а задача тормозит. Но из вышенаписанного понял, что на это IO влияет, точнее я это знал, но забываешь всегда, ибо не интуитивно это как-то.

А вообще можно было бы короче ответить: Да или Нет.

Повторю ещё раз, примером: Если я запущу однопоточную программу которая будет тупо делить 10/3 в цикле 1 000 000 и запущу эту же программу которая 12 потоков создаст, быстрее будет же второй вариант? С IO понятно что быстрей будет например загрузить параллельно 12 картинок в 12 потоках

О боже

Если я запущу однопоточную программу которая будет тупо делить 10/3 в цикле 1 000 000 и запущу эту же программу которая 12 потоков создаст, быстрее будет же второй вариант?

Естественно, быстрее будет второй вариант.

Если это не Python < 3.14, потому что в Python до недавнего времени треды давали ускорение только на блокирующемся io. Есть и другие языки с GIL, но я сейчас их не вспомню.

и у меня возникает недопонимание от этого, почему я деньги плачу, если у меня проц загружен на 30%, а задача тормозит.

Наоборот. Сначала у тебя недопонимание, а от этого ты платишь неизвестно за что

Если я запущу однопоточную программу которая будет тупо делить 10/3 в цикле 1 000 000 и запущу эту же программу которая 12 потоков создаст, быстрее будет же второй вариант?

Нет. Зависит от

То, что ты упорно называешь процессором, примерно с 2006 называется процессорным ядром (cpu core). Один поток в конкретный момент времени работает может работать на одном ядре.

Если у тебя N ядер, приложение идеально распараллеливается, система ничем другим не загружена, и, главное, задача является cpu-bound, то будет хорошим решением запустить N потоков

Больше потоков будут конкурировать за процеоссорное время и висеть в очереди

Естественно, быстрее будет второй вариант.

Неверно

Например

• а) у него есть только одно ядро
• б) у него задача io-bound

Он там два вопроса задавал: про cpu bound и io bound. Я ответил только на вопрос про cpu bound.

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

А вообще, непонятно, каким образом пользователь с таким огромным стажем и звёздами, может задавать такие простые вопросы.

Не в первый раз замечаю.

так, ну я наверное не правильно сформулировал, конечно цикл то выполнится на всех ядрах за примерно одинаковое время, но одновременно можно выполнять 12 циклов

примерно с 2006 называется процессорным ядром

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

конечно цикл то выполнится на всех ядрах за примерно одинаковое время, но одновременно можно выполнять 12 циклов

У меня такое ощущение, что ты всё ещё не понял

Железо обновилось, а компилятор все также работает с 1 ядром по старинке

Неуд, на пересдачу. Если ты хочешь работать многопоточно, тебе нужно серьезно менять логику приложения

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

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

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

У меня такое ощущение, что ты всё ещё не понял

А что не так разве? Могу в принципе написать на ноде простой тест с форками... 12 циклов...12 ядер...ну конечно возможно будет что разные ядра по разному загружены (планировщиком задач в ОС), но примерно время то будет одинаковое

Неуд, на пересдачу. Если ты хочешь работать многопоточно, тебе нужно серьезно менять логику приложения

Да господи, синхронизация, блокировки, распределение памяти, я все это знаю и работал с этим в java, но я про другое, что если у тебя 1 поток то он должен использовать всю мощность процессора, все ядра, а не тупить в одиночку в углу. Но разрабатывались компиляторы в 70х годах, а ядра как ты говорил в 2006 появились.

что если у тебя 1 поток то он должен использовать всю мощность процессора, все ядра

Нет. Если у тебя один поток, то он использует один поток процессора, собственно поэтому это блин так и называется.

но я про другое, что если у тебя 1 поток то он должен использовать всю мощность процессора, все ядра, а не тупить в одиночку в углу

Никто не обязан выполнять за тебя твою работу и осуществлять твои фантазии. Похоже, звездишь ты все про работу с жабой

Ещё раз, для особо одарённых

То, что ты называешь процессором, больше 20 лет называется ядром даже на домашних процессорах

Два ядра - это два РАЗНЫХ вычислительных устройства. Если ты хочешь, чтобы они оба одновременно работали над ОДНОЙ твоей задачей, твоя задача должна быть переписана под многопоточную логику

Возьми свои фантазии про жабу, почитай учебник, и реализуй многопоточное приложение, которое делает то, что тебе нужно. Не бессвязный бред про деление без цели и результата, а выполнение конкретной задачи. Сравни логику его работы с однопоточной версией. Найди разницу (скорее даже - найди хоть что-то общее)

Но разрабатывались компиляторы в 70х годах, а ядра как ты говорил в 2006 появились.

Компиляторы разрабатываются каждый год.

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