@NetworkNerd

1. Identify the Cause of High Disk IO and CPU Wait MariaDB Activity: Since mariadb is showing high IO during the problematic window, it's crucial to identify the queries causing this load. You can enable the slow query log in MariaDB to capture queries that are taking an unusually long time to execute. Scheduled Tasks: Check for any scheduled tasks (cron jobs) on the server that run around 5 AM CST. These could be system tasks, WordPress cron jobs, or database maintenance tasks. 2. Systemd-journald Failure The failure of systemd-journal-flush.service suggests that the journaling system is overwhelmed, likely due to the high IO load. Investigate the journal logs (journalctl) for any errors or warnings that occur around this time. 3. Review WordPress Plugins and Activities Plugin Behavior: Even though plugins like Updraft Plus are scheduled for different times, they might be triggering background tasks. Verify plugin behavior and logs. WordPress Cron: WordPress has its own cron system (wp-cron.php) that can sometimes trigger resource-intensive tasks. Review the WordPress cron events. 4. Server and Database Optimization Database Optimization: Run a check and optimization task on your MariaDB database. Over time, databases can become inefficient and slow. Upgrade Resources: An e2-micro instance is quite limited in resources. If this issue is related to resource constraints, consider upgrading the VM instance type. 5. Monitoring and Logs Enable Enhanced Monitoring: Tools like sar, iotop, or atop can provide in-depth system metrics. Make sure they are configured correctly. Access and Error Logs: Review NGINX, PHP-FPM, and MariaDB logs for any anomalies during the problematic time frame. 6. External Factors Traffic Spikes: Although Jetpack stats show low traffic, consider checking the access logs for unexpected traffic spikes, which might be bots or crawlers. Network Analysis: Use tools to monitor network activity. Unexpected external connections might be contributing to the load. 7. Testing and Isolation Isolate Components: Temporarily disable certain components or plugins during the problem window to see if the issue persists. Test in a Staging Environment: If possible, replicate the setup in a staging environment to test without affecting the live site.

@Pete-S said in WordPress Site Lost Its Mind - Ten Minutes of Maintenance Over and Over Again:

This is how you do that:
https://developer.wordpress.org/plugins/cron/hooking-wp-cron-into-the-system-task-scheduler/

Nice, good info. Thanks.

So one of our guys tracked it down. It was a typo in the .htaccess file that we received from the customer.

You can trying using auditd to audit the file.

sudo apt-get install auditd

Running sudo auditctl -l by default show no rules

Create a temporary rule to audit changes to index.php

sudo auditctl -w /var/www/html/index.php -p rwxa # -p = read, write, execute, attributes

Run sudo auditctl -l will show the rule that was created.
Now run sudo ausearch -f index.php | more to show what's touching index.php
or sudo tail -f /var/log/audit/audit.log | grep index.php.

What about using Ghost? I started with it before moving to Wordpress. It is completely markdown if I remember right. I liked it but didn't feel the plugin availability was there.

This is the SSL score.
76a95c9d-98c9-4017-b1a5-9241f011403e-image.png

I assume this is why the A rating and not A+
c8606068-aa33-4e47-ac08-12495d504b90-image.png

But not much to do about that since it is Cloudflare that is terminating.

thanks. missed that

@JaredBusch yeah, it's annoying that WP-CLI struggles with that.

I've seen that a lot. When I import Drupal databases, I learnt to use its Backup and Migrate module instead, it works flawlessly. Downside is you need to do clean Drupal installation first, but that basically is just creating blank database and putting brick on enter key.

@JaredBusch said in WP-CLI and database users:

@Pete-S said in WP-CLI and database users:

@JaredBusch said in WP-CLI and database users:

@Pete-S said in WP-CLI and database users:

And when you use -e you should have it after user and password so the SQL commands you want to execute comes after the -e.

That was a once off artifact of me doing it on this system after the root password has been set.

OK, so maybe this then:

sudo mysql -e "CREATE USER $DB_USER@localhost IDENTIFIED by '$DB_PASS';" sudo mysql -e "GRANT ALL ON $DB_NAME.* TO $DB_USER@localhost;" sudo mysql -e "FLUSH PRIVILEGES;"

right. Updating the guide. but half tempted to leave the single quotes everywhere it that causes no error in order to protect against spaces by others. Though I am using pwgen to to this.

It's kind of f*cked up to have spaces in user names and passwords. Personally I don't use something unless it's specifically needed but either way works.

@Obsolesce said in Wordpress Theme Recommendations:

@scottalanmiller said in Wordpress Theme Recommendations:

@Obsolesce said in Wordpress Theme Recommendations:

@Dashrender said in Wordpress Theme Recommendations:

We use DIVI - but I'm not saying it's good or bad as I've never used another.. or WP plain.

DIVI?

Divi purports to be the most popular theme on WP. It's definitely popular and seems to do a lot and has decent licensing rules. But is pricey, too.

Oh, I googled it and seen so many other things lol. I haven't heard of it before so I wasn't sure what I was looking for.

it adds a ton to WP - including a wsyiwyg editor (if you want to use it), etc..

Turns out that there was a wildcard A record in DomainA2.com

@IRJ said in Remove Social Media Icons like Google+ from Flawless Wordpress Theme by Goodlayers:

Maybe just dump that bad theme all together.

I'd love to, but I just host the site and help out a little.

@IRJ You are passionate about computers, you love to write code. Well, what's more exciting than being able to create your own plugins.

When you know that WordPress is today one of the most used CMS on the web, it would be really interesting to see how a plugin is made and to be able to create it yourself. [Check it here] (http://bit.ly/2KxPChJ)

We got it. Had to open the Nginx logs and noticed too many "posts" in the error log. Dug in and it was three ranges overseas all hitting with a "post timeout attack." It was a light DDoS where sessions were being opened and held causing nginx to wait on a timeout. This caused Apache to just increment forever. Once we blocked those ranges, the Apache thread count started to drop for the first time, and memory started to release. And the continuous flood of nginx error logs ceased.

If you are looking at nginx error logs, this is what you look for: upstream timed out (110: Connection timed out) while reading response header from upstream, client:

You can use this command to collect the offending IP addresses:

grep "upstream timed out" error.log | cut -d' ' -f20

Then use your firewall to shut them down. We are all good now! Woot.

Well let's talk about fedora and updating killing a laptop lol....

@black3dynamite said in If Not WordPress, What's the Alternative:

@scottalanmiller said in If Not WordPress, What's the Alternative:

@360col said in If Not WordPress, What's the Alternative:

Well if the site is not complex then something like Grav these days is much better IMHO

I've been eyeing Grav for a while. It does look very interesting. ANy guesses as to pros and cons vs. WordPress? Beyond the obvious flat file vs database differences...

Ever since discovering Wiki.js, I like the idea of using git for versioning backups and deployments.
https://github.com/trilbymedia/grav-plugin-git-sync

You can automate backups of the MariaDB, though. Not all that much different. Lighter, on big loads. GIT is actually a very heavy process. Great for tiny things, but bad for big ones.