1

Мы наблюдаем некоторое медленное простое время выполнения команд в Linux, возможно, связанное с медлительностью procfs.

Как и простая команда uptime может занять несколько секунд.

Вот входы:

  • Платформа: AWS
  • Экземпляр: x1.32xl (128 ядер с 2T RAM)
  • ОС: Ubuntu 16.04
  • Ядро: 4.4.0-1043-aws

Мы запускаем докер с около 250 контейнеров.

  • Версия докера: 17.09-ce

Использование:

  • Загрузка ЦП: <50%
  • Использование памяти: <50%

Некоторые характеристики ОС:

# cat /proc/loadavg
100.45 108.30 109.41 35/254951 544357

# vmstat 1 3
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
110  2 791584 485552640 50354496 687472448    0    0   426   183    1    1 10  8 82  1  0
13  0 791584 485495104 50353940 687477568    0    0 22820 47984 196555 326943 12 12 75  1  0
33  1 791584 485385632 50352428 687473536    0    0 38932 52892 166486 389428 13 14 72  1  0

# ps axu| wc -l
3792

Что именно происходит?

Запуск простых команд требует времени, когда команды каким-либо образом используют procfs. Подобно тому, как выполнение ls в директории с несколькими файлами застревает на открытом системном вызове procfs

# strace -r ls
...
0.000084 open("/proc/filesystems", O_RDONLY) = 3
3.652504 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
...

Или uptime:

# strace -r uptime
...
0.000035 open("/proc/filesystems", O_RDONLY) = 3
11.014154 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
...
0.000044 open("/proc/uptime", O_RDONLY) = 3
1.554646 lseek(3, 0, SEEK_SET)
...

Быстрый Q/A и то, что мы уже попробовали:

  • Эта медлительность присутствует только на уровне хоста. В контейнерах мы не видим таких проблем. Мы играли вокруг немного , и посмотреть этот вопрос , когда мы запускаем контейнер с обоими --ipc=host и --pid=host флагов.
  • Мы проследили эту медлительность в procfs до mutex_lock здесь https://github.com/torvalds/linux/blob/v4.4/fs/namei.c#L3082
  • Слишком много контейнеров
    • Нет у нас 600 на другом хосте и все хорошо
  • Слишком много процессов
    • Нет, у нас 10к на другом хосте и все хорошо
  • Слишком много тем
    • Это может быть. У нас нет такого количества потоков на любом другом хосте, но мы попытались воспроизвести его на чистом экземпляре x1.32xlarge и потерпели неудачу. Так что это может быть еще один шаг

Любые идеи и предложения приветствуются.

|источник

0