I'm wondering if there's a way to automate this kind of analysis to give you condensed, interesting points of a system performance status. À la powertop for power management.
glances. Mentioned elsewhere in the thread.
Linux Performance Analysis
21–30 of 84 posts
Re: Linux Performance Analysis
#22I'm wondering if there's a way to automate this kind of analysis to give you condensed, interesting points of a system performance status. À la powertop for power management.
Collectd + Graphite / InfluxDB + Grafana. You shoudn't need to ssh on a host to see those metrics.
Re: Linux Performance Analysis
#23If you want more from Brendan Gregg on analyzing performance, be sure to check out his book, Systems Performance: http://smile.amazon.com/dp/0133390098
Re: Linux Performance Analysis
#24that's a pretty awesome summary. to that i would add: * `iftop` that allows me to quickly check which network streams are hogging the machine (this is a little like sar -n DEV 1 but much more detailed!) * `tcpdump -c 100 -vv`- poor man's alternative to iftop or systat if they're not available locally * tail those logfiles, with systemd it's even easier with journald as all logfiles can be checked at once: `journalctl…
I'll add to your list with htop. Its a little nicer than plain ole top.
problem with (h)top is that it doesn't catch short-lived processes, and it displays only the most basics stats. For more detailed perf analysis you will likely be better with something like atop
Re: Linux Performance Analysis
#25I'm wondering if there's a way to automate this kind of analysis to give you condensed, interesting points of a system performance status. À la powertop for power management.
glances. Mentioned elsewhere in the thread.
Very nice. https://github.com/nicolargo/glances/
I like how there are configurable alerts for each datapoint, that's a start for analyzing what's wrong.
Re: Linux Performance Analysis
#26that's a pretty awesome summary. to that i would add: * `iftop` that allows me to quickly check which network streams are hogging the machine (this is a little like sar -n DEV 1 but much more detailed!) * `tcpdump -c 100 -vv`- poor man's alternative to iftop or systat if they're not available locally * tail those logfiles, with systemd it's even easier with journald as all logfiles can be checked at once: `journalctl…
I'll add to your list with htop. Its a little nicer than plain ole top.
Also like to add atop. I love the interface and usually is my first command I launch.
Re: Linux Performance Analysis
#27If you want more from Brendan Gregg on analyzing performance, be sure to check out his book, Systems Performance: http://smile.amazon.com/dp/0133390098
There was an interesting interview with him earlier in the year on Software Engineering Radio where he talked about his book: http://www.se-radio.net/2015/04/se-radio-episode-225-brendan...
Re: Linux Performance Analysis
#28> Don’t miss this step! dmesg is always worth checking.
Best advice given in the whole article. Many times I go to check something that "can't figure out what is wrong." dmseg | tail and then the swearing begins on their end.
Re: Linux Performance Analysis
#29that's a pretty awesome summary. to that i would add: * `iftop` that allows me to quickly check which network streams are hogging the machine (this is a little like sar -n DEV 1 but much more detailed!) * `tcpdump -c 100 -vv`- poor man's alternative to iftop or systat if they're not available locally * tail those logfiles, with systemd it's even easier with journald as all logfiles can be checked at once: `journalctl…
If you like iftop, iptraf is similar and goes deeper in the ability to dig into TCP details or confuse yourself with scads of BPF rules.
Re: Linux Performance Analysis
#30> Don’t miss this step! dmesg is always worth checking. Best advice given in the whole article. Many times I go to check something that "can't figure out what is wrong." dmseg | tail and then the swearing begins on their end.
Can you imagine a world where the Windows System Event Viewer was this useful?
It's amazing how much time one useful error message can save.
Also, I'm a little disappointed that the author didn't drill down into what the actual problem was in his example. That java process is of course suspicious, but that might just be the video server and expected behavior.