Глядя на вывод команды top на нашем сервере, один из моих коллег сказал мне, что тот факт, что некоторые процессы имеют менее 100% ЦП, объясняется тем, что я выполняю слишком много процессов. Он добавил, что исходя из его опыта, если я запускаю менее 6 процессов, то, вероятно, все процессы будут иметь 100% ЦП.
Я не хочу раздражать других пользователей, но сомневаюсь, что он сказал правильно. Сервер имеет 16 ядер, и текущая средняя нагрузка составляет от 10 до 11. Насколько я знаю, он не перегружен. Но я не знаю, почему некоторые процессы просто получают менее 100% ЦП? Неужели это из-за меня?
Спасибо и привет!
Вот вывод top:
top - 16:34:13 up 32 days, 1:36, 12 users, load average: 10.61, 10.39, 10.22
Tasks: 380 total, 10 running, 370 sleeping, 0 stopped, 0 zombie
Cpu(s): 55.0%us, 1.7%sy, 0.0%ni, 42.2%id, 0.5%wa, 0.1%hi, 0.4%si, 0.0%st
Mem: 130766620k total, 39859784k used, 90906836k free, 849412k buffers
Swap: 47351548k total, 279456k used, 47072092k free, 19792956k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
17197 tim 18 -2 1315m 1.3g 1504 R 100 1.0 4510:11 MLtest
28762 tim 18 -2 1315m 1.3g 1504 R 100 1.0 4633:01 MLtest
29249 tim 18 -2 1315m 1.3g 1504 R 100 1.0 4623:03 MLtest
29560 tim 18 -2 1315m 1.3g 1504 R 100 1.0 4626:59 MLtest
4904 tim 18 -2 1315m 1.3g 1504 R 100 1.0 4757:12 MLtest
5143 tim 18 -2 1315m 1.3g 1504 R 100 1.0 4759:40 MLtest
29389 tim 18 -2 1315m 1.3g 1504 R 99 1.0 4622:11 MLtest
5285 tim 18 -2 1315m 1.3g 1504 R 97 1.0 4758:49 MLtest
4763 tim 18 -2 1315m 1.3g 1504 R 93 1.0 4754:22 MLtest
9456 zma 18 -2 206m 85m 11m S 48 0.1 60:46.78 dropbox
7527 vals 18 -2 1266m 436m 42m S 4 0.3 613:57.10 MATLAB
2903 root 15 -5 0 0 0 S 1 0.0 19:00.01 rpciod/0
19133 vals 18 -2 1380m 503m 42m S 1 0.4 798:47.99 MATLAB
12454 tim 18 -2 19248 1588 1024 R 1 0.0 0:48.88 top
12 root RT -5 0 0 0 S 1 0.0 35:01.05 migration/3
2924 root 15 -5 0 0 0 S 1 0.0 27:20.92 nfsiod
12690 jun 18 -2 913m 84m 2684 S 1 0.1 121:55.65 MATLAB
19650 jun 18 -2 19244 1600 1028 S 1 0.0 6:58.41 top
6 root RT -5 0 0 0 S 0 0.0 129:49.45 migration/1
9 root RT -5 0 0 0 S 0 0.0 104:34.66 migration/2
2870 daemon 20 0 8180 404 308 S 0 0.0 5:18.91 portmap
8985 root 20 0 28484 344 264 S 0 0.0 6:24.77 hald-addon-stor
9293 root 20 0 369m 4208 2316 S 0 0.0 83:36.35 kdm_greet
24028 tim 18 -2 871m 140m 45m S 0 0.1 7:50.56 MATLAB
1 root 20 0 4104 304 224 S 0 0.0 0:03.59 init
2 root 15 -5 0 0 0 S 0 0.0 0:00.26 kthreadd
3 root RT -5 0 0 0 S 0 0.0 0:00.31 migration/0
4 root 15 -5 0 0 0 S 0 0.0 1:08.91 ksoftirqd/0
Не уверен, о чем говорит ваш друг, но это звучит довольно произвольно и ... ну, явно неверно.
Процент измерения ЦП несколько вводит в заблуждение. Фактически, любой процесс, который в данный момент находится "на" ЦП, в этот момент получает 100% ЦП. Процент относится к тому, сколько процессорного времени эти процессы получили во время последней выборки времени.
Так что тот факт, что они отображают менее 100% загрузки ЦП, не является признаком проблемы.
Более подходящим показателем в вашем главном выводе является следующая строка: ЦП: 55,0% us, 1,7% sy, 0,0% ni, 42,2% id, 0,5% wa, 0,1% hi, 0,4% si, 0,0% st.
Он показывает 42% простоя ЦП. Таким образом, ваши другие процессы, какими бы они ни были, не связаны с процессором.
Ваш друг не только неправ, но и если вы сделаете то, что он говорит, это может оказаться контрпродуктивным. Если у вас 16 ядер и нагрузка 10, вам, вероятно, следует увеличить количество запущенных процессов MLTest, если в настоящее время оно ограничено только 9 и каким-либо образом настраивается. Зачем?
Ну, процесс обычно может работать только на 1 процессоре. Если процесс использует 100% ЦП, он привязан к ЦП. Итак, если вы ограничиваете и говорите, что можете использовать только 9 процессов для того, что делает MLTest, то вы можете использовать только 9 из этих 16 процессоров.
Под нагрузкой понимается количество процессов, ожидающих запуска. Очевидно, у вас есть 10 процессов, которые необходимо запустить на ЦП. Кто знает, что им нужно делать. Но если вы позволяете процессам MLTest запускаться только на нескольких ЦП (помните, по одному процессу на ЦП), тогда у вас (может) быть высокая нагрузка, потому что все эти процессы всегда выполняются или ожидают запуска. Однако, разрешив большему количеству процессов, вы сможете выполнять больше задач быстрее, и вам не придется ждать, чтобы запустить так много времени.
Однако это лишь один теоретический сценарий. Чтобы конкретно решить проблему, нужно ответить:
1) какой (процесс) ожидает запуска (вызывая нагрузку)? 2) Вы ограничиваете количество процессов MLTest, которые могут выполняться? 3) Если вы позволите запускать больше процессов MLTest, будет ли это быстрее «решать» вашу проблему / программу?
Вы можете нажать «1» (один) и top покажет статистику ЦП вверху для каждого ЦП. Вы можете найти это информативным.
Программы не просто ждут от процессора. Они ждут на диске сетевого ввода-вывода; они ждут ввода пользователя. Не каждая запущенная программа будет использовать 100% ЦП для кванта обновления top. Например, когда ничего не работает, вы видите init потребляет 100% CPU? Нет.
Это может быть вызвано рядом причин, и сначала я бы сказал, что это не повод для беспокойства или беспокойства.
Не зная ничего больше о том, что вы делаете, чем список процессов, который вы включили, и ничего не зная на самом деле о Matlab, я собираюсь предложить некоторые возможные вещи, которые происходят, что совершенно нормально и может привести к тому, что вы наблюдаем.
Однако сначала я хочу отметить, что top показывает вам среднее значение за определенный период времени, и, вероятно, очень короткое - порядка нескольких секунд. Один из ваших процессов, работающий всего лишь на 93% в течение пары секунд (а не на 100%), не имеет большого значения. Вероятно, он вернется к 100% (и другому процессу до 93%) в следующем интервале.
Вернуться к почему:
Если процесс делает что-либо, требующее системного вызова, особенно дисковый ввод-вывод, он может некоторое время бездействовать, ожидая завершения этой операции. Это приведет к загрузке ЦП <100%, поскольку часть времени блокируется при вводе-выводе. Здесь определенно сказываются процессы других пользователей. Может быть более чем достаточно ядер, но если вы все боретесь за пропускную способность одного и того же жесткого диска, тогда никто не увидит 100% загрузки процессора.
Кажется, ваше приложение использует несколько процессов или даже несколько потоков одновременно. Это может ускорить процесс до определенного момента (и это напрямую зависит от приложения и того, как оно распределяет работу). Однако это также может иметь связанные с этим затраты, когда дело доходит до связи между процессами. Если, например, каждый дочерний процесс (или поток) должен взаимодействовать друг с другом, то количество каналов связи значительно возрастает по мере увеличения количества процессов. Даже если каждый процесс взаимодействует только с главным ответственным процессом, потомки могут блокировать связь с родителем, когда родитель разговаривает с другим дочерним процессом. На самом деле это не так уж и отличается от блокировки дискового ввода-вывода.
В конце концов, даже с бесконечным количеством ядер, вы, вероятно, увидите убывающую отдачу от каждого дополнительного процесса, который вы используете для выполнения своей работы. Вероятно, где-то есть золотая середина, и, возможно, это 6, как предлагает ваш коллега. Но я бы не стал использовать его анализ (поиск <100% использования), чтобы определить, где находится эта золотая середина.