Pull to refresh

Comments 20

Два сервера коньяка этому господину за мой счёт! С новым годом! И спасибо за статью: наглядно и по делу — просто жир!
Очень вкусная статья! Огромное спасибо!

Сорри, не понимаю, у вас в выводе iostat wait_time ~100ms — разве это "ввод-вывод хороший"?!
Да и в целом, если в top system time значителен, во очень многих случаях можно сэкономить время и сразу смотреть на iostat и vmstat в поисках проблем с IO или интенсивного paging'а.

Нет, это как раз и была иллюстрация того, что все не очень здорово и конкретно в I/O: в perf top мы увидели ф-ии IO и предположив, что проблема на уровне IO, проверили гипотезу через iostat.
Диаграмма, аналогичная первой в этой статье, для FreeBSD:
http://www.slideshare.net/brendangregg/meetbsd2014-performance-analysis
вопрос знатокам: если известно, что дело где-то в кернеле, почему бы не использовать /proc/<pid>/stack вместо gdb?
/proc//stack — это стек ядра для данного процесса, а в gdb мы видим user-space стек.
К слову, Brendan Gregg еще написал крутую книгу «Systems Performance: Enterprise and the Cloud» о анализе производительности систему. Также он разрабатывал DTrace и разрабатывает perf. Благодаря ему появилась возможность легко связать вывод perf-а для java процесса и java код.
А мне у него FlameGraph нравится — классная штука для визуализации проблем.
Дело в том, что strace генерирует эту статистику по завершении программы, которую он пасет, которую он трассирует, и если у вас работает nginx, а вы не хотите его прерывать, то вы не получите этой статистики

Strace без проблем подцепляется к уже запущенному процессу. Это, ведь, даже в этом же материале демонстрировалось. В том числе без проблем подцепляется с флагом -c. Или автор что-то другое имел в виду?
Да, Вы правы. Знаете, не скажу сейчас в чем дело, но это какая-то ошибка… На слайде делается strace -c -p и трейсер, дествительно, спокойно аттачится к запущенным процессам и по Ctrl+C показывает статистику.
За netstat с grep'ом надо по рукам линейкой. Давно же уже есть ss который работает в разы быстрее и не блокирует интерфейсы пока работает.
У меня не было целью рассказать об утилитах системного администрирования и как-то их сравнить. Я специально в начале доклада (этот пост — это не статья, а транскрипция моего доклада) рассказал о работе Брендана Грегга и дал ссылку на него — у него очень много именно по инструментарию. Цель же доклада: показать как локализовать проблему производительности и почему для этого желательно иметь базовые знания о ядре ОС.
По вашему примеру научатся новички и потом мы будем видеть треды в духе «где netstat?!».

Пишите статьи с современными тулзами, а не теми, которые были deprecated 5 лет назад https://sourceforge.net/p/net-tools/code/ci/77d0c1b2a55c1af31cce4df68da7bf93c8155111/ https://wiki.linuxfoundation.org/networking/net-tools

Материал Брендана мог быть написан и лет 10 назад, это не отменяет ответственности за обучение людей устаревшим вещам.
ss чисто линуксовая тулза. Кстати, не холивара ради — Брендан Грегг отдает предпочтение FreeBSD, когда стоит вопрос о «понимании того, что происходит на сервере» (говорит об этом в докладах и приводит нелестные для линукса сравнения). В FreeBSD netstat живее всех живых, между прочим (https://github.com/freebsd/freebsd/commits/386ddae58459341ec567604707805814a2128a57/usr.bin/netstat/main.c), и отрабатывает молниеносно (при использовании опции -n, конечно, я б ее вообще по дефолту вшил), поэтому считаю рано его хоронить и бить линейкой.
Есть ss и lsof, если уж быть точным.
Помнится мне тут недавно за подобное напоминание полную шляпу огурцов накидали, славные хаброюзеры кричали, что мало ли что там депрекейтед, а они все равно будут юзать netstat, а когда его выкинут на помойку притащат его с помойки, потому что в их шпаргалках для мамкиных попингуев какие-то дураки по прежнему пишут про устаревший и неудобный netstat.
коллеги, вместо грепанья /proc/net/dev можно использовать nicstat от того же BG.
> А если в TOP всё хорошо?

Там не совсем всё хорошо: все 4 ядра ~22% времени проводят в system, и только ~12% в user.
perf top и тут бы помог.
Очень хотелось в конце статьи прочитать о маленькой победоносной войне. А то получается так — по 8 дескриптору определили access.log и констатировали факт, что это неудивительно. И всё! А делать-то что с этим? Как теперь плавно вывести сервер на нормальную работу?

мне кажется тут два варианта:
1) уменьшить количество IO (в данном случае, например, изменив параметры логгирования nginx)
2) обеспечив требуемые ресурсы IO. например, используя более производительную СХД, либо более быстрые внутренние диски, либо их массив.

Sign up to leave a comment.