Открыть список
Как стать автором
Обновить

Комментарии 20

Хорошая работа. Будет здорово если это появится в ядре. Нормальный api для информации о процессах давно напрашивается.
Отличная работа! Как только АПИ появится в ванильной версии ядра, переведем наш сканер аномалий в Linux на новый API вместо тормозного proc: github.com/FastVPSEestiOu/Antidoto
Жду с нетерпением коммита в ядро! =)
НЛО прилетело и опубликовало эту надпись здесь

Супер! А те, кто втупую хвалят интерфейс текстовых файлов, мол, "философия UNIX", "всё есть текст" — просто дураки. Я целую статью запилил на эту тему: https://habrahabr.ru/post/321652 ("UNIX-подобные системы содержат кучу костылей. Крах «философии UNIX»").


Между прочим, procfs перенесена из Plan 9 в Linux (правда, это написано в Википедии с пометкой "[citation needed]"). Поэтому я до недавнего времени думал, что procfs — это очень хорошая идея. Т. к. её реализовали не только в юниксах, но даже и в Plan 9, который, типа, ещё круче. Так вот, нет, ничего подобного. В юниксах ошиблись, и даже в Plan 9 ошиблись, procfs — бред. Андрей, респект!

Если проблема в том, что для получения информации о куче процессов, нужно перебрать кучу файлов, то в ядро добавить в /proc файл, в котором будет краткая инфа сразу по всем процессам. Можно добавить несколько файлов, которые все равно являются просто алиасами к методам, возвращающим нужную инфу.

Но по-сути, в статье показана просто альтернатива ps, которая берет инфу из того же самого /procfs.
ps изначально собирает больше инфы, чем требуется в выводе, поэтому и работает дольше.

Качественный скачок может быть, если в ядре появится нативный интерфейс, отличный от /proc
Но по-сути, в статье показана просто альтернатива ps, которая берет инфу из того же самого /procfs.
ps изначально собирает больше инфы, чем требуется в выводе, поэтому и работает дольше.

Качественный скачок может быть, если в ядре появится нативный интерфейс, отличный от /proc

Нет, представлен как раз другой нативный интерфейс. Просто не присутствующий в ванильном ядре Linux. То есть автор форкнул ядро Linux, внёс в него изменения, и теперь Linux даёт принципиально другой интерфейс. Правда, это интерфейс, через новый файл в /proc. Т. е. интерфейс всё равно завязан на /proc. Но он новый.


Если проблема в том, что для получения информации о куче процессов, нужно перебрать кучу файлов, то в ядро добавить в /proc файл, в котором будет краткая инфа сразу по всем процессам.

Именно это автор и сделал. Добавил новый файл в /proc. Файл /proc/task_diag. Вот же он пишет:


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

Если посмотреть ссылку в конце статьи ( http://www.slideshare.net/openvz/speeding-up-ps-and-top-57448025 ), то там рассказывается то же самое, и, на мой взгляд, лучше.


Точнее говоря, это не файл, в котором сразу вся инфа, это файл, в который нужно отправлять запрос и получать ответ, зависящий от запроса.

Точнее говоря, это не файл, в котором сразу вся инфа, это файл, в который нужно отправлять запрос и получать ответ, зависящий от запроса.

Интересно, это не приведет к гонкам?


  • Процесс A пишет запрос
  • Процесс B пишет запрос
  • Прочесс A читает ответ для процесса B...

Это ведь и потенциальная дырка — чужой процесс теоретически сможет таким образом подменять информацию, запрашиваемую процессом A

Спросите это у avagin. Моё предположение: ядро помнит, какой файловый дескриптор что спросил
Нет, не приведет. На самом деле все файлы в /proc это запрос на какие-то данные, т е сама по себе эта проблема решена давно.
Изначально, я свой интерфейс делал через netlink, но неожиданно для себя обнаружил, что этот мощный интерфейс считается для нужд сетевой подсистемы и некоторые попытки использования его в других подсистемах плохо себя показали. Это я к тому, что если надо мой новый интерфейс не имеет жестких завязок на /proc.

Сама идея файловой системы /proc не является ошибочной. На пример, в /proc есть «magic symlink» (/proc/pid/root, /proc/pid/fd/X, /proc/pid/cwd, etc), которые вряд ли получится заменить на что-то координатно другое.

Скажите, пожалуйста, жив ли ещё этот проект и поддерживает ли ядро на данный момент этот или какой-то другой механизм быстрого получения информации о процессах (например, аналогичной содержащейся в /proc/PID/maps)?

В апстрим все это так и не попало. В прошлом году обсудили как это можно переделать, но не переделали.

Понятно. Значит, придётся кешировать :) Впрочем, в случае одного процесса и большого количества повторных запросов это в любом случае нужно делать. А вот для сбора информации обо всей системе — да, проблема...

А что является основным препоном / какие требования выдвинули?
Можете, пожалуйста, дать ссылки на обсуждения?
Основное обсуждение произошло год назад в рамках Linux Kernel Summit. Там были разобраны главные причины медленной работы текущего интерфейса.
1. Формат файлов разный и не всегда расширяемый.
2. Некоторые файлы содержат информацию, которая нужна не часто, но ее получение занимает львиную часть времени.
3. Форматирование в текстовый формат — это очень дорогая операция (printf)
4. Три системных вызова (open, read, close) — это тоже очень дорого.

Что было предложено:
1. Добавить несколько новых файлов в /proc/pid c форматом, как у netlink сообщений.
2. Набор атрибутов в файлах будет фиксированный. У task-diag пользователь имел возможность сказать.
3. Есть отдельно файл с быстрыми атрибутами и с медленными.

К сожалению, я так и не нашел времени все это сделать. Работы тут на неделю, с учетом что большая часть кода уже написана в рамках task-diag. Никакой уверенности, что эту схему возьмут в апстрим нет:), но тут хотя бы есть поддержка у тех 5-10 человек, кто присутствовал на обсуждении.
Ага, ясно, т.е. текущее предложение — файлы вместо request/response, да?

Планируете двигать это дальше? В каком виде можно вам помочь?
Планирую, но пока нет времени. Если есть то можете заиплементить один из этих файлов и попробовать заслать в lkml. Я могу помощь советом, ревью и своим кодом из linux-task-diag.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.