One place for hosting & domains

      Troubleshoot

      How To Troubleshoot Common Apache Errors



      Part of the Series:
      Common Apache Errors

      This tutorial series explains how to troubleshoot and fix some of the most common errors that you may encounter when using the Apache web server.

      Each tutorial in this series includes descriptions of common Apache configuration, network, filesystem, or permission errors. The series begins with an overview of the commands and log files that you can use to troubleshoot Apache. Subsequent tutorials examine specific errors in detail.

      Series Description

      This tutorial series explains how to troubleshoot and fix some of the most common errors that you may encounter when using the Apache web server.

      Each tutorial in this series includes descriptions of common Apache configuration, network, filesystem, or permission errors. The series begins with an overview of the commands and log files that you can use to troubleshoot Apache. Subsequent tutorials examine specific errors in detail.

      Introduction

      There are three main commands, and a set of common log locations that you can use to get started troubleshooting Apache errors. Generally when you are troubleshooting Apache, you will use these commands in the order indicated here, and then examine log files for specific diagnostic data.

      The commands that you will commonly use to troubleshoot Apache across most Linux distributions are:

      • systemctl – Used to control and interact with Linux services via the systemd service manager.
      • journalctl – Used to query and view the logs that are generated by systemd.
      • apachectl – When troubleshooting, this command is used to check Apache’s configuration.

      These commands, how to use them, and Apache’s log locations where you can find additional information about errors are described in further detail in the following sections.

      Note: On Debian and Ubuntu systems, the Apache service and process name is apache2, whereas on CentOS, Fedora, and other RedHat-derived systems, Apache’s service and process name is httpd. Apart from the differences between the service and running process names, starting, stopping, and checking Apache’s status, as well as logs with journalctl should work the same on any Linux system that uses systemd to manage the Apache service. Be sure to use the correct name for your Linux distribution.

      systermctl Commands for Apache

      To troubleshoot common Apache errors using the systemd service manager, the first step is to inspect the state of the Apache processes on your system. The following systemctl commands will query systemd for the state of Apache’s processes.

      On Ubuntu and Debian systems run:

      • sudo systemctl status apache2.service -l --no-pager

      The -l flag will ensure that output is not truncated or ellipsized. The --no-pager flag will make sure that output will go directly to your terminal without requiring any interaction on your part to view it. You should receive output like this:

      Output

      ● apache2.service - The Apache HTTP Server Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled) Drop-In: /lib/systemd/system/apache2.service.d └─apache2-systemd.conf Active: active (running) since Mon 2020-07-13 14:43:35 UTC; 1 day 4h ago Process: 929 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS) Main PID: 1346 (apache2) Tasks: 55 (limit: 4702) CGroup: /system.slice/apache2.service ├─1346 /usr/sbin/apache2 -k start . . .

      To inspect the Apache process on CentOS and Fedora systems run:

      • sudo systemctl status httpd.service -l --no-pager

      You should receive output like this:

      Output

      ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2020-07-14 19:46:52 UTC; 3s ago Docs: man:httpd.service(8) Main PID: 21217 (httpd) Status: "Started, listening on: port 80" Tasks: 213 (limit: 2881) Memory: 16.6M CGroup: /system.slice/httpd.service ├─21217 /usr/sbin/httpd -DFOREGROUND . . . Jul 14 19:46:52 localhost.localdomain httpd[21217]: Server configured, listening on: port 80

      In either case, make a note of the Active line in the output. If your Apache server does not show active (running) as highlighted in the previous examples but you expect it should, there may be an error. Typically if there is a problem, you will have a line like the following in your output (note the highlighted failed portion):

      Example Error Output

      Active: failed (Result: exit-code) since Tue 2020-07-14 20:01:29 UTC; 1s ago

      If there is a problem with your Apache process or configuration you can troubleshoot it further using the journalctl command.

      Journalctl Commands for Apache

      To inspect the systemd logs for Apache, you can use the journalctl command. The systemd logs for Apache will usually indicate whether there is a problem with starting or managing the Apache process.

      These logs are separate from Apache’s request and error logs. journalctl displays logs from systemd that describe the Apache service itself, from startup to shutdown, along with any process errors that may be encountered along the way.

      On Ubuntu and Debian systems use the following command to examine the logs:

      • sudo journalctl -u apache2.service --since today --no-pager

      The --since today flag will limit the output of the command to log entries beginning at 00:00:00 of the current day only. Using this option will help restrict the volume of log entries that you need to examine when checking for errors. You should receive output like the following:

      Output

      Jul 14 20:12:14 ubuntu2004 systemd[1]: Starting The Apache HTTP Server... Jul 14 20:12:14 ubuntu2004 systemd[1]: Started The Apache HTTP Server.

      If you are using a CentOS or Fedora based system, use this version of the command:

      • sudo journalctl -u httpd.service --since today --no-pager

      You should receive output like the following:

      Output

      Jul 14 20:13:09 centos8 systemd[1]: Starting The Apache HTTP Server... . . . Jul 14 20:13:10 centos8 httpd[21591]: Server configured, listening on: port 80

      If there is an error, you will have a line in the output that is similar to the following, with the main difference between Linux distributions being the highlighted yourhostname portion:

      Example Error Output

      Jul 14 20:13:37 yourhostname systemd[1]: Failed to start The Apache HTTP Server.

      If your Apache server has errors in the journalctl logs like the previous example, then the next step to troubleshoot possible issues is investigating Apache’s configuration using the apachectl command line tool.

      Troubleshooting with apachectl

      Most Linux distributions include the apachectl utility with Apache. apachectl is an invaluable tool to help detect and diagnose Apache configuration problems.

      To troubleshoot issues using apachectl, test your Apache configuration using the apachectl configtest command. The tool will parse your Apache files and detect any errors or missing settings before attempting to start the server.

      Run the command like this on Ubuntu, Debian, CentOS, and Fedora based distributions:

      • sudo apachectl configtest

      A working Apache configuration will result in output like the following:

      Output

      Syntax OK

      Depending on your Linux distribution, there may be other lines mixed in with the output, but the important line is the one that says Syntax OK.

      If there is an error in your Apache configuration, like a directive that references a module that is not enabled or even a single typo, apachectl will detect it and attempt to notify you about the problem.

      For example, attempting to use directives for an Apache module that is not enabled will result in apachectl configtest messages like the following:

      Example Error Output

      AH00526: Syntax error on line 232 of /etc/apache2/apache2.conf: Invalid command 'SSLEngine', perhaps misspelled or defined by a module not included in the server configuration Action 'configtest' failed. The Apache error log may have more information.

      In this example the ssl module is not enabled, so the SSLEngine directive generates an error when the configuration is tested. The last line also indicates that The Apache error log may have more information, which is the next place to look for more detailed debugging information.

      Apache Log Files

      Apache log files are a very helpful resource for troubleshooting. Generally, any error that you receive in a browser or other HTTP client will have a corresponding entry in Apache’s logs. Sometimes Apache will also output errors related to configuration, built-in modules, and other debugging information to its log files.

      To examine log files for errors while troubleshooting Apache on a Fedora, CentOS, or RedHat server, examine the /var/log/httpd/error_log file.

      If you are troubleshooting a Debian or Ubuntu derived system, examine /var/log/apache2/error.log for errors using a tool like tail or less. For example, to view the last two lines of the error log using tail, run the following command:

      • sudo tail -n 2 /var/log/apache2/error.log

      Substitute the number of lines that you would like to examine in place of the number 2 in the command. On a CentOS or Fedora system, the log file to examine is /var/log/httpd/error_log.

      An example error will resemble something like the following lines, regardless of which Linux distribution you are using to run your Apache server:

      Error Log Examples

      [Wed Jul 15 01:34:12.093005 2020] [proxy:error] [pid 13949:tid 140150453516032] (13)Permission denied: AH00957: HTTP: attempt to connect to 127.0.0.1:9090 (127.0.0.1) failed [Wed Jul 15 01:34:12.093078 2020] [proxy_http:error] [pid 13949:tid 140150453516032] [client 127.0.0.1:42480] AH01114: HTTP: failed to make connection to backend: 127.0.0.1

      The two lines in this output are distinct error messages. They both reference the module causing the error (proxy in the first line, proxy_http in the second) and include an error code that is specific to the module. The first one, AH00957, indicates that the Apache server attempted to connect to a backend server (127.0.0.1 on port 9090 in this case) using the proxy module but failed to do so.

      The second error is derived from the first: AH01114 is a proxy_http module error that also indicates that Apache was unable to connect to the configured backend server to make an HTTP request.

      These example lines are just for illustration purposes. If you are diagnosing errors with your Apache server, chances are the error lines in your logs will have different contents than these. Regardless of your Linux distribution, the format of any error lines in your logs will include the relevant Apache module and error code, as well as a text description of the error.

      Once you have an idea of what might be causing problems with your Apache server you can continue researching and troubleshooting the issue. The error code and text description are especially useful, since they give you explicit and specific terms that you can use to narrow down the range of possible causes of a problem.

      Conclusion

      Troubleshooting Apache errors can range from diagnosing errors with the service itself, to locating misconfigured options for modules, or to examining customized access control rules in detail. This introduction to diagnosing issues with Apache explained how to use a number of utilities to help narrow down the possible causes of errors. Usually, you will use these utilities in the same order, although you can always skip some, or start directly with examining logs if you have a general idea of what the problem might be.

      However, as a general sequence for troubleshooting, it helps to be methodical and use these tools in the order described. Start troubleshooting with systemctl to examine the state of the Apache server. If you need more information, examine the systemd logs for Apache using the journalctl command. If the issue is still not apparent after checking journalctl, testing Apache’s configuration using apachectl configtest is the next step. Finally, for in-depth troubleshooting, examining Apache’s log files will usually indicate a specific error, with helpful diagnostic messages and error codes.

      The rest of the tutorials in this series will examine some common errors that you may encounter when using Apache in more detail.



      Source link

      Check This Overlooked Setting to Troubleshoot ‘Strange’ Microsoft SQL Server Performance Issues


      As a SQL DBA or a system admin of highly transactional, performance demanding SQL databases, you may often find yourself perplexed by “strange” performance issues reported by your user base. By strange, I mean any issue where you are out of ideas, having exhausted standard troubleshooting tactics and when spending money on all-flash storage is just not in the budget.

      Working under pressure from customers or clients to resolve performance issues is not easy, especially when C-Level, sales and end users are breathing down your neck to solve the problem immediately. Contrary to popular belief from many end users, we all know that these types of issues are not resolved with a magic button or the flip of a switch.

      But what if there was a solution that came close?

      Let’s review the typical troubleshooting process, and an often-overlooked setting that may just be your new “magic button” for resolving unusual SQL server performance issues.

      Resolving SQL Server Performance Issues: The Typical Process

      Personally, I find troubleshooting SQL related performance issues very interesting. In my previous consulting gigs, I participated in many white boarding sessions and troubleshooting engagements as a highly paid last-resort option for many clients. When I dug into their troubleshooting process, I found a familiar set of events happening inside an IT department specific to SQL Server performance issues.

      Here are the typical steps:

      • Review monitoring tools for CPU, RAM, IO, Blocks and so on
      • Start a SQL Profiler to collect possible offending queries and get a live view of the slowness
      • Check underlying storage for latency per IO, and possible bottle necks
      • Check if anyone else is running any performance intensive processes during production hours
      • Find possible offending queries and stop them from executing
      • DBAs check their SQL indexes and other settings

      When nothing is found from the above process, the finger pointing starts. “It’s the query.” “No, it’s the index.” “It’s the storage.” “Nope. It’s the settings in your SQL server.” And so it goes.

      Sound familiar?

      An Often-Forgotten Setting to Improve SQL Server Performance

      Based on the typical troubleshooting process, IT either implements a solution to prevent identical issues from coming back or hope to fix the issue by adding all flash and other expensive resources. These solutions have their place and are all equally important to consider.

      There is, however, an often-forgotten setting that you should check first—the block allocation size of your NTFS partition in the Microsoft Windows Server.

      The block allocation setting of the NTFS partition is set at formatting time, which happens very early in the process and is often performed by a sysadmin building the VM or bare metal server well before Microsoft SQL is installed. In my experience, this setting is left as the default (4K) during the server build process and is never looked at again.

      Why is 4K a bad setting? A Microsoft SQL page is 8KB in size. With a 4K block, you are creating two IO operations for every page request. This is a big deal. The Microsoft recommended block size for SQL server is 64K. This way, the page is collected in one IO operation.

      In bench tests of highly transactional databases on 64K block allocation in the NTFS partition, I frequently observe improved database performance by as much as 50 percent or more. The more IO intensive your DB is, the more this setting helps. Assuming your SQL server’s drive layout is perfect, for many “strange performance” issues, this setting was the magic button. So, if you are experiencing unexplained performance issues, this simple formatting setting maybe just what you are looking for.

      A word of caution: We don’t want to confuse this NTFS block allocation with your underlying storage blocks. This storage should be set to the manufacturer’s recommended block size. For example, as of recently, Nimble storage bock allocation at 8k provided best results with medium and large database sizes. This could change depending on the storage vendor and other factors, so be sure to check this with your storage vendor prior to creating LUNs for SQL servers.

      How to Check the NTFS Block Allocation Setting

      Here is a simple way to check what block allocation is being used by your Window Server NTFS partition:

      Open the command prompt as administrator and run the following command replacing the C: drive with a drive letter of your database data files. Repeat this step for your drives containing the logs and TempDB files:

      • fsutil fsinfo ntfsinfo c:

      Look for the reading “Bytes Per Cluster.”  If it’s set to 4096, that is the undesirable 4K setting.

      The fix is easy but could be time consuming with large database sizes. If you have an AlwaysOn SQL cluster, this can be done with no downtime. If you don’t have an AlwaysOn MSSQL cluster, then a downtime window will be required. Or, perhaps it’s time to build an AlwaysOn SQL cluster and kill two birds with one stone.

      To address the issue, you will want to re-format the disks containing SQL data with 64K blocks.

      Concluding Thoughts

      If your NTFS block setting is at 4K right now, moving the DB files to 64K formatted disks will immediately improve performance. Don’t wait to check into this one.

      Explore INAP Cloud.

      LEARN MORE

      Rob Lerner


      READ MORE



      Source link

      How To Troubleshoot Issues in Redis


      Introduction

      Redis is an open-source, in-memory key-value data store. It comes with several commands that can help with troubleshooting and debugging issues. Because of Redis’s nature as an in-memory key-value store, many of these commands focus on memory management, but there are others that are valuable for providing an overview of the state of your Redis server. This tutorial will provide details on how to use some of these commands to help diagnose and resolve issues you may run into as you use Redis.

      How To Use This Guide
      This guide is written as a cheat sheet with self-contained examples. We encourage you to jump to any section that is relevant to the task you’re trying to complete.

      The commands and outputs shown in this guide were tested on an Ubuntu 18.04 server running Redis version 4.0.9. To obtain a similar setup, you can follow Step 1 of our guide on How To Install and Secure Redis on Ubuntu 18.04. We will demonstrate how these commands behave by running them with redis-cli, the Redis command line interface. Note that if you’re using a different Redis interface — Redli, for example — the exact outputs of certain commands may differ.

      Alternatively, you could provision a managed Redis database instance to test these commands, but note that depending on the level of control allowed by your database provider, some commands in this guide may not work as described. To provision a DigitalOcean Managed Database, follow our Managed Databases product documentation. Then, you must either install Redli or set up a TLS tunnel in order to connect to the Managed Database over TLS.

      memory usage tells you how much memory is currently being used by a single key. It takes the name of a key as an argument and outputs the number of bytes it uses:

      • memory usage key_meaningOfLife

      Output

      (integer) 42

      For a more general understanding of how your Redis server is using memory, you can run the memory stats command:

      This command outputs an array of memory-related metrics and their values. The following are the metrics reported by memory stats:

      • peak.allocated: The peak number of bytes consumed by Redis
      • total.allocated: The total number of bytes allocated by Redis
      • startup.allocated: The initial number of bytes consumed by Redis at startup
      • replication.backlog: The size of the replication backlog, in bytes
      • clients.slaves: The total size of all replica overheads (the output and query buffers and connection contexts)
      • clients.normal: The total size of all client overheads
      • aof.buffer: The total size of the current and rewrite append-only file buffers
      • db.0: The overheads of the main and expiry dictionaries for each database in use on the server, reported in bytes
      • overhead.total: The sum of all overheads used to manage Redis’s keyspace
      • keys.count: The total number of keys stored in all the databases on the server
      • keys.bytes-per-key: The ratio of the server’s net memory usage and keys.count
      • dataset.bytes: The size of the dataset, in bytes
      • dataset.percentage: The percentage of Redis’s net memory usage taken by dataset.bytes
      • peak.percentage: The percentage of peak.allocated taken out of total.allocated
      • fragmentation: The ratio of the amount of memory currently in use divided by the physical memory Redis is actually using

      memory malloc-stats provides an internal statistics report from jemalloc, the memory allocator used by Redis on Linux systems:

      If it seems like you’re running into memory-related issues, but parsing the output of the previous commands proves to be unhelpful, you can try running memory doctor:

      This feature will output any memory consumption issues that it can find and suggest potential solutions.

      Getting General Information about Your Redis Instance

      A debugging command that isn’t directly related to memory management is monitor. This command allows you to see a constant stream of every command processed by the Redis server:

      Output

      OK 1566157213.896437 [0 127.0.0.1:47740] "auth" "foobared" 1566157215.870306 [0 127.0.0.1:47740] "set" "key_1" "878"

      Another command useful for debugging is info, which returns several blocks of information and statistics about the server:

      Output

      # Server redis_version:4.0.9 redis_git_sha1:00000000 redis_git_dirty:0 redis_build_id:9435c3c2879311f3 redis_mode:standalone os:Linux 4.15.0-52-generic x86_64 . . .

      This command returns a lot of information. If you only want to see one info block, you can specify it as an argument to info:

      Output

      # CPU used_cpu_sys:173.16 used_cpu_user:70.89 used_cpu_sys_children:0.01 used_cpu_user_children:0.04

      Note that the information returned by the info command will depend on which version of Redis you’re using.

      Using the keys Command

      The keys command is helpful in cases where you’ve forgotten the name of a key, or perhaps you’ve created one but accidentally misspelled its name. keys looks for keys that match a pattern:

      The following glob-style variables are supported

      • ? is a wildcard standing for any single character, so s?mmy matches sammy, sommy, and sqmmy
      • * is a wildcard that stands for any number of characters, including no characters at all, so sa*y matches sammy, say, sammmmmmy, and salmony
      • You can specify two or more characters that the pattern can include by wrapping them in brackets, so s[ai]mmy will match sammy and simmy, but not summy
      • To set a wildcard that disregards one or more letters, wrap them in brackets and precede them with a carrot (^), so s[^oi]mmy will match sammy and sxmmy, but not sommy or simmy
      • To set a wildcard that includes a range of letters, separate the beginning and end of the range with a hyphen and wrap it in brackets, so s[a-o]mmy will match sammy, skmmy, and sommy, but not srmmy

      Warning: The Redis documentation warns that keys should almost never be used in a production environment, since it can have a major negative impact on performance.

      Conclusion

      This guide details a number of commands that are helpful for troubleshooting and resolving issues one might encounter as they work with Redis. If there are other related commands, arguments, or procedures you’d like to see outlined in this guide, please ask or make suggestions in the comments below.

      For more information on Redis commands, see our tutorial series on How to Manage a Redis Database.



      Source link