Что произойдет, если я начну слишком много фоновых заданий?
На самом деле, похоже, нет никакого стандартного способа сделать.
Существует наиболее очевидное решение: из сетевого пространства имен запустите ssh сервер, затем подключитесь к нему с любого удаленного компьютера с помощью обычных параметров,
ssh -Y me@network.namespace.IP.address
после этого можно будет запустить любую графическую программу. на сервере X11 удаленной машины. Также работают всевозможные вариации на одну и ту же тему, например vnc .
В качестве альтернативы можно использовать обычные инструменты: iptables , netcat , socat . Вот один из способов сделать это с помощью socat : фокус в том, что, хотя места localhost на сервере и в его новом сетевом пространстве имен были разделены, их сокеты X11 unix не имеют. Фактически, из сетевого пространства имен вы можете сразу открывать графические приложения, которые будут отображаться на X-сервере его родительской машины.Таким образом, заставляя сетевое пространство имен записывать в новый сокет unix на его родительской машине, мы можем перенаправить данные, отправленные в новый сокет, на клиентский X-сервер с помощью обычной пересылки ssh X11 на серверная машина, даже без подключения нового сетевого пространства имен, что дает более простое решение.
Это делается следующим образом: в новом сетевом пространстве имен,
export DISPLAY=:1
Это будет записывать в новый сокет Unix, /tmp/.X11-unix/X1 , который еще ни к чему не подключен . В удаленном клиенте используйте команду
socat exec:'ssh me@remoteserver socat unix-l\:/tmp/.X11-unix/X1 -' unix:/tmp/.X11-unix/X0
(обратите внимание на экранирование : ). Приведенная выше команда отправляет входные данные сокета unix /: 1 на сервере в сокет unix /: 0 на клиенте. Возможно, вам придется ослабить локальные (= на клиенте) элементы управления xhost и проверить право собственности на unix /: 1 (= : 1 = / tmp /.X11-unix/X1) сокет. Это значительно проще, чем предыдущий метод: не нужно ни настраивать ssh-сервер в новом сетевом пространстве имен, ни даже получать IP-адрес. Он также обходит все проблемы авторизации X11, такие как использование xhost для разрешения некоторых удаленных пользователей или использование волшебных файлов cookie MIT с socat (я даже не уверен, что это можно сделать).
Есть и другие способы сделать это (например, подавив параметр -nolisten tcp на клиентском X-сервере, а затем с помощью socat перенаправить сокет unix : 1 в клиентский порт TCP6000, например), но, даже если не учитывать то, что они вызывают серьезные проблемы с безопасностью, они не являются стандартными ни при каких обстоятельствах.
Could all 700 instances possibly run concurrently?
Это зависит от того, что вы подразумеваете под одновременно. Если мы придирчивы, то нет, они не могут, если у вас нет 700 потоков выполнения в вашей системе, вы можете использовать (так что, вероятно, не ). На самом деле, да, они, вероятно, могут, если у вас достаточно оперативной памяти и/или места подкачки в системе. UNIX и его различные дочерние системы замечательно справляются с управлением огромными уровнями параллелизма, и это одна из причин, почему они так популярны для крупномасштабного -использования высокопроизводительных вычислений.
How far could I get until my server reaches its limit?
На этот вопрос невозможно ответить конкретно без дополнительной информации. В значительной степени вам нужно иметь достаточно памяти, чтобы соответствовать:
- Время выполнения -требования к памяти для одного задания, умноженное на 700.
- Требования bash к памяти для управления таким количеством заданий (bash не так ужасен в этом, но управление заданиями не совсем эффективно с точки зрения использования памяти ).
- Любые другие требования к памяти в системе.
Если вы снова столкнетесь с этим (, имея только 50 ГБ ОЗУ, вам все равно придется решать другие проблемы.:
- Сколько процессорного времени тратит bash на управление заданиями? Вероятно, немного, но с сотнями рабочих мест это может быть значительным.
- Какая для этого потребуется пропускная способность сети? Простое открытие всех этих подключений может привести к перегрузке вашей сети на пару минут в зависимости от пропускной способности и задержки.
- Много других вещей, о которых я, вероятно, не подумал.
When that limit is reached, will it just wait to begin the next iteration off foo or will the box crash?
Это зависит от того, какой предел достигнут. Если это память, то в системе что-то умрет (, точнее говоря, будет убито ядром при попытке освободить память )или может произойти сбой самой системы (заканчивается память ). Если это время ЦП, оно будет продолжать работать без проблем, просто будет невозможно сделать что-то еще в системе. Однако, если это сеть, вы можете привести к сбою других систем или служб.
Что вам действительно здесь нужно, так это не запускать все задания одновременно. Вместо этого разделите их на пакеты и запустите все задания в пакете одновременно, дайте им завершиться, а затем запустите следующий пакет. Для этого можно использовать GNU Parallel (https://www.gnu.org/software/parallel/), но он далеко не идеален при таком масштабе в производственной среде (. системы, к которым в противном случае вы бы не прикоснулись ). Я действительно рекомендую поискать подходящий инструмент для организации сети, такой как Ansible (https://www.ansible.com/), так как он не только решит ваши проблемы с параллелизмом (Ansible выполняет пакетную обработку, как я упоминал выше, автоматически ), но также даст вам много других полезных функции для работы с (, такие как идемпотентное выполнение задач, удобные отчеты о состоянии,и встроенная интеграция с очень большим количеством других инструментов ).
Трудно сказать конкретно, сколько экземпляров может быть запущено в качестве фоновых заданий описанным вами способом. Но обычный сервер, безусловно, может поддерживать 700 одновременных подключений, если вы делаете это правильно. Веб-серверы делают это постоянно.
Могу ли я предложить вам использовать GNU parallel(https://www.gnu.org/software/parallel/)или что-то подобное для достижения этой цели? Это дало бы вам ряд преимуществ по сравнению с подходом к работе в фоновом режиме :
.- Вы можете легко изменить количество одновременных сеансов.
- И он будет ждать завершения сеансов, прежде чем начинать новые.
- Легче прервать.
Посмотрите здесь для быстрого начала:https://www.gnu.org/software/parallel/parallel_tutorial.html#A-single-input-source
Использование &для параллельной обработки допустимо при выполнении нескольких операций и при отслеживании хода выполнения. Но если вы работаете в корпоративной производственной среде, вам нужно что-то, что даст вам лучший контроль.
ls ~/sagLogs/ | parallel --delay 0.5 --memfree 1G -j0 --joblog my.log --retries 10 foo {}
Это запустит fooдля каждого файла в ~/sagLogs. Он запускает задание каждые 0,5 секунды, он будет запускать максимально возможное количество заданий параллельно, пока 1 ГБ ОЗУ свободен, но будет соблюдать ограничения вашей системы (, например. количество файлов и процессов ). Обычно это означает, что вы будете запускать 250 заданий параллельно, если не настроили разрешенное количество открытых файлов. Если вы отрегулируете количество открытых файлов, у вас не должно возникнуть проблем с параллельным запуском 32000 -, если у вас достаточно памяти.
Если задание завершается ошибкой (, т. е. возвращается с кодом ошибки ), оно будет повторено 10 раз.
my.logсообщит вам, успешно ли выполнено задание (после возможных повторных попыток )или нет.
What happens if I start too many background jobs?
Система станет медленной и перестанет отвечать на запросы, в худшем случае она будет настолько невосприимчивой, что лучше всего будет просто нажать кнопку питания и выполнить жесткую перезагрузку... это будет запуск чего-то от имени пользователя root, где у него есть привилегия избежать наказания делая это. Если ваш скрипт bash выполняется с правами обычного пользователя, то первое, что приходит на ум, это /etc/security/limits.confи /etc/systemd/system.confи все переменные в них, чтобы [в идеале] предотвратить пользователя (s )из перегрузка системы.
процессор = xeon E5649, то есть 12-ядер процессор; таким образом, у вас есть 12 ядер для одновременной работы 12 процессов, каждый из которых использует одно из двенадцати ядер на 100%. Если вы запустите 24 процесса, то каждый из них будет работать с 50% использованием каждого из двенадцати ядер, 700 процессов = 1,7%, но это компьютер, если все завершается правильно за приемлемое время, тогда это = успех; эффективность не всегда актуальна.
Могут ли все 700 экземпляров работать одновременно? Конечно,700 — это небольшое число; мой файл /etc/security/limits.conf
maxprocпо умолчанию равен 4 135 275, напримерКак далеко я могу зайти, пока мой сервер не достигнет своего предела? Я уверен, что гораздо дальше 700.
Ограничения ... что произойдет, если скрипт будет запущен под учетной записью пользователя [и, как правило, root
limits.confв значительной степени относится ко всем] заключается в том, что скрипт просто выйти после попытки выполнитьfoo &700 раз; вы ожидаете увидеть 700 foo процессов, каждый из которых имеет свой pid, но вы можете увидеть только 456 (случайный выбор числа ), а остальные 244 никогда не запускались, потому что они были заблокированы какой-то системой безопасности или systemd предел.
Вопрос на миллион долларов :Сколько нужно запускать одновременно?
будучи вовлеченным в сеть , и вы сказали, что каждый из них будет устанавливать соединение telnet, обоснованное предположение состоит в том, что вы столкнетесь с ограничениями сети и накладными расходами, прежде чем вы сделаете это для ограничений процессора и оперативной памяти. Но я не знаю, что вы делаете конкретно, что, вероятно, произойдет, если вы можете запустить все 700 одновременно, но все будет автоматически блокироваться до тех пор, пока предыдущие процессы и сетевые подключения не завершатся и не закроются в зависимости от различных системных ограничений или что-то вроде первые 500 запустятся, а остальные 200 — нет, потому что этому препятствуют ограничения системы или ядра. Но как бы много ни выполнялось одновременно, всегда будет сладкое место, чтобы сделать все как можно быстрее... минимизируя накладные расходы и повышая эффективность. Если у вас 12 ядер (или 24, если у вас 2 процессора ), начните с 12 (или 24 )одновременно, а затем увеличьте количество одновременных пакетов на 12 или 24, пока вы не увидите улучшение времени выполнения..
подсказка:погуглите максимальное количество соединений telnet и посмотрите, как это применимо к вашей системе (s ). Также не забывайте о брандмауэрах. Также сделайте быстрый расчет памяти, необходимой для каждого процесса x 700;убедитесь, что < доступно ОЗУ (около 50 ГБ в вашем случае ), иначе система начнет использовать SWAP и в основном перестанет отвечать. Так что пинайте 12, 24, N процессов за раз и следите за свободной ОЗУ, затем увеличивайте N уже имея некоторое представление о том, что происходит.
By default, RHEL limits the number of telnet connections from a single host to 10 simultaneous sessions. This is a security feature... set to 10, /etc/xinetd.conf, change “per_source” value.