Comments 20
Супер! А те, кто втупую хвалят интерфейс текстовых файлов, мол, "философия UNIX", "всё есть текст" — просто дураки. Я целую статью запилил на эту тему: https://habrahabr.ru/post/321652 ("UNIX-подобные системы содержат кучу костылей. Крах «философии UNIX»").
Между прочим, procfs перенесена из Plan 9 в Linux (правда, это написано в Википедии с пометкой "[citation needed]"). Поэтому я до недавнего времени думал, что procfs — это очень хорошая идея. Т. к. её реализовали не только в юниксах, но даже и в Plan 9, который, типа, ещё круче. Так вот, нет, ничего подобного. В юниксах ошиблись, и даже в Plan 9 ошиблись, procfs — бред. Андрей, респект!
Но по-сути, в статье показана просто альтернатива 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
Сама идея файловой системы /proc не является ошибочной. На пример, в /proc есть «magic symlink» (/proc/pid/root, /proc/pid/fd/X, /proc/pid/cwd, etc), которые вряд ли получится заменить на что-то координатно другое.
del
Скажите, пожалуйста, жив ли ещё этот проект и поддерживает ли ядро на данный момент этот или какой-то другой механизм быстрого получения информации о процессах (например, аналогичной содержащейся в /proc/PID/maps
)?
Понятно. Значит, придётся кешировать :) Впрочем, в случае одного процесса и большого количества повторных запросов это в любом случае нужно делать. А вот для сбора информации обо всей системе — да, проблема...
Можете, пожалуйста, дать ссылки на обсуждения?
1. Формат файлов разный и не всегда расширяемый.
2. Некоторые файлы содержат информацию, которая нужна не часто, но ее получение занимает львиную часть времени.
3. Форматирование в текстовый формат — это очень дорогая операция (printf)
4. Три системных вызова (open, read, close) — это тоже очень дорого.
Что было предложено:
1. Добавить несколько новых файлов в /proc/pid c форматом, как у netlink сообщений.
2. Набор атрибутов в файлах будет фиксированный. У task-diag пользователь имел возможность сказать.
3. Есть отдельно файл с быстрыми атрибутами и с медленными.
К сожалению, я так и не нашел времени все это сделать. Работы тут на неделю, с учетом что большая часть кода уже написана в рамках task-diag. Никакой уверенности, что эту схему возьмут в апстрим нет:), но тут хотя бы есть поддержка у тех 5-10 человек, кто присутствовал на обсуждении.
Планируете двигать это дальше? В каком виде можно вам помочь?
del
Новый интерфейс для получения атрибутов процессов в Linux