Лучше чем iotop!
Hellsy22 25 апреля, 2013 - 11:49
И снова здравствуйте. Это снова я и мне снова нужна информация.
Суть проблемы: комп постоянно шуршит винтом, будь это на винде я бы даже спрашивать не стал, но здесь-то все в моей власти *маниакальный смех*. В общем, хочу выяснить, что почему шуршит, зачем и как это сократить. А для этого нужно знать какие процессы куда и что пишут. С конкретными именами файлов и объемами чтения/записи.
Я попробовал 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* во время "шуршения". Интересны названия процессов из иотоп, шуршение сие вызывающие.
Способ решения вашей проблемы можно было бы предложить если бы вы соизволили изложить конечную цель, а не препятствия на выбранном вами пути. Иотоп вполне понятно показывает наиболее активный по ио пид. Неугодный нам пид либо подгибается под наши нужды конфигом, либо выбрасывается на свалку вместе с пакетом его содержащим как никчемное поделие. Что именно шуршит вашим винтом?
/
Здесь фишка в том, что решение о закупке ПО принимают одни люди, а эксплоатируют его обычно совсем другие.
В результате разработчику проприетарного ПО очень сложно избежать соблазна уклона в направлении произведения впечатления на... господ, ведающих выделением финансирования.
:wq
--
Live free or die
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 ;)
/
Главное --- ни в коем случае не приводить списка необходимых условий выполнимости тезиса.
Чтобы типический покупатель виндавса веровал, что заявленное возможно не в супер-пупер-тырпрайс версии, а в конкретной наличной, купленной им.
Ну и чтобы самому ножке не пришлось настраивать ХРень (помним про прикладное ПО) согласно заявленному.
: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 ;)
/
Ога.
Самый забавный фанатик здесь сам ножка.
Пока же можно развалившись в кресле понаблюдать за осознанием оным сути приведённой им ссылки (ну что поделать: нет у бедняжки, сколь ни пыжься, личного опыта поиска в тырпрайс-документации достаточного ответа на конкретный вопрос, а он естественно-закономерно не снисходит до ссылок на оригиналы).
ЗЫ: Упоротость в попытке обозвать последовательность фанатичностью лечится только по прогрессивной методике проф. Луговского.
: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:
Для x64:
Написал правила:
-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
В логах:
# aureport -f
Т.е. логируется из всего списка лишь syscall равный 2 (open для x64)
Опытным путем было установлено, что arch=c000003e - это x64 (кстати, в документации об этом ни слова. Забравшись в гугле аж на третью страницу я все еще не нашел ответа, какой номер чему соответствует).
В общем, аудит упорно не желает поддаваться.
Какие-нибудь подсказки?