Usage

Easily diagnose and fix common performance and resource issues.

Designers

WilliamJonMcCann, AllanDay

Objectives

Goals

  • Enable users to diagnose and resolve common performance/capacity issues
    • Runaway apps hogging CPU, memory, disk I/O, bandwidth
    • Full disks, including root/home partitions
    • Battery running out too quickly
  • Allow users to understand what is going on with the system

Non Goals

  • Not a development tool

Use cases

  • Watching a film but it keeps pausing.
    • Indicate if there's another app consuming network bandwidth.
  • Why is my computer slow?
    • Indicate if there's a CPU/memory issue
  • I got a warning that I'm almost out of disk space.
    • Allow the user to find out what's using space and allow them to free it up.
  • My battery is running out really quickly!

Technical notes

CPU

Single process applications/activities will encounter limits for the core on which they are running. It is therefore probably worth indicating when single cores have reached capacity.

At the same time, activities that are parallelised could saturate all the cores. Processes are also moved between cores to make the most of the total available CPU capacity. In that sense there *is* a single combined resource. While it is not used evenly, it can run out in certain situations.

At the moment we don't protect certain processes, like the shell, so the system can be affected by heavy CPU usage by apps.

Memory

Memory management is fairly crude on Linux at the moment:

  • If a process tries to claim memory that isn't available, the kernel will just kill it.
  • If you run out of RAM your machine will start swapping, but that's often very slow, so the whole system starts to lag.

Generally speaking if you've used 100% of your memory and your computer is slow, it's a memory issue and you need to free some up. However, it's worth noting that RAM is used for cache which will be reallocated if needed by a process - so this usage either needs to be ignored or differentiated in some way.

Disk I/O

Disk read/write isn't parallelizable, so processes have to compete for it. A single process can hog the disk. Examples: indexing lots of data, downloading a large file.

Spinning disks also have the seek time issue - the time it takes to move to the correct position - which gets worse with data fragmentation. They also have to be spun up if they aren't already rotating.

Network

Not all users will have a good understanding of network bandwidth - they might not realise that some activities/apps use a lot of bandwidth.

Network issues are also related to the available bandwidth of course. Would it be possible to indicate the total amount of bandwidth being used, and whether this is relatively high/low?

Power

Power usage is related to CPU usage - if an app is using a lot of CPU it is also burning through your battery.

Discussion

Need to consider certain locales and deployments where hardware limitations are likely to be encountered (eg. poor quality hardware in hot/humid conditions).

How are users supposed to know that Usage exists? Is it possible to notify them when issues are detected for CPU/memory/etc, in the same way that we do for disk space?

Right now resource usage is only recorded while Usage is running. More historical data would be useful for power, network, etc

Tentative Design

Comments

  • I have created an alternative design proposal with some details on the decisions, available for comments - RobertRoth

  • I think the "Disk space used/available by type of data" goal should also make it easier for people to solve disk space problems. That might be emptying the thumbnail, browser, etc. caches, or finding duplicate files (fdupes is a command-line tool that I use often for that case, but which could do with a GUI equivalent) (-- BastienNocera 2013-11-18 13:41:50)

See Also

Design/Apps/Usage (last edited 2018-02-12 16:07:23 by AllanDay)