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

Недостатки текущего интерфейса

Прочитав заголовок, возникает вопрос:”A чем же старый интерфейс не угодил”? Многие из вас знают, что сейчас информация о процессах собирается по файловой системе procfs. Здесь каждому процессу соответствует директория, которая содержит несколько десятков файлов.

$ ls /proc/self/ 
attr             cwd      loginuid    numa_maps      schedstat  task
autogroup        environ  map_files   oom_adj        sessionid  timers
auxv             exe      maps        oom_score      setgroups  uid_map
cgroup           fd       mem         oom_score_adj  smaps      wchan
clear_refs       fdinfo   mountinfo   pagemap        stack
cmdline          gid_map  mounts      personality    stat
comm             io       mountstats  projid_map     statm
coredump_filter  latency  net         root           status
cpuset           limits   ns          sched          syscall

Каждый файл содержит некоторое количество атрибутов. Первая проблема заключается в том, что нам придется на каждый процесс прочитать минимум один файл, т.е. сделать три системных вызова. Если же нужно собрать данные о сотне тысяч процессов, это может занять продолжительное время даже на мощной машине. Некоторые наверняка могут вспомнить, что утилита ps или top работает медленно на загруженных машинах.

Вторая проблема связана с тем, как свойства процессов разбиты по файлам. У нас есть хороший пример, который показывает, что текущее разбиение не очень хорошее. В CRIU есть задача получить данные о всех регионах памяти процесса. Если мы посмотрим в файл /proc/PID/maps, то мы обнаружим, что он не содержит флагов, которые необходимы для востановление регионов памяти. К нашему счастью, есть еще один файл — /proc/PID/smaps, который содержит необходимую информацию, а так же статистику по затраченной физической памяти (которая нам не нужна). Простой эксперимент показывает, что формирование первого файла занимает на порядок меньше времени.

$ time cat /proc/*/maps > /dev/null
real	0m0.061s
user	0m0.002s
sys	0m0.059s

$ time cat /proc/*/smaps > /dev/null
real	0m0.253s
user	0m0.004s
sys	0m0.247s

Вероятно, вы уже догадались, что во всем виновата статистика потребления памяти — на ее сбор уходит большая часть времени.

Третью проблему можно увидеть в формате файлов. Во-первых, нет единого формата. Во-вторых, формат некоторых файлов принципиально нельзя расширить (именно по этой причине мы не можем добавить поле с флагами в /proc/PID/maps). В-третьих, многие файлы в текстовом формате, которые легко читаются человеком. Это удобно, когда вы хотите посмотреть на один процесс. Однако, когда стоит задача проанализировать тысячи процессов, то вы не будете просматривать их глазами, а напишете какой-то код. Разбирать файлы разных форматов — не самое приятное времяпрепровождение. Бинарный формат обычно удобнее для обработки в програмном коде, а его генерация зачастую требует меньше ресурсов.

Интерфейс получения информации о сокетах socket-diag

Когда мы начали делать CRIU, встала проблема с получением информации о сокетах. Для большинства типов сокетов, как обычно, использовались файлы в /proc (/proc/net/unix, /proc/net/netlink и т.д.), содержащие достаточно ограниченный набор параметров. Для INET сокетов существовал netlink интерфейс, который представлял информацию в бинарном виде и легко расширяемом формате. Этот интерфейс удалось обобщить на все типы сокетов.
Работает он следующим образом. Сначала формируется запрос, который задает набор групп параметров и набор сокетов, для которых они требуются. На выходе мы получаем требуемые данные, разбитые на сообщения. Одно сообщение описывает один сокет. Все параметры разбиты на группы, которые могут быть достаточно маленькими, так как несут накладные расходы только на размер сообщения. Каждая группа описывается типом и размером. При этом у нас есть возможность расширять существующие группы или добавлять новые.

Новый интерфейс получения атрибутов процессов task-diag

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

Все атрибуты нужно разбить на группы. Здесь есть одно важное правило — никакой из атрибутов не должен оказывать заметного влияния на время, требуемое для генерации всех атрибутов в группе. Помните, я рассказывал про /proc/PID/smaps? В новом интерфейсе мы вынесли эту статистику в отдельную группу.

На первом этапе мы не ставили задачу покрыть все атрибуты. Хотелось понять, насколько новый интерфейс удобен для использования. Поэтому мы решили сделать интерфейс, достаточный для нужд CRIU. В результате получился следующий набор групп атрибутов:

        TASK_DIAG_BASE          /* основная информация pid, tid, sig, pgid, comm */
        TASK_DIAG_CRED,         /* права доступа */
        TASK_DIAG_STAT,         /* то же, что предствляет taskstats интерфейс */
        TASK_DIAG_VMA,          /* описание регионов памяти */
        TASK_DIAG_VMA_STAT,     /* дополнить описание регионов памяти статистикой потребления ресурсов */
        TASK_DIAG_PID   = 64,   /* идентификатор нити */
        TASK_DIAG_TGID,         /* идентификатор процесса */

На самом деле здесь представлена текущая версия разбиения на группы. В частности, мы видим тут TASK_DIAG_STAT, который появился во второй версии в рамках интеграции интерфейса с уже существующим taskstats, построенным на базе netlink сокетов. Последний использует netlink протокол и имеет ряд известных проблем, которые мы еще затронем в этой статье.

И пара слов о том, как задается группа процессов, о которых нужна информация.

#define TASK_DIAG_DUMP_ALL      0               /* обо всех процессах в системе*/
#define TASK_DIAG_DUMP_ALL_THREAD       1       /* обо всех нитях в системе */
#define TASK_DIAG_DUMP_CHILDREN 2               /* о всех детях указанного процесса */
#define TASK_DIAG_DUMP_THREAD   3               /* о всех нитях указанного процесса */
#define TASK_DIAG_DUMP_ONE      4               /* об одном заданном процессе */

В процессе реализации возникло несколько вопросов. Интерфейс должен быть доступен для обычных пользователей, т.е. нам нужно было где-то сохранить права доступа. Второй вопрос — откуда брать ссылку на пространство имен процессов (pidns)?

Начнем со второго. Мы используем netlink интерфейс, который базируется на сокетах и используется в основном в сетевой подсистеме. Ссылку на сетевое пространство имен берут с сокета. В нашем случае ссылку нужно взять на пространство имен процессов. Почитав немного код ядра, выяснилось, что каждое сообщение содержит информацию об отправителе (SCM_CREDENTIALS). Оно содержит идентификатор процесса, что позволяет нам взять ссылку на пространство имён процессов с отправителя. Это идет вразрез c сетевым пространством имен, т.к. сокет привязывается к пространству имен, в котором он был создан. Брать ссылку на pidns с процесса, запросившего информацию, наверное, допустимо, к тому же мы получаем возможность задать нужный нам неймспейс, т.к. информацию об отправителе можно задать на стадии отправки.

Первая проблема оказалась намного интереснее, хотя ее детали мы долго не могли понять. У файловых дескрипторов в Linux есть одна особенность. Мы можем открыть файл и понизить себе привилегии, при этом файловый дескриптор останется полностью функциональным. Это же в какой-то степени верно и для netlink сокетов, но тут есть проблема, на которую мне указал Энди Лютомирский (Andy Lutomirski). Заключается она в том, что у нас нет возможности точно задать, для чего именно данный сокет будет использоваться. То есть, если у нас есть приложение, которое создает netlink сокет и потом понижает свои привилегии, то это приложение сможет использовать сокет для любой функциональности, которая доступна для netlink сокетов. Иными словами, понижение привилегий не влияет на netlink сокет. Когда мы добавляем новую функциональность к netlink сокетам, мы открываем новые возможности для приложений, их использующих, что является серьезной проблемой безопасности.

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

Так же было предложение сделать транзакционый файл в файловой системе procfs. Идея схожа с тем, что мы делали для netlink сокетов. Открываем файл, записываем запрос, читаем ответ. Именно на этой идее мы и остановились, как на рабочем варианте для следующей версии.

Несколько слов о производительности

Первая версия не вызвала большого обсуждения, но помогла найти еще одну группу людей, заинтересованных в новом, более быстром интерфейсе для получения свойств процессов. Однажды вечером я поделился свой работой с Павлом Одинцовым (@pavelodintsov), и он рассказал, что у него недавно были проблемы с perf-ом, и связаны они были тоже со скоростью сбора атрибутов процессов. Вот так он свел нас с Девидом Аерном (David Ahern), который внес свой немалый вклад в развитие интерфейса. Он также доказал на еще одном примере, что данная работа нужна не только нам.

Сравнение производительности можно начать с простого примера. Предположим, что нам надо для всех процессов получить номер сессии, группы и другие параметры из файлы /proc/pid/stat.

Для честного сравнения напишем небольшую программу, которая будет зачитывать /proc/PID/status для каждого процесса. Ниже мы увидим, что она работает быстрее, чем утилита ps.

        while ((de = readdir(d))) {
                if (de->d_name[0] < '0' || de->d_name[0] > '9')
                        continue;
                snprintf(buf, sizeof(buf), "/proc/%s/stat", de->d_name);
                fd = open(buf, O_RDONLY);
                read(fd, buf, sizeof(buf));
                close(fd);
                tasks++;
        }

Программа для task-diag более объемная. Ее можно будет найти в моем репозитории в директории tools/testing/selftests/task_diag/.

$ ps a -o pid,ppid,pgid,sid,comm | wc -l
50006
$ time ps a -o pid,ppid,pgid,sid,comm > /dev/null

real    0m1.256s
user    0m0.367s
sys     0m0.871s

$ time ./task_proc_all a
tasks: 50085

real    0m0.279s
user    0m0.013s
sys     0m0.255s

$ time ./task_diag_all a

real    0m0.051s
user    0m0.001s
sys     0m0.049s

Даже на таком простом примере видно, что task_diag работает в несколько раз быстрее. Утилита ps работает медленней, так как читает больше файлов на один процесс.

Давайте посмотрим, что нам покажет pref trace --summary для обоих вариантов.

$ perf trace --summary ./task_proc_all a
tasks: 50086

 Summary of events:

 task_proc_all (72414), 300753 events, 100.0%, 0.000 msec

   syscall            calls      min       avg       max      stddev
                               (msec)    (msec)    (msec)        (%)
   --------------- -------- --------- --------- ---------     ------
   read               50091     0.003     0.005     0.925      0.40%
   write                  1     0.011     0.011     0.011      0.00%
   open               50092     0.003     0.004     0.992      0.49%
   close              50093     0.002     0.002     0.061      0.15%
   fstat                  7     0.002     0.003     0.008     25.95%
   mmap                  18     0.002     0.006     0.026     19.70%
   mprotect              10     0.006     0.010     0.020     13.28%
   munmap                 2     0.012     0.020     0.028     40.18%
   brk                    3     0.003     0.007     0.010     30.28%
   rt_sigaction           2     0.003     0.003     0.004     18.81%
   rt_sigprocmask         1     0.003     0.003     0.003      0.00%
   access                 1     0.005     0.005     0.005      0.00%
   getdents              50     0.003     0.940     2.023      4.51%
   getrlimit              1     0.003     0.003     0.003      0.00%
   arch_prctl             1     0.002     0.002     0.002      0.00%
   set_tid_address        1     0.003     0.003     0.003      0.00%
   openat                 1     0.022     0.022     0.022      0.00%
   set_robust_list        1     0.003     0.003     0.003      0.00%

$ perf trace --summary ./task_diag_all a

 Summary of events:

 task_diag_all (72481), 183 events, 94.8%, 0.000 msec

   syscall            calls      min       avg       max      stddev
                               (msec)    (msec)    (msec)        (%)
   --------------- -------- --------- --------- ---------     ------
   read                  31     0.003     1.471     6.364     14.43%
   write                  1     0.003     0.003     0.003      0.00%
   open                   7     0.005     0.008     0.020     26.21%
   close                  6     0.002     0.002     0.003      3.96%
   fstat                  6     0.002     0.002     0.003      4.67%
   mmap                  17     0.002     0.006     0.030     25.38%
   mprotect              10     0.005     0.007     0.010      6.33%
   munmap                 2     0.006     0.007     0.008     13.84%
   brk                    3     0.003     0.004     0.004      9.08%
   rt_sigaction           2     0.002     0.002     0.002      9.57%
   rt_sigprocmask         1     0.002     0.002     0.002      0.00%
   access                 1     0.006     0.006     0.006      0.00%
   getrlimit              1     0.002     0.002     0.002      0.00%
   arch_prctl             1     0.002     0.002     0.002      0.00%
   set_tid_address        1     0.002     0.002     0.002      0.00%
   set_robust_list        1     0.002     0.002     0.002      0.00%

Количество системных вызовов в случае с task_diag серьезно уменьшается.

Результаты для утилиты perf (цитата из письма Девида Аерна (David Ahern)).

> Using the fork test command:
>    10,000 processes; 10k proc with 5 threads = 50,000 tasks
>    reading /proc: 11.3 sec
>    task_diag:      2.2 sec
>
> @7,440 tasks, reading /proc is at 0.77 sec and task_diag at 0.096
>
> 128 instances of sepcjbb, 80,000+ tasks:
>     reading /proc: 32.1 sec
>     task_diag:      3.9 sec
>
> So overall much snappier startup times.

Здесь мы видим прирост производительности на порядок.

Заключение

Данный проект находится в разработке, и всё еще может много раз измениться. Но уже сейчас у нас есть два реальных проекта, на примере которых можно видеть серьезный прирост производительности. Я почти уверен, что в том или ином виде эта работа рано или поздно попадет в основную ветку ядра.

Ссылки

github.com/avagin/linux-task-diag
lkml.org/lkml/2015/7/6/142
lwn.net/Articles/633622
www.slideshare.net/openvz/speeding-up-ps-and-top-57448025