Skip to main content

Hiding poor performance in processor cycles

Solaris remains the only operating system capable of microstate accounting. Other operating systems like Linux, FreeBSD, and Windows can not accurately report how their kernel spends an application's user mode time and kernel mode time. Although, Linux kernel 3.0 says it supports microstate accounting it only reports approximate time spent as percentages. What that means is applications can hide their poor performance in processor cycles.

Even if your kernel doesn't support microstate accounting you can still investigate your application for poor performance using commands like time, killall, timeout and vmstat.

The command time reports three psuedo time values of a running process: real time, user time, and system time. Only real time is valuable, but it isn't actually real time. Run time using your application's absolute path as its argument:

time <command> 2>&1;

Once your application opens, guide your application to the point you want to check then kill it by sending your application the signal SIGTERM, SIGSTOP or SIGKILL. (You could also start using it as you normally would then kill it when it starts hanging or slowing down.) Run killall to kill all processes owned by your application:

killall -s <signal> <command or pid>;

Run your application again, but this time use your application's real time as the argument for the command timeout along with "vmstat 1". The command timeout runs vmstat every 1 second for the amount of real time. Guide your application to the same point you wanted to check before. The command vmstat will display CPU information every second leading up to your checkpoint including the processing of the kill signal. Here's the command to run:

<command> 2>&1; timeout <real time> vmstat 1 2>&1;

Do you have a suggestion about how to improve this blog? Let's talk about it. Contact me at David.Brenner.Jr@Gmail.com or 720-584-5229.

Comments

Popular posts from this blog

The meaning of time in reinforcement learning

Reinforcement learning (RL) is one of three basic machine learning paradigms, alongside supervised learning and unsupervised learning. Reinforcement learning is concerned with how software agents ought to take actions in an environment in order to maximize the notion of cumulative reward through the process of trial and error. In reinforcement learning an agent starts at an empty state then analyzes the available datasets according to a policy of positive states and negative states. Rather than being explicitly taught as in supervised learning the correct set of actions for performing a task, reinforcement learning uses rewards as signals for positive states and punishments as signals for negative states. The agent obtains the best path to a desirable reward as a cumulation of positive states and negative states. As compared to unsupervised learning, reinforcement learning is different in terms of goals. While the goal in unsupervised learning is to find similarities and differences...

Threat hunting polymorphic malware in Linux with Python

You can investigate suspicious activity that could be polymorphic malware by collecting relevant machine data from your endpoint. You can use the machine data to create your own analysis. Before you start your investigation you will need to determine normal activity on your endpoint. Normal activity is the scope of functionality of the software on your endpoint during periods of low activity and high activity. You will need some kind of software that periodically collects specific machine data from your endpoint like my software developed in Python that's available for free download at https://github.com/davidbrennerjr/server-stats-collector Ingest one or more of the following machine data from Category #1. Ingest one or more of the following machine data from Category #2. And ingest one or more of the following machine data from Category #3. Category #1 General system-wide error messages from /var/log/syslog Auditing logs of application rule...

Application behavior monitoring in Linux with Python

You can monitor application behaviors by collecting relevant machine data from your endpoint. You can use the machine data to investigate suspicious activity and create your own analysis. Before you start your investigation you will need to determine normal activity on your endpoint. Normal activity is the scope of functionality of the software on your endpoint during periods of low activity and high activity. You will need some kind of software that periodically collects specific machine data from your endpoint like my software developed in Python that's available for free download at https://github.com/davidbrennerjr/server-stats-collector Ingest one or more of the following machine data from Category #1. Ingest one or more of the following machine data from Category #2. Category #1 General system-wide error messages from /var/log/syslog Auditing logs of application rulesets Auditing logs of security contexts Auditing logs of ...