Лучше чем iotop!

И снова здравствуйте. Это снова я и мне снова нужна информация.

Суть проблемы: комп постоянно шуршит винтом, будь это на винде я бы даже спрашивать не стал, но здесь-то все в моей власти *маниакальный смех*. В общем, хочу выяснить, что почему шуршит, зачем и как это сократить. А для этого нужно знать какие процессы куда и что пишут. С конкретными именами файлов и объемами чтения/записи.

Я попробовал iotop -Paqqbod 600, но там никакой конкретики, только общие объемы IO у процессов.

Какую утилиту порекомендуете? И как бы снизить активность jbd (это, как я понял, процесс обслуживающий ext4) - я пробовал опцию маунта commit=60, но эффекта это не произвело.

sys-apps/dstat ?

sys-apps/dstat ?

P.S.: Linux - это красная таблетка :-) Windows - синяя...

dstat отличная утилита, но

dstat отличная утилита, но она тоже показывает лишь итоговые значения по дискам.

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

lsof/gamin?

lsof/gamin(inotify)?

http://serverfault.com/questi

http://serverfault.com/questions/219323/monitor-open-process-files-on-linux-real-time
https://www.google.ru/search?q=linux+openfile+monitor&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a
начать отсюда, а далее видно будет...

P.S.: Linux - это красная таблетка :-) Windows - синяя...

Спасибо, я, разумеется,

Спасибо, я, разумеется, сперва проверил google. Но у меня складывается странное ощущение, что никого из линуксоидов никогда не интересовало какой процесс (ветка процессов) сколько и куда пишет данных и откуда читает. В винде соотв. монитор ресурсов появился аж пять лет назад. А тут изобилие утилит для просмотра открытых файловых дескрипторов по процессам (тот же lsof), но нет IO. Или есть IO, по процессам, но нет привязки к конкретным файлам (iotop).

Вроде бы у iotop есть опция

Вроде бы у iotop есть опция -o которая выводит только процессы, что в данный момент делают io.

Кстати, а ядро поддерживает сбор статистики по IO? Опции CONFIG_TASK_IO_ACCOUNTING, CONFIG_TASK_DELAY_ACCT, CONFIG_TASKSTATS.

Чем больше юзерфрендли, тем сложнее юзать.

У вас совершенно правильное

У вас совершенно правильное ощущение. На момент отказа в обслуживании меня интересует конкретный пид (ни слова матом :)). По определении пид, его (во имя общего блага, разумеется) следует немедленно отстрелить (и в этом случае сокращение "пид" может означать не только идентификатор процесса) . Таким образом восстанавливается работа безусловного большинства. Расследование причин инцидента и нахождение способов недопущения нерационального распределения ресурсов может занять значительное время. А качество сервиса - есть качество сервиса. Комбайнов "все в одном" под никсами мало, ибо "юникс вей". Каждой утилите свое назначение. Нужный сервис можно достаточно легко получить склеив пару - тройку тузл шеллом. Широко делиться наколенными поделками не принято из за естественной кривизны коленки, и частично неестественной кривизны рук. Монитор ресурсов в винде имхо совершенно бесполезная свиристелка ибо:
1) У меня нет времени на нее смотреть, а посему через нее никогда нельзя узнать самое интересное. Много больше даст настроенный заббикс (к примеру).
2) Что-то не нашел там заявленного вами функционала, типа мониторинга в какой именно файл какой процесс пишет. Интересно было бы взглянуть на реализацию подобного функционала в традиционно "красивом" графическом интерфейсе.
3) ДАРЗАНЕБЫ (R) за степень контроля надо платить теми самыми ресурсами, которые вы своим контролем пытаетесь оптимизировать.

"Шуршение винта" - замечательный термин. Но top несколько точнее. Ежели во время "шуршения" параметр wa в пределах от нуля до единицы, значит сие шуршение винта есть свойство винта, оптимизируется заменой винта. Интересны показания iostat -x 1 /dev/sd* во время "шуршения". Интересны названия процессов из иотоп, шуршение сие вызывающие.

Способ решения вашей проблемы можно было бы предложить если бы вы соизволили изложить конечную цель, а не препятствия на выбранном вами пути. Иотоп вполне понятно показывает наиболее активный по ио пид. Неугодный нам пид либо подгибается под наши нужды конфигом, либо выбрасывается на свалку вместе с пакетом его содержащим как никчемное поделие. Что именно шуршит вашим винтом?

/

wi написал(а):
2) Что-то не нашел там заявленного вами функционала, типа мониторинга в какой именно файл какой процесс пишет. Интересно было бы взглянуть на реализацию подобного функционала в традиционно "красивом" графическом интерфейсе.

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

:wq
--
Live free or die

2) Что-то не нашел там

2) Что-то не нашел там заявленного вами функционала, типа мониторинга в какой именно файл какой процесс пишет. Интересно было бы взглянуть на реализацию подобного функционала в традиционно "красивом" графическом интерфейсе.

Оно там конешна есть, но
1) закопано далеко
2) не в таск манагере
3) жрет ресурсы
4) ограничения a'ля accountd только в серверах типа Ынтырпрайс/Датабасе
5) требует моск выше среднего по винде
6) в экосистеме винды практически не нужно
7) "размазано" по системе

:)

П.С Как и 90% линуксоедов ТС ругает Шаляпина по напевам Изи

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

Я и не предполагал, что такой

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

Мне бы хотелось получить лог событий с подробным описанием типа:

процесс AA (2711): открыт файл "name", дескриптор 123
процесс AA (2711): запись 1024 байт с позиции 8381, дескриптор 123
процесс АА (2711): закрыт файл, дескриптор 123

При этом мне совершенно не нужны все ваши эти однотипные комбайны. Только сырой лог. Только хардкор.

Только сырой лог. Только

 Только сырой лог. Только хардкор.
»

Moя сумает, что он для вас неразбирабельный - ибо баитстрим, если мну не изменяет память.
Так што auditctl/acct - и вперед писатьц правила;
П.С вобщето что в винде, что в линуксе технически можно ограничить юзера с точностью до сискалла ;); Глубжее только системтап и опрофиле

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

/

slepnoga написал(а):
П.С вобщето что в винде, что в линуксе технически можно ограничить юзера с точностью до сискалла ;); Глубжее только системтап и опрофиле

Главное --- ни в коем случае не приводить списка необходимых условий выполнимости тезиса.
Чтобы типический покупатель виндавса веровал, что заявленное возможно не в супер-пупер-тырпрайс версии, а в конкретной наличной, купленной им.
Ну и чтобы самому ножке не пришлось настраивать ХРень (помним про прикладное ПО) согласно заявленному.

:wq
--
Live free or die

По просьбе Анархиста, для

По просьбе Анархиста, для подкормки - вброс.
http://en.wikipedia.org/wiki/Windows_System_Resource_Manager

П.С Фанатики чего либо всегда вызывали смех и желания помочь им пофанатеть

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

/

slepnoga написал(а):
По просьбе Анархиста, для подкормки - вброс.
http://en.wikipedia.org/wiki/Windows_System_Resource_Manager

П.С Фанатики чего либо всегда вызывали смех и желания помочь им пофанатеть

Ога.
Самый забавный фанатик здесь сам ножка.

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

ЗЫ: Упоротость в попытке обозвать последовательность фанатичностью лечится только по прогрессивной методике проф. Луговского.

:wq
--
Live free or die

http://www.xaprb.com/blog/200

http://www.xaprb.com/blog/2009/08/23/how-to-find-per-process-io-statistics-on-linux/

Ебилда нет, судя по всему. Не представляю чем это может помочь в вашем случае ибо кэш.

То что вы хотите делается

То что вы хотите делается аудитом. sys-process/audit + соответствующие параметры ядра. в сети есть конкретные инструкции, насколько помню, для редхата или типа того.

если обратно, то есть, есть файл хотим знать только кто(упс, ошибочка, "кто" - не узнам) и зачем к нему обращается, то inotifywait -m

линупс как бы унутрях до сих пор серверная херь и решения соотвествующие. хотя со стороны может показаться "пушкой по воробьям".

Ну и да, как заметил ножка, вроде бы простые вопросы могут требовать серъезного подхода даже в виндах.

:)

Спасибо, разбираюсь с

Спасибо, разбираюсь с audit.

Вы случайно не знаете, где можно найти список syscall, с сопоставлением номеров, алиасов и рашифровкой? А то я вот написал вроде как простое правило:

-a exit,always -F arch=b32 -S open -S close -S read -S write -S unlink -F dir=/home -F success=1
-a exit,always -F arch=b64 -S open -S close -S read -S write -S unlink -F dir=/home -F success=1

А на выходе только syscall-ы с номером 2, который по найденной мной документации вообще к файлам не относится - sys_fork

в сорцах глибца/ядра - сейчас

в сорцах глибца/ядра
Погляди в /usr/include/asm/unistd.h

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

В общем, я там нашел: Для

В общем, я там нашел:

Для x32:

#define __NR_read 3
#define __NR_write 4
#define __NR_open 5
#define __NR_close 6
#define __NR_creat 8
#define __NR_unlink 10

Для x64:

#define __NR_read 0
#define __NR_write 1
#define __NR_open 2
#define __NR_close 3
...
#define __NR_creat 85
#define __NR_unlink 87

Написал правила:
-a exit,always -F arch=b32 -S 3 -S 4 -S 5 -S 6 -S 8 -S 10 -F dir=/root
-a exit,always -F arch=b64 -S 0 -S 1 -S 2 -S 3 -S 85 -S 87 -F dir=/root

(прим. я пробовал и так: -a exit,always -F arch=b64 -S open -S close -S read -S write -S unlink -F dir=/root)

Затем:
# touch test.file
# echo 111 >> test.file
# cat test.file
111
# rm test.file

В логах:

type=SYSCALL msg=audit(1367383630.761:87): arch=c000003e syscall=2 success=yes exit=3 a0=7fffdf6ab8ee a1=941 a2=1b6 a3=7fffdf6a9d60 items=3 ppid=18557 pid=30618 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=3 tty=pts0 comm="touch" exe="/bin/touch" key=(null)
type=PATH msg=audit(1367383630.761:87): item=0 name="test.file" inode=262145 dev=08:03 mode=040700 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1367383630.761:87): item=1 name=(null) inode=262145 dev=08:03 mode=040700 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1367383630.761:87): item=2 name=(null) inode=262152 dev=08:03 mode=0100644 ouid=0 ogid=0 rdev=00:00
type=SYSCALL msg=audit(1367383646.251:88): arch=c000003e syscall=2 success=yes exit=3 a0=7fffbee658f2 a1=0 a2=0 a3=7fffbee63aa0 items=1 ppid=18557 pid=30621 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=3 tty=pts0 comm="cat" exe="/bin/cat" key=(null)
type=PATH msg=audit(1367383646.251:88): item=0 name="test.file" inode=262152 dev=08:03 mode=0100644 ouid=0 ogid=0 rdev=00:00

# aureport -f

File Report
===============================================
# date time file syscall success exe auid event
===============================================
1. 05/01/2013 08:47:10 test.file 2 yes /bin/touch 1000 87
2. 05/01/2013 08:47:26 test.file 2 yes /bin/cat 1000 88

Т.е. логируется из всего списка лишь syscall равный 2 (open для x64)
Опытным путем было установлено, что arch=c000003e - это x64 (кстати, в документации об этом ни слова. Забравшись в гугле аж на третью страницу я все еще не нашел ответа, какой номер чему соответствует).

В общем, аудит упорно не желает поддаваться.
Какие-нибудь подсказки?

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".