nohup не размещает каждый процесс на одном ядре конкретно
Для дистрибутивов, которые следуют LSB, они назначают UID и GID 0-99 статически. UID 100-499 назначаются динамически, но они также предназначены для системы, а не для учетных записей входа.
Например, демоны печати, такие как cups, имеют собственную учетную запись пользователя. Таким образом, если уязвимость в демоне эксплуатируется, демон не работает как root с полной властью над системой. (При этом он не обязательно имеет право вмешиваться в работу других демонов).
В более поздних дистрибутивах Linux системный диапазон расширен до 999.
Это оставило бы UID от 500 и выше (или от 1000) для учетных записей входа.
Debian дополнительно имеет статическое распределение для UIDGID 100, хотя я не могу себе представить, чтобы это отклонение вызывало какую-либо конкретную проблему.
Легко представить себе другую систему с отклонением на единицу, которая дополнительно резервирует UID 500. долго, без обновления).
Первая учетная запись для входа не обязательно должна быть учетной записью администратора или основной учетной записью администратора. Системы не обязательно используют sudo (особенно если они предшествуют этому :).В этом случае вы можете сказать, что «основная учетная запись администратора» — root. Кроме этого, дистрибутивы *nix и Linux общего назначения не распознают конкретную «основную учетную запись администратора».
nohup ничего не настраивает для сохранения процесса на определенном ядре. Для этого обычно используется набор задач вместе с nohup . top может показать, на каком ядре процесс был последний раз запланирован, это столбец P .
Планирование процессов и потоков с годами стало довольно сложным, потому что необходимо учитывать все больше и больше факторов: сродство ЦП, сродство кеша, обработка прерываний, диапазоны мощности ... Но я бы не ожидал каких-либо проблем, если вы начинаете меньше заданий, чем у вас есть доступные ядра, при условии, что система не слишком занята другими задачами. Точно так же вы не можете точно предсказать, на каком процессоре будет выполняться задача, но если это уместно, планировщик, скорее всего, оставит ее на том же ядре после того, как выберет ядро.
Во-первых, я ошибался, полагая, что nohup и / или фоновая обработка - это процесс, который работает на определенном ядре, отображаться в терминале? Top сообщает вам только, какие ядра заняты, а не какую задачу они выполняют, насколько мне известно?) достаточно, чтобы привязать процесс к определенному { {1}} ядро? (И может ли
Nohup запускать команду точно так же, как если бы они были запущены без них, с той лишь разницей, что они удаляются из списка pid-идентификаторов для отправки сигнала при выходе. (Disown работает для процесса, не запущенного с помощью nohup).
] Во-вторых, произойдет ли перегрузка ЦП, даже если есть 2 запасных ЦП , доступных для обработки других задач системы?
Только если перегрузка ЦП происходит без nohup ...
Наконец, если бы я не был неправильно, привязан ли данный процесс к определенному процессору и только к этому процессору, или они будут переключаться между потоками в зависимости от порядка вызовов / времени и т. д., например, если я зацикливался на {{ 1}}, будет ли первый закреплен на ЦП 0, затем 1, 2 и так далее до завершения?
так же, как и без nohup ...
вы можете просмотреть, какое ядро процессора используется процесс выполняется с помощью ps, и вы можете ограничить или изменить ограничения для ядер с помощью набора задач.
ps -eo pid,sgi_p,cmd --sort sgi_p
taskset -c -p 0 1234