Solving the sigwinch Problem and Optimizing My Web Server for the WordPress E commerce Website

By /


WordPress ecommerce website can be both rewarding and challenging. Recently, I faced an unexpected problem with my Apache web server: this sigwinch was shut down with grace after receiving the signal. It was causing downtime and disrupting my online store.

In this blog post, I will explain what this issue was, how I resolved it, and the steps I took to customize my web server for better performance.


Problem: Sigwinch Signal Shut Down Apache What is SIGWINCH?
Sigwinch (signal window change) is a signal sent to a process when it is running in the terminal window. Although this sign is generally harmless, it became problematic to my Apache web server as it was being interpreted as a command to close it with grace.


Why Was This Happening?
In the investigation, I realized that Apache was running in a terminal session rather than a background service. When the terminal window was shaped, the Sigwinch Signal was sent to Apache, which unpredictably closed.


How I Resolved the SIGWINCH Issue

Step 1: Running Apache as a Background Service To prevent Apache from being affected by the terminal signal, I configured it to run as a background service using systemd. Here’s what I did:

  1. Stop Apache if it is running in the terminal:
    sudo apachectl stop
  2. Start Apache as a service:
    sudo systemctl start apache2
  3. Enable Apache to start automatically on boot:
    sudo systemctl enable apache2


This ensured that Apache moved independently of any terminal session, ending the issue of Sigwinch.

Step 2: Reviewing Apache Log
I checked the Apache error log to confirm that the sigwinch signal was the root cause. The log files are located at:

  • /var/log/apache2/error.log (Debian/Ubuntu)
  • /var/log/httpd/error_log (CentOS/RHEL)

The logs confirmed that Apache was shutting down gracefully after receiving the SIGWINCH signal.

Step 3: Fix Test
After making these changes, I tested the server by shaping the terminal window and monitoring Apache’s behavior. The server remained stable, confirming that the problem was solved.

Adaptation of My Web Server for Better Performance
After solving the Sigwinch issue, I took the opportunity to customize my web server for better performance. Here’s what I did:

  1. Tuning Apache Configuration
    I updated the Apache configuration file (/etc/apache2/apache2.conf) to optimize performance for my 4GB RAM server. Here is the configuration I used:
<IfModule mpm_prefork_module>
    StartServers          4
    MinSpareServers       4
    MaxSpareServers       8
    MaxRequestWorkers     150
    MaxConnectionsPerChild   10000
</IfModule>

Timeout 60
KeepAlive On
KeepAliveTimeout 5

I also enabled essential Apache modules: 

sudo a2enmod rewrite expires headers cache deflate 
sudo systemctl restart apache2
  1. Enabling PHP Opcode Caching

    To improve PHP performance, I installed and configured OPcache:

    Installed OPcache:

    sudo apt install php-opcache

    Updated the PHP configuration file (/etc/php/8.1/apache2/php.ini):


    opcache.enable=1 opcache.memory_consumption=128 opcache.max_accelerated_files=10000 opcache.revalidate_freq=60
  2. Setting a Caching Plugin

    I installed WP Super Cache on my WordPress site to generate static HTML files and reduce server load. I also configured browser caching and optimized CSS/JS files.
  3. Optimizing the Database

    I used the WP-Optimize plugin to clean and customize my WordPress database. Additionally, I tuned MySQL/MariaDB settings for better performance:
[mysqld]
innodb_buffer_pool_size = 1G
innodb_log_file_size = 256M
query_cache_type = 1
query_cache_size = 64M
max_connections = 200

  1. Enabling Gzip Compression

    I enabled Gzip compression in Apache to reduce file sizes and improve load times:
<IfModule mod_deflate.c> 
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/javascript application/x-javascript 
</IfModule>
  1. Monitoring Server Performance I set up monitoring tools such as HTOP and Google PageSpeed Insights to track server performance and identify bottlenecks.
  2. Securing the Server Finally, I secured my server:
  • Installed a firewall (UFW).
  • Configured the SSL certificate using Let’s Encrypt.
  • Kept all software updated.

Results
After solving the Sigwinch issue and optimizing my server, I saw significant improvements:

  • Stability: No unexpected shutdowns.
  • Performance: Faster page load times and better handling of traffic spikes.
  • Scalability: My server is now ready to handle increased traffic as my ecommerce business grows.

Key Learnings

  1. Run important services like Apache as background processes to avoid interference from terminal signals.
  2. Regularly monitor server logs to identify and resolve issues.
  3. Optimize server configurations to ensure smooth performance, especially for resource-intensive ecommerce applications.

If you’re facing similar issues or want to optimize your web server, feel free to reach out or follow the steps outlined in this post. Happy hosting!

Scroll to Top