As it could be a 24 hour snapshot theres a possibility of skewed results so bear that in mind. This, by no means actually gives you a definite idea what process it might be that is the cause of this problem, but might give you good feel. Process accounting only accounts properly when its on when processes spawn, so its probably best to restart the system after enabling it to ensure all services are being accounted for. This breaks down the data as the total amount of CPU time (the top row) and then how that CPU time has been split up. What you'll be looking for is the process types that generate the most User/System CPU time. Amount of real time spent on all the processes of this type.If it was not running before this will need time to run. This will enable process accounting (if not already added). The second way to look for this is to enable process accounting. There is a problem with this, primarily if the box goes into a runaway cpu loop and produces huge load - your not guaranteed that your actual process will execute in a timely manner during load (if at all) so you could actually miss the output! I would suggest this be your first port of call since it produces the most valuable/reliable data to work with. This will give you a quite detailed outlook of the running of the system at ten minute intervals. pidstat -u 600 >/var/log/pidstats.log & disown $! The first way is to setup pidstat to run in the background and produce data. Note that its entirely possible its many processes in a runaway scenario causing this, not just one. There are a couple of possible ways you can do this.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |