1

I'm building a monitor to track down all Linux /proc data that can be usefull to understand how the server is behaving. Still I cannot understand if I should track every single CPU (and in a virtual environment they can be many) or I can just track the overall CPU activity (which is basically the sum of the single CPUs).

Tracking everysingle CPUs means tons of data to archive while total CPU is just one and the sum of all others (even more readable than having to see 10-12 different plot).

I really would like to go with Total CPU but I would like to know if there are specific case in which having every tracking of every single CPUs can "save" the life of the sys-admin.

Is there any case that total CPU can be under-analytics about CPU activity?

Max Cuttins
  • 143
  • 1
  • 7
  • 1
    I have an actual use case now that I'm working out with a vendor: The main application in this vendors system is supposed to be multithreaded (i.e. can use all the cores assigned to the VM) but it's not using all cores. It's stuck on one core and nearly maxxing it out while the other 7 cores are basically idle. The aggregate CPU usage seems tolerable (around 50%) but the application is under performing due to the process staying on 1 core. – Brandon Xavier Sep 26 '17 at 23:02

1 Answers1

0

Interrupts! By default kernel binds all interrupts to one core (usualy the first). If irqbalance service isn't used, you may endup with system with low overall load, however single core running at 100% and limiting your server performance.

Jaroslav Kucera
  • 1,545
  • 11
  • 18
  • Ok, but I guess this behaviour happen if you don't run the irqbalance service. Then you need to run this service and the issue is solved. Instead of track down all CPU to see if you are not running irqbalance, you should just check if the service is alive, no? At the moment I don't see any reason to save all CPUs infos instead of saving the total one. – Max Cuttins Sep 28 '17 at 08:31