Overview

In the Rails framework, web applications are run in an application server, which can be considered the third piece of the web request flow. In this article, we will review the main elements that need to be checked when addressing issues with the application servers.

Contents:

• The application servers
  • Application server types and debug information
    • Passenger
    • Unicorn
    • Puma
  • Managing the application servers
  • Finding logs
• Summary

The application servers

Engine Yard supports three types of application server: Passenger, Puma, and Unicorn. At present, these are generally managed by monit, with the exception of Puma in v7, which is instead managed by Systemd. Note that this is subject to change, as Systemd is the more modern solution and may be extended to more applications going forward.

Note: While many solutions for issues affecting these application servers exist outside of the context of Engine Yard, Engine Yard has a very specific configuration, so be cautious when applying Stack Overflow solutions.

Application server types and debug information

In this section, we will cover the main differences to be taken into account when working with one application server or another. A description of the specifics for each of them can be found in Unicorn vs. Puma vs. Passenger: Comparison of each App Server.

Passenger

The following particularities are relevant when working in an instance where Passenger is deployed:

• Passenger deploys its own version of Nginx (the web server). This is rarely relevant for troubleshooting, but can lead to confusion when checking running processes with ps -aux. 
• Passenger will only have one master process tracked by Monit; It will be necessary to use additional commands to debug the workers.

To debug Passenger, the following commands can be run:

• passenger-status:  Shows all relevant information for the running Passenger process. Of special importance are the following stats:
  • Memory
  • CPU
  • Requests in queue
• passenger-memory-stats: This shows further details for the memory stats; in general, the memory totals are the most useful to know.

Unicorn

The following particularities are relevant when working in an instance where Unicorn is deployed:

• While the Unicorn master will start the workers as required, Monit will track each worker and manage them based on the memory thresholds configured.
• Unicorn does not have a specific command to show process details. Instead, you can use bro info to show some relevant stats, such as the 'web stack' and the 'web stack stats'.

Puma

The following particularities are relevant when working in an instance where Puma is deployed:

• While some customers may attempt to run Puma in older stacks than v6, Puma is only considered to work reliably in v6 and v7. Customers not in these versions are asked to upgrade to a later stack.
• On stack v6, Puma runs in Monit, while stack v7 has two versions:
  • Puma legacy: Up to Puma v5.0, uses Monit.
  • Puma: For Puma v5.1 and above, using Systemd in place of Monit.
• In Monit, Puma works similarly to Unicorn, where all workers are monitored and managed.

Managing the application servers

As mentioned before, Engine Yard implements a specific way of handling the application servers. The process to do so is detailed in Managing Applications with Monit and Systemd.

Finding logs

While a full breakdown of available logs is in the Application Instance Cheat Sheet, we can point to the following logs as having especial relevance for debugging the application servers:

Summary

This article provides a comprehensive guide to troubleshooting Rails applications in an application server. It covers the use of Monit and Systemd, log locations, and specific instructions for Passenger, Unicorn, and Puma.