Help
cancel
Showing results for 
Search instead for 
Did you mean: 

Understanding your graphs part 2 - Processes

GitHub Staff

Understanding your graphs part 2 - Processes

 

In part 1 of our 'Understanding your graphs' mini-series, we talked about GitHub Enterprise System Health graphs. We'll now look at GitHub Enterprise Processes graphs.

 

Processes

The processes graph section looks deeper into the major individual services which make up the GitHub Enterprise appliance. Looking at these services individually can show how usage trends impact system resources over time.

 

Processes

Processes graph

  • Process counts will fluctuate with usage trends.
  • The longpoll process will often have the highest average, with more peaks and valleys reflecting daily web UI usage trends.

 

Memory

Memory graph

  • The unicorn and resque process groups normally consume the highest amount of memory, followed by memcached, mysql, and elasticsearch.
  • resqued, babeld, and git-daemon processes are most influenced by user activity.
  • Elements such the size of repositories interacted with and frequency of requests. Because of this, these process graphs can have peaks and valleys.

 

CPU (Kernel)

CPU (Kernel) graph

  • CPU time consumed by processes accessing hardware directly, via trusted lower level operating system functions.
  • The unicorn process normally consumes the most CPU time.
  • Often has lower values than the following CPU (Application) graph.

 

CPU (Application)

CPU (Application) graph

  • CPU time consumed by processes via Linux kernel interfaces.
  • The majority of GitHub Enterprise service CPU time occurs here.
  • On busy systems, unicorn consumes the most CPU time, followed by babeld, git, git-daemon, and resque.

 

I/O operations (Read IOPS)

I/O operations (Read IOPS) graph

  • git-daemon, and babeld read Input/Output Operations Per Second (IOPS) values are influenced by Git fetch / pull activity.
  • unicorn read IOPS are influenced by web application or API GET requests.
  • resque read IOPS are from background jobs, such as regular repository maintenance and repacking.

 

I/O operations (Write IOPS)

I/O operations (Write IOPS) graph

  • git-daemon write IOPS reflect Git push activity and is most often the largest consumer of write IOPS.
  • resque background jobs, such as search indexing, and repository repacking are also be a large consumer of write IOPS

 

Storage traffic (Read)

Storage traffic (Read) graph

  • Read throughput trends are a counterpart to Read IOPS. These values used together can help determine if storage system read performance is as expected.
  • User activity such as fetching, and retrieving API data will result in read activity.

 

Storage traffic (Written)

Storage traffic (Written)

  • Write throughput trends are a counterpart to Write IOPS. These values used together can help determine if storage system read performance is as expected.
  • Pushes, background repacks, and API POST operations are often the largest influencers of this graph.

 

Continue the conversation

There's more to come in the "Understanding your graphs" mini-series. If you'd like to follow along, subscribe to the "Understanding your graphs" label. Please let us know if you have any questions in the comments!