У меня есть 6 ядер и захочется запускать 12 процессов одновременно параллельно .. Я использую MPIRUN, но всасываю и запутанный в варианте, который я буду использовать для многопроцессора на сердечник .. Команда 6 процессов такая
mpirun -np 6 ./the program
и какое максимальное количество процессов, которые можно использовать в одном ядре
Ядро Linux может начать и управлять большим количеством процессов для вас; Больше, чем вы можете использовать. Но более важный вопрос: сколько параллельных процессов полезно для вашей конкретной задачи? Сколько должно быть вы начинаете наилучшим образом использовать ваши системные ресурсы?
, которые нелегко ответить в общем случае. Некоторые задачи являются границей CPU, то есть. Им нужна много вычислительной мощности. Некоторые входные / вывода, то есть они читают много данных с диска или написать много данных на диск. Некоторые являются сетью, то есть они передают много данных по сети. А затем есть использование памяти; Каждая задача требует определенного количества оперативной памяти, будь то физическая или виртуальная оперативная память, включая пространство подкачки; И когда начинается замена, все приходит к визжению остановки, поэтому вы захотите избежать этого.
Итак, у вас есть несколько различных классов системных ресурсов, которые требуют каждая задача, т. Е. Для которых любые параллельные задачи соревнуются:
Если общая миссия состоит в том, чтобы запустить, скажем, 10 000 задач, это зависит от структуры их использования этих системных ресурсов, сколько из них имеет смысл, чтобы быть запущенным параллельно. Если каждая задача не очень интенсивно, но должна дождаться результатов из сети, может иметь смысл иметь смысл большего запуска их большего количества в параллер, чем ядра CPU. Если все они прочитают много данных из файлов, может быть более эффективным не запустить, что многие параллельно, потому что диск ввода / вывода будет ограничительным фактором. Если они все читают тот же файл, это может быть противоположно, потому что файл будет кэшироваться в буферах ввода / вывода.
Это действительно зависит от картины использования, и вы, как правило, приходится экспериментировать, когда сладкое место предназначено для вашей конкретной конфигурации системы (в зависимости от полосы пропускания ввода / вывода, количества ядер CPU, использование CPU, доступных оперативных операций и т. Д.).
Этот ответ только о том, сколько потоков на одной основной части.
Это значительно зависит от нагрузки и памяти на поток. Примеры здесь используют минимальную память и нагрузку на поток, и вы можете наблюдать, как я получаю огромное количество нитей на сердечник.
В этом примере программа будет запущена 30 раз, когда каждое возникновение вращается 1000 потоков. Во-первых, я посмотрю на то, сколько процессов уже связано со мной:
~$ cat /sys/fs/cgroup/pids/user.slice/user-1000.slice/pids.current
14
Затем запустите программу несколько раз, на заднем плане:
doug@s18:~/c$ for i in {1..30}; do ./waiter 1000 100 60 2 999999 0 > /dev/null & done
[1] 635246
[2] 635247
[3] 635248
...
[28] 635426
[29] 635434
[30] 635448
и посмотрите снова на количество потоков:
doug@s18:~$ cat /sys/fs/cgroup/pids/user.slice/user-1000.slice/pids.current
30044
Это на 6 Core, 6 процессор, процессор I5-9600K.
Теперь, как к ограничениям потоков, см. Этот ответ , но и я покажу здесь без поддержки информации, которую вы можете найти в ссылке. Я сделаю 20 раз на 10 000 потоков, вырученные на протяжении всего 200 000 потоков:
doug@s18:~$ cat /sys/fs/cgroup/pids/user.slice/user-1000.slice/pids.current
200034
o.k. Я не делал это только на одном ядре, так что теперь делаю это:
doug@s18:~/c$ for i in {1..20}; do taskset -c 4 ./waiter 10000 100 60 2 999999 0 > /dev/null & done
[1] 85334
[2] 85335
...
[19] 85353
[20] 85354
Нет проблем, и на самом деле я могу добраться до 254000 (по ошибке, если вы должны знать) до того, как среднее значение нагрузки подскочило до более 200000, и все действительно увязнут вниз.
top - 13:53:58 up 9 min, 2 users, load average: 100.06, 2488.11, 2014.59
Tasks: 200179 total, 8 running, 200171 sleeping, 0 stopped, 0 zombie
%Cpu0 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu1 : 18.1 us, 25.7 sy, 0.0 ni, 56.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu2 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu3 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu4 : 25.7 us, 38.7 sy, 0.0 ni, 35.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu5 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 31962.2 total, 6236.9 free, 24814.8 used, 910.5 buff/cache
MiB Swap: 2048.0 total, 2048.0 free, 0.0 used. 6679.1 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1150 doug 20 0 241796 231484 3132 R 43.0 0.7 2:42.53 top
21 root 20 0 0 0 0 S 0.6 0.0 0:01.94 ksoftirqd/1
1 root 20 0 167628 11468 8356 S 0.0 0.0 0:54.61 systemd
Среднее среднее значение высокого нагрузки происходит от фазы запуска и быстро падает. Соблюдайте еще много емкости на CPU 4, но память становится низкой, но неплохо на самом деле.
Однако SystemD, похоже, вступает в трудности, пытаясь убить так много процессов на одном ядре:
top - 14:06:48 up 22 min, 2 users, load average: 143735.08, 78365.08, 32282.72
Tasks: 163872 total, 106906 running, 19503 sleeping, 0 stopped, 37463 zombie
%Cpu0 : 0.2 us, 59.4 sy, 0.0 ni, 40.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu1 : 0.0 us, 30.5 sy, 0.0 ni, 69.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu2 : 12.3 us, 26.4 sy, 0.0 ni, 60.9 id, 0.0 wa, 0.0 hi, 0.4 si, 0.0 st
%Cpu3 : 0.6 us, 4.2 sy, 0.0 ni, 95.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu4 : 0.0 us,100.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu5 : 0.4 us, 1.9 sy, 0.0 ni, 97.5 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st
MiB Mem : 31962.2 total, 13418.8 free, 17632.6 used, 910.8 buff/cache
MiB Swap: 2048.0 total, 2048.0 free, 0.0 used. 13861.3 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 167628 11476 8356 S 99.6 0.0 4:08.50 systemd
285365 doug 20 0 241772 231688 3256 R 36.1 0.7 1:28.26 top
все будет разобраться, если я оставлю это достаточно долго.
Программа, используемая в данном документе, является моей, но запущена / развивалась из книги «Linux Programing на примере» в декабре 1999 года.