Book Image

Red Hat Enterprise Linux Troubleshooting Guide

By : Benjamin Cane
Book Image

Red Hat Enterprise Linux Troubleshooting Guide

By: Benjamin Cane

Overview of this book

Red Hat Enterprise Linux is an operating system that allows you to modernize your infrastructure, boost efficiency through virtualization, and finally prepare your data center for an open, hybrid cloud IT architecture. It provides the stability to take on today's challenges and the flexibility to adapt to tomorrow's demands. In this book, you begin with simple troubleshooting best practices and get an overview of the Linux commands used for troubleshooting. The book will cover the troubleshooting methods for web applications and services such as Apache and MySQL. Then, you will learn to identify system performance bottlenecks and troubleshoot network issues; all while learning about vital troubleshooting steps such as understanding the problem statement, establishing a hypothesis, and understanding trial, error, and documentation. Next, the book will show you how to capture and analyze network traffic, use advanced system troubleshooting tools such as strace, tcpdump & dmesg, and discover common issues with system defaults. Finally, the book will take you through a detailed root cause analysis of an unexpected reboot where you will learn to recover a downed system.
Table of Contents (19 chapters)
Red Hat Enterprise Linux Troubleshooting Guide
Credits
About the Author
About the Reviewers
www.PacktPub.com
Preface
Index

Resolving the issue in the long-term and short-term


Issues such as the one discussed in this chapter can be a bit tricky, as they generally have two paths to resolution. There is a long-term fix and a short-term fix; both are necessary, but one is only temporary.

Long-term resolution

For the long-term resolution of this issue, we really have two options. We could increase the server's physical memory to provide both Apache and Processor adequate memory for their tasks. Alternatively, we could move the processor to another server.

Since we know that this server has frequently killed the Apache service and the processor job, it is likely that the memory on the system is simply too low for it to perform both these roles. By moving the processor job (and likely the custom app that it is part of) to another system, we would be moving the workload to a dedicated server.

On the basis of the memory usage of the processor, it may also be worth increasing the memory on the new server as well. As it seems...