Що станеться, якщо я розпочну занадто багато фонових завдань?

Мені потрібно виконати деяку роботу на 700 мережевих пристроях, використовуючи сценарій очікування. Я можу це зробити послідовно, але поки тривалість виконання становить близько 24 годин. В основному це пов’язано з часом, необхідним для встановлення з'єднання, та затримкою виводу з цих пристроїв (старих). Я можу встановити два з'єднання, і вони можуть паралельно працювати паралельно, але як далеко я можу це зробити?

Я не уявляю, що я могла б виконати всі 700 з них одночасно, напевно, є якась межа обмеження "ні". з підключеннями telnet, яким мій VM може керувати.

Якби я спробував запустити 700 з них у такому циклі, як цей:

for node in `ls ~/sagLogs/`; do  
    foo &  
done

З

• CPU 12 CPU x Intel (R) Xeon (R) CPU E5649 @ 2,53 ГГц

• Пам'ять 47,94 ГБ

Моє запитання:

1. Чи можуть всі 700 екземплярів працювати одночасно?
2. Як далеко я можу дістатись, поки мій сервер не досягне межі?
3. Коли ця межа буде досягнута, це буде просто чекати, коли розпочнеться наступна ітерація, fooабо поле вийде з ладу?

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

Чи можуть всі 700 екземплярів працювати одночасно?

Це залежить від того, що ви маєте на увазі одночасно. Якщо ми вибагливі, то ні, вони не можуть, якщо у вас не буде 700 потоків виконання у вашій системі, які ви можете використовувати (так, мабуть, ні). Однак реально, так, вони, ймовірно, можуть, за умови, що у вас достатньо оперативної пам’яті та / або поміняти місцями в системі. UNIX та різні діти надзвичайно добре керують величезними рівнями одночасності, ось чому вони так популярні для широкомасштабного використання HPC.

Як далеко я можу дістатись, поки мій сервер не досягне межі?

На це неможливо відповісти конкретно без набору більшої кількості інформації. Досить багато, вам потрібно мати достатньо пам’яті, щоб зустрітися:

• Цілі вимоги до пам’яті під час виконання одного завдання, разів 700.
• Вимоги пам'яті bash для управління багатьма робочими завданнями (bash не жахливо з цього приводу, але управління роботою не є точно ефективною пам'яттю).
• Будь-які інші вимоги до пам'яті в системі.

Якщо припустити, що ви зустрінетесь (знову ж таки, маючи лише 50 Гб оперативної пам’яті, ви все ще вирішуєте інші проблеми:

• Скільки часу процесор буде витрачений на втрату контролю за роботою? Напевно, не багато, але при сотнях робочих місць це може бути значним.
• Скільки для цього потрібно буде пропускна здатність мережі? Просто відкриття всіх цих з'єднань може заграти вашу мережу на пару хвилин, залежно від вашої пропускної здатності та затримки.
• Багато інших речей, які я, певно, не думав.

Коли ця межа буде досягнута, буде лиш чекати, коли розпочнеться наступна ітерація з футу, або вікно зрушиться?

Це залежить від того, яка межа потрапила. Якщо це пам'ять, у системі щось загине (точніше, ядро ​​вбивається в спробі звільнити пам'ять) або сама система може вийти з ладу (незвично конфігурувати системи, щоб навмисно виходити з ладу під час вичерпання пам'яті). Якщо настав час процесора, він буде просто продовжувати без проблем, багато іншого в системі буде неможливо. Якщо це мережа, ви можете зламати інші системи чи служби.

Що вам тут справді потрібно, це не запускати всі завдання одночасно. Натомість розділіть їх на партії та виконайте всі завдання в партії одночасно, нехай вони закінчуються, а потім розпочніть наступну партію. GNU Parallel ( https://www.gnu.org/software/parallel/ ) може бути використаний для цього, але він менш ідеальний в такому масштабі у виробничому середовищі (якщо ви йдете з ним, не будьте занадто агресивними, як я вже говорив, ви можете заграти в мережу і вплинути на системи, яких інакше ви не торкалися б) Я б дуже рекомендував заглянути відповідний інструмент для оркестрування мережі, як Ansible ( https://www.ansible.com/), оскільки це не тільки вирішить ваші проблеми з одночасністю (Ansible робить пакетне, як я вже згадував вище), але і надасть вам безліч інших корисних функцій, з якими можна працювати (наприклад, безвідмовне виконання завдань, приємні звіти про стан та натурна інтеграція з дуже велика кількість інших інструментів).

Важко сказати конкретно, скільки екземплярів може бути запущено як фонові завдання в описаному вами порядку. Але звичайний сервер, безумовно, може підтримувати 700 одночасних з'єднань, якщо ви це зробите правильно. Веб-сервери роблять це постійно.

Я можу запропонувати вам використовувати паралель GNU ( 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 підкаже, чи вдасться виконати роботу (після можливо повторних спроб) чи ні.

Що станеться, якщо я розпочну занадто багато фонових завдань?

система стане повільною та безвідповідальною, гірший випадок настільки невідповідний, що було б найкраще просто натиснути кнопку живлення та зробити важку перезавантаження ... це було б запускати щось на кшталт кореня, де вона мала честь піти з цього. Якщо ваш Баш скрипт працює в звичайних привілеї користувача, то перше , що спадає на думку, /etc/security/limits.confі /etc/systemd/system.confта все змінні в ньому [ідеалі кажучи] запобігти користувач (їй) від перевантаження системи.

• CPU = xeon E5649, тобто 12- ядерний процесор; Таким чином, у вас є 12 ядер для 12 процесів, які можна одночасно запускати, використовуючи один із дванадцяти ядер на 100%. Якщо ви запустили 24 процеси, кожен з них буде працювати з 50% -ним використанням кожного з дванадцяти ядер, 700 процесів = 1,7%, але це комп'ютер, якщо все закінчиться належним чином за нормальний час, то це = успіх; ефективність не завжди є актуальною.

  1. Чи можуть всі 700 екземплярів працювати одночасно? Безумовно, 700 - це не велика кількість; Наприклад, мій /etc/security/limits.conf maxproc- 4,135,275

  2. Як далеко я можу дістатись, поки мій сервер не досягне межі? Набагато далі, ніж 700, я впевнений.

  3. Обмеження ... що станеться, якщо скрипт буде запущено під обліковим записом користувача [і, як правило, root, як правило, limits.confстосується всіх], - це те, що сценарій просто вийде після спроби зробити це foo &700 разів; Ви очікуєте, що тоді ви побачите 700 процесів foo, кожен з яких має інший pid, але ви можете побачити лише 456 (вибір випадкових чисел), а інші 244 так і не почалися, оскільки їх заблокували певні обмеження безпеки або системного обмеження.

Питання на мільйон доларів: скільки потрібно виконувати одночасно?

займаючись мережею, і ви сказали, що кожен зробить з'єднання telnet, в курсі, що ви наткнетесь на обмеження мережі та накладні витрати, перш ніж робити обмеження для процесора та оперативної пам'яті. Але я не знаю, що ви робите конкретно, що, швидше за все, трапиться, - ви можете зняти всі 700 одразу, але все автоматично блокується, поки попередні процеси та мережеві з'єднання не закінчаться та закриються на основі різних системних обмежень або чогось подібного перші 500 починаються, а решта 200 не буде, тому що обмеження системи чи ядра перешкоджають цьому. Але хоч скільки біжить одразу, буде солодкемісце, щоб зробити все якомога швидше ... мінімізуючи накладні витрати та підвищуючи ефективність. Отримавши 12 ядер (або 24, якщо у вас є 2 процесора), то починайте відразу з 12 (або 24), а потім збільште цей номер одночасного пакету на 12 або 24, поки ви не побачите покращення часу виконання.

підказка: підключення google max telnet і подивіться, як це стосується ваших систем. Також не забувайте про брандмауери. Також швидко зробіть обчислення необхідної пам'яті за процес x 700; переконайтеся, що <доступна оперативна пам’ять (близько 50 Гбіт у вашому випадку) в іншому випадку система почне використовувати SWAP і в основному не відповідатиме. Тож натискання 12, 24, N процесів одночасно та моніторинг оперативної пам'яті безкоштовно, а потім збільшуйте N, вже маючи певні знання про те, що відбувається.

За замовчуванням RHEL обмежує кількість підключень telnet від одного хоста до 10 одночасних сеансів. Це функція захисту ... встановлена ​​на 10, /etc/xinetd.conf, змініть значення "per_source".