clone () / fork () / процесс создания медленно на некоторых машинах

Question

Создание новых процессов очень медленно на некоторых моих машинах, а не на других.

Все машины похожи, и некоторые медленные машины работают с теми же рабочими нагрузками на том же оборудовании и ядре (2.6.32-26, Ubuntu 10.04), что и некоторые быстрые машины. Задачи, не связанные с созданием процессов, имеют одинаковую скорость на всех машинах.

Например, эта программа выполняется на ~ 50 раз медленнее на зараженных машинах:

int main()
{
    int i;
    for (i=0;i<10000;i++)
    {
        int p = fork();
        if (!p) exit(0);
        waitpid(p);
    }
    return 0;
}

Что может быть причиной замедления процесса создания задачи и какие еще различия я могу искать в машинах?

Edit1: Запуск сценариев bash (так как они порождают много подпроцессов) также очень медленный на этих машинах, и strace на медленных сценариях показывает замедление при вызове ядра clone().

Edit2: vmstat не показывает каких-либо существенных различий на быстрых и медленных машинах. Все они имеют более чем достаточно оперативной памяти для своих рабочих нагрузок и не идут на обмен.

Edit3: я не вижу ничего подозрительного в dmesg

Edit4: я не уверен, почему это сейчас на stackoverflow, я не спрашиваю о приведенном выше примере программы (просто использую ее для демонстрации проблемы), а об администрировании / настройке linux, но если люди думают, что это здесь , круто.

Answer 1

Мы столкнулись с той же проблемой с нашим стеком приложений, отметив значительное снижение производительности приложений и более длительное время клонирования с помощью strace.Используя вашу тестовую программу на 18 узлах, я воспроизвел ваши результаты на тех же трех участках, с которыми у нас было медленное время клонирования.Все узлы были подготовлены одинаково, но с немного другим оборудованием.Мы проверили BIOS, vmstat, vm.overcommit_memory и заменили оперативную память без каких-либо улучшений.Затем мы переместили наши диски на обновленное оборудование, и проблема была решена.

CentOS 5.9 2.6.18-348.1.1.el5 # 1 SMP вт 22 января 16:19:19 EST 2013 x86_64 x86_64 x86_64 GNU / Linux

"плохие" и "хорошие" lspci:

$ diff ../bad_lspci_sort ../good_lspci_sort 
< Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 05)
> Ethernet controller: Intel Corporation 82574L Gigabit Network Connection

< Host bridge: Intel Corporation Xeon E3-1200 Processor Family DRAM Controller (rev 09)
> Host bridge: Intel Corporation Xeon E3-1200 v2/Ivy Bridge DRAM Controller (rev 09)

< ISA bridge: Intel Corporation C204 Chipset Family LPC Controller (rev 05)
> ISA bridge: Intel Corporation C202 Chipset Family LPC Controller (rev 05)

< PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 6 (rev b5)
> PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 7 (rev b5)

< VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200e [Pilot] ServerEngines (SEP1) (rev 04)
> VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200eW WPCM450 (rev 0a)

Answer 2

Я мог бы начать с использования strace, чтобы увидеть, какие системные вызовы выполняются и где висят медленные.Мне также любопытно, как вы используете здесь waitpid ().В моих системах подпись для waitpid

pid_t waitpid(pid_t pid, int *status, int options);

Похоже, вы используете wait (), но передаете pid дочернего процесса вместо int-status, который имеетИЛИ флагов состояния, которые вы хотите проверить.Я мог бы ожидать, что это может привести к некоторым странным вещам, если PID будет интерпретироваться как маска состояния.

Answer 3

Вы проверили конфигурацию BIOS, если у вас отключены кэши ЦП, или конфигурация питания испорчена, или некоторые системы перегреваются, или часть памяти разогнана ...

Answer 4

Значения /sbin/sysctl vm.overcommit_memory одинаковы для всех систем? Если нет, то это могло бы объяснить разницу.

Разрешение чрезмерной передачи сделает fork() намного быстрее, но это означает, что вновь выделенные страницы не будут поддерживаться оперативной памятью или подкачкой. Если / когда вы дотрагиваетесь до неотмеченной страницы, ОС должна найти для нее поддержку, а если не сможет, процесс будет убит. Это не проблема, если все, что делает ребенок, это exec(), как это происходит в вызове system(), так как все эти непрочитанные страницы отбрасываются; однако это может привести к серьезным проблемам для других пользователей fork().

Answer 5

Различия: ядро ​​(параметры, драйверы устройств, активные модули) и аппаратное обеспечение (версия процессора, число процессоров, конфигурация памяти, периферийные устройства).

Также: после изменения поведения компьютеровцикл перезагрузки / питания?

РЕДАКТИРОВАТЬ:

Низкая производительность, вероятно, связана с (виртуальной) иерархией памяти.Эта иерархия очень сложна, и эта сложность может привести к странным эффектам.Где-то на пути от TLB к кешам данных в основную память могут возникнуть странные конфликты.Это может быть вызвано немного другой структурой памяти ядер разных машин, или потому что иерархия памяти (аппаратная) на самом деле немного отличается.

Конечно, могут быть и другие причины, странное периферийное устройство (генерирующеепрерывания), другая рабочая нагрузка (например, количество активных процессов), ...

Если вы можете решить эту проблему, пожалуйста, поделитесь результатами!Спасибо.