Tasks: 165 total, 2 running, 113 sleeping, 0 stopped, 0 zombie

If you look at the first one, which is MySQL is taking 11.9% of CPU and 2.5% of CPU. You may want to start by looking into top or htop result to see the processes overview.Īs you can see below, it gives an excellent idea about what all processes are utilizing. But if you don’t have one or looking for a command-based solution, then here you go. There are many monitoring software which does this out of the box. However, imagine a shared server where multiple services are running, and you need to find which one is eating all the resources. If the server host just one process, then it’s easy to find out when the process consumes all the resources. It's just a guess - I haven't looked into details if someone does and has a solution preventing full rescanning on each run, I would like to hear it here as this would be a more correct solution than excluding the whole mount point from updating.Know how much an individual process or system-wide consume CPU or memory.Īs a sysadmin, you often have to deal with an incident where the application is slow or unresponsive due to high CPU/memory/network utilization. The fact that updatedb.mlocale thinks all directories on an NTFS partition are always new is probably related to the way how inodes are represented by ntfs-3g. Code: sudo lsof I easily found that the 100% CPU load is created by the updatedb.mlocate script run by cron once per day to update the locate database (man updatedb for more info).įor some reason, updatedb.mlocate thinks that all directories on the NTFS partition have been changed and performs a full rescan of the partition which creates high CPU load due to the limitation of the free version of the ntfs-3g driver used in Ubuntu (this limitation is well known and described somewhere else).Ī possible workaround is to append the path to the NTFS mount point to the PRUNEPATHS variable in /etc/nf to exclude this mount point from the process of updating the locate database.

Ubuntu show cpu usage