Comments 20
Два сервера коньяка этому господину за мой счёт! С новым годом! И спасибо за статью: наглядно и по делу — просто жир!
Очень вкусная статья! Огромное спасибо!
Сорри, не понимаю, у вас в выводе iostat wait_time ~100ms — разве это "ввод-вывод хороший"?!
Да и в целом, если в top system time значителен, во очень многих случаях можно сэкономить время и сразу смотреть на iostat и vmstat в поисках проблем с IO или интенсивного paging'а.
Диаграмма, аналогичная первой в этой статье, для FreeBSD:
http://www.slideshare.net/brendangregg/meetbsd2014-performance-analysis
http://www.slideshare.net/brendangregg/meetbsd2014-performance-analysis
вопрос знатокам: если известно, что дело где-то в кернеле, почему бы не использовать /proc/<pid>/stack вместо gdb?
К слову, Brendan Gregg еще написал крутую книгу «Systems Performance: Enterprise and the Cloud» о анализе производительности систему. Также он разрабатывал DTrace и разрабатывает perf. Благодаря ему появилась возможность легко связать вывод perf-а для java процесса и java код.
Дело в том, что strace генерирует эту статистику по завершении программы, которую он пасет, которую он трассирует, и если у вас работает nginx, а вы не хотите его прерывать, то вы не получите этой статистики
Strace без проблем подцепляется к уже запущенному процессу. Это, ведь, даже в этом же материале демонстрировалось. В том числе без проблем подцепляется с флагом -c. Или автор что-то другое имел в виду?
За netstat с grep'ом надо по рукам линейкой. Давно же уже есть ss который работает в разы быстрее и не блокирует интерфейсы пока работает.
У меня не было целью рассказать об утилитах системного администрирования и как-то их сравнить. Я специально в начале доклада (этот пост — это не статья, а транскрипция моего доклада) рассказал о работе Брендана Грегга и дал ссылку на него — у него очень много именно по инструментарию. Цель же доклада: показать как локализовать проблему производительности и почему для этого желательно иметь базовые знания о ядре ОС.
По вашему примеру научатся новички и потом мы будем видеть треды в духе «где netstat?!».
Пишите статьи с современными тулзами, а не теми, которые были deprecated 5 лет назад https://sourceforge.net/p/net-tools/code/ci/77d0c1b2a55c1af31cce4df68da7bf93c8155111/ https://wiki.linuxfoundation.org/networking/net-tools
Материал Брендана мог быть написан и лет 10 назад, это не отменяет ответственности за обучение людей устаревшим вещам.
Пишите статьи с современными тулзами, а не теми, которые были 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.
Помнится мне тут недавно за подобное напоминание полную шляпу огурцов накидали, славные хаброюзеры кричали, что мало ли что там депрекейтед, а они все равно будут юзать netstat, а когда его выкинут на помойку притащат его с помойки, потому что в их шпаргалках для мамкиных попингуев какие-то дураки по прежнему пишут про устаревший и неудобный netstat.
коллеги, вместо грепанья /proc/net/dev можно использовать nicstat от того же BG.
> А если в TOP всё хорошо?
Там не совсем всё хорошо: все 4 ядра ~22% времени проводят в system, и только ~12% в user.
perf top и тут бы помог.
Там не совсем всё хорошо: все 4 ядра ~22% времени проводят в system, и только ~12% в user.
perf top и тут бы помог.
Очень хотелось в конце статьи прочитать о маленькой победоносной войне. А то получается так — по 8 дескриптору определили access.log и констатировали факт, что это неудивительно. И всё! А делать-то что с этим? Как теперь плавно вывести сервер на нормальную работу?
Sign up to leave a comment.
Как понять, что происходит на сервере