Note: this text is about Systems Programming on Linux platforms.
This type of interview is focused on finding out what do you know about what happens below the “command line” surface. Down there things can get messier, as processes get created, terminated, the output gets collected, system calls are performed. Things get complicated really fast for the unaware or the unprepared.
Let’s take for example a single command that is being run:
This is a classical interview question, asked for more than 15 years now. I’m not sure if anyone still asks it in 2016, but it’s still interesting to see the answer. So, what happens when this is being run? (No, not the file list display).
From the beginning:
AWS provides a complete monitoring engine called CloudWatch; it works with metrics – including custom, user-provided metrics – and is able to raise alarms when any such metric crosses a certain threshold. This is the tool that is used for all perfomance monitoring tasks within AWS.
This text will cover a monitoring scenario regarding deploying an arbitrary appplication to the cloud and being able to determine what causes the performance limits to be met, be it the application code itself or resource limits enforced by Amazon.
Let’s assume that one has just started using Amazon Web Services and is deploying applications on free tier or other general purpose (T2) instances. One learns that the general purpose instances work with “credits” that allow dealing with short spikes through performance bursting – but once the credits are exhausted the performance is reverted to some baseline. All the particular details do not make a lot of sense but one needs to know if the application can meet the desired service limits with this setup.
Before getting into action, let’s split the “performance” problem in a couple of boxes, as the concept itself is quite general. First, deciding what we want to monitor (an entire system? a particular application?) – and second, deciding on what type of performance monitoring do we require (stats collection by the kernel? in-depth analysis?). Based on this particular classification, we may end up with 4 categories, each with its particular software selection:
Tracing / Profiling / Debugging
netstat offers much more info beyond statistics on interface / protocol and may also be used to monitor individual connections.
dtrace and SystemTap can also trace individual applications.