Есть ли какое-либо влияние жатвы процессов-зомби?

Сколько разделов

Я верю другому, быстрее и лучшие люди уже ответили на это отлично.:)

Всегда существует еще один предел

Для следующего обсуждения всегда помните, что пределы являются теоретическими. Фактические ограничения часто являются меньше, чем теоретические пределы потому что также

  • другие теоретические пределы ограничивают вещи. (ПК очень, очень сложные вещи действительно в эти дни),
  • всегда существует больше ошибок. (этот ответ, не исключенный)

Когда Пределы Нарушены

То, что происходит, когда эти пределы нарушены, не просто, также. Например, назад в эпоху дисков на 10 ГБ, у Вас могли быть разделы мультигигабайта, но некоторые машины не могли загрузочный код, сохраненный после 1,024-го цилиндра. Поэтому столько установщиков Linux все еще настаивает на отдельном, маленьком / разделе начальной загрузки в начале диска. После того как Вам удалось загрузиться, вещи были очень хорошо.

Размер разделов: Таблица разделов MS-DOS (MBR)

MS-DOS хранит разделы в (запустите, размер), формат, каждый из которых 32 бита шириной. Каждое число раньше кодировало координаты сектора головки цилиндра в былые дни. Теперь это просто включает произвольный номер сектора (диск справляется с переводом от этого до определенных для носителя координат). Источник ядра для типа раздела 'MS-DOS' предполагает, что размеры раздела 32 бита шириной в секторах. Который дает нам 2^32 * 512, или 2^41 байты, или 2^21 двоичные Мегабайты, или 2 097 152 мегабайта, или 2 048 гигабайтов или 2 терабайта (минус один сектор).

Таблица разделов GUID (GPT)

При использовании дисковой маркировки Таблицы разделов GUID (GPT) таблица разделов хранится как (запустите, конец), пара. Оба 8 байтов длиной (64 бита), который допускает еще много, чем Вы, вероятно, будете когда-либо использовать: 2^64 512-байтовые секторы, или 2^73 байты (8 двоичных зеттабайт), или 2^33 терабайты.

Если Вы загружаетесь прочь ROM UEFI, а не традиционного BIOS CP/M-era, Вы уже получили GPT. Если не можно всегда принимать решение использовать GPT в качестве disklabel. Если у Вас есть довольно новый диск, Вы действительно должны.

Размеры сектора

Сектор составил 512 байтов долгое время. Это установлено измениться на 4 096 байтов. Много дисков уже имеют это, но эмулируют 512-байтовые секторы. Когда изменения происходят в переднем плане, и единица выделения становится 4 096-байтовыми секторами, и LBAs обращаются к 4 096-байтовым секторам, все размеры выше изменятся на 3 двоичных порядка величины: умножьте их всех на 8 для получения новых, страшных значений.

Диспетчер логических томов

При использовании LVM независимо от того, что объем, который Вы делаете, должен также поддерживаться LVM, так как он находится между Вашими разделами и файловыми системами. Согласно LVM2 FAQ, LVM2 поддерживает до 8EB (эксабайты) на Linux 2.6 на 64-разрядной архитектуре; 16 ТБ (терабайты) на Linux 2.6, работающем на 32-разрядной архитектуре; и 1 ТБ на Linux 2.4.

Пределы файловой системы

Конечно, это пределы размера на раздел (или объем LVM), который является тем, что Вы спрашиваете. Но точка наличия разделов должна обычно хранить файловые системы, и файловые системы имеют свои собственные пределы. На самом деле, что типы пределов, которые имеет файловая система, зависят от самой файловой системы! Единственные глобальные пределы являются максимальным размером файловой системы и максимальным размером каждого файла в нем.

EXT4 позволяет разделам до 16 ТБ за файл и 1EB (эксабайт) на объем. Однако это использует 32-разрядные номера блока, таким образом, необходимо было бы увеличить 4 096-байтовый размер блока по умолчанию. Это не может быть возможно на Вашем ядре и архитектуре, таким образом, 16 ТБ за объем могут быть более реалистичными на ПК.

ZFS позволяет 16EB файлы и 16EB объемы, но несомненно он имеет его собственный другой, непредвиденные пределы также.

Википедия имеет очень хорошую таблицу этих пределов для большинства файловых систем, известных человеку.

На практике

При использовании Linux 2.6 или более новые на 64-разрядных машинах и разделах GPT похоже, что необходимо только волноваться о выборе файловой системы и ее пределов. Даже затем это действительно не должно волновать Вас так очень. Вы, вероятно, не должны создавать единственные файлы 16 ТБ так или иначе, и 1 эксабайт (1 048 576 ТБ) будет сюрреалистическим ограничением некоторое время. Если Вы используете MBR и нуждаетесь больше чем в 2 двоичных терабайтах, необходимо переключиться на UEFI и GPT, потому что Вы действуете под пределом 2TB на раздел (это может быть менее, чем тривиально на уже развернутом компьютере),

Обратите внимание на то, что я - старпер, и я использую двоичные единицы, когда я вычисляю кратные числа полномочий два. Изготовителям дисков нравится обманывать (и убедили нас, что они всегда делали это, даже при том, что мы знаем, что они не сделали) при помощи десятичных единиц. Таким образом, самый большой диск 'на 2 ТБ' еще меньше, чем 2 двоичных терабайта, и Вы не испытаете затруднения. Если Вы не используете LVM или RAID 0.

2
21.12.2013, 00:51
2 ответа

При жатве зомби перед его родителем Вы теряете любой эффект, который жатва имела бы в родителе. Это является очевидно зависящим от приложения.

Существует очень мало причины активно пойти и пожинать зомби. Некоторые операционные системы не позволяют Вам сделать это, за исключением вручную ptracing родительский процесс и то, чтобы заставлять это выполнить a waitpid системный вызов. Солярис предлагает a preap утилита, но единственный случай, когда необходимо использовать его, - когда программа неправильно себя ведет и заполняет таблицу процессов зомби.

4
27.01.2020, 21:53
  • 1
    кажется, что приложение неправильно себя ведет и процессы-зомби, является только вещью, о которой я подозрителен. –  mibzer 06.11.2012, 10:40
  • 2
    @mibzer буйвола Buffalo является, вероятно, признаком, не болезнью. Обычно, процессы-зомби оставлены позади, потому что процесс, который должен пожинать их, не делает то, что он должен делать (включая waitлуг для его детей). Жатва зомби не заставит его сделать то, что это должно делать. первое место –  Gilles 'SO- stop being evil' 06.11.2012, 11:19

Ваш сценарий мог бы пожинать зомби, слишком рано предотвращающие их родителей для жатвы их и затем вызывающий неожиданное поведение с ними.

Принятие Вас не имеет никакого способа зафиксировать первопричину этих процессов-зомби существование, я только пожинал бы тех, которые были в более не существующем состоянии в течение достаточно долгого промежутка времени (например, 1 минута), чтобы не обходить законную жатву:

for pid in $(ps -eo pid,s | nawk '$2 == "Z" {print $1 };sleep 60)
do
  preap $pid
done

Между прочим, | xargs бесполезно в Вашем сценарии, поскольку новая строка является допустимым разделителем аргумента.

3
27.01.2020, 21:53
  • 1
    Что является “слишком ранним”? Каковы оборотные стороны жатвы их слишком скоро? Как определять “достаточно долго”? –  Marco 05.11.2012, 14:20
  • 2
    Это - проблема синхронизации. Если Вы, оказывается, запускаете свой скрипт сразу после того, как процесс умирает, необходимо позволить его родительскому процессу шанс пожинать его и правильно получить его статус возврата. –  jlliagre 05.11.2012, 14:23
  • 3
    Вы никогда не знали бы, сколько времени ожидать. Лучше, чтобы позволить родителю сделать свое задание и зафиксировать его, если он не. –  Jim Paris 05.11.2012, 19:58
  • 4
    @Jim: Я соглашаюсь, что первопричина должна быть зафиксирована, если возможный, но я принимаю, вопрос означает, что это не возможно по некоторым причинам. В любом случае, если родитель не пожинал более не существующего ребенка после того, как говорят одну минуту, существует очень мало шанса, он будет когда-либо делать это. –  jlliagre 06.11.2012, 09:04
  • 5
    , если у Вас есть процессы-зомби, кто родительский pid, '1' (init), те, которых можно пожинать. Если процесс-зомби все еще сообщает, что это - фактический родитель, как это - PPID, переждите его. –  Tim Kennedy 13.11.2012, 07:02

Теги

Похожие вопросы