@masterarts said in Wordpress on Vultr 768:
I think you need a larger Vultr server for better performance. Cloudways super fast managed Vultr hosting servers are one clicked managed. You can get any help from their live chat support.
Why would I pay more for a server that has less resources per dollar than what Vultr offers directly?
I'm legitimately asking the question, as I have done zero research on Cloudways.
@scottalanmiller said in Wordpress on Vultr 768:
@fuznutz04 said in Wordpress on Vultr 768:
@scottalanmiller said in Wordpress on Vultr 768:
Good reading, as well: http://www.smbitjournal.com/2011/02/why-we-reboot-servers/
A little modern design can get that to zero downtime no problem.
Sure thing, but that would have been a huge undertaking in regards to how applications were written/designed. Starting fresh, no question.
@scottalanmiller said in Wordpress on Vultr 768:
Good reading, as well: http://www.smbitjournal.com/2011/02/why-we-reboot-servers/
I used to work for a business that hosted a CMS as well as hundreds of websites and email hosting. Clients were all across the globe, so nightly restarts as well as weekend updates were out of the question. The best time to patch and reboot was Thursday nights, once a month. Having a web farm, or database farm would have reduced overall downtime, but in the end, it wasn't too bad. a couple minutes of downtime per server at the most isn't bad once a month in my opinion. Patching hosts were done less frequently, but that involved zero downtime, as all VMs were migrated to other nodes during the update.
@scottalanmiller said in Wordpress on Vultr 768:
Read that one already 
Couldn't agree more. There have been more than once where I've heard stories of new IT guys going into a new roll, not rebooting a server, and finds out months down the road after an extended power outage, that the server will not come back online.
@scottalanmiller said in Wordpress on Vultr 768:
@fuznutz04 said in Wordpress on Vultr 768:
@scottalanmiller said in Wordpress on Vultr 768:
Don't forget to set up your update and reboot schedule now.
Would love to hear a best practice / how-to for this. Any suggestions?
There isn't a strict best practice, or if there is it is really complex to state. But as a "guideline" you want reboots rather often. Weekly is generally best, monthly at the longest.
What NTG does, which I think is pretty good, is that we use constant updates via the yum-cron tool or similar. This does a random patching cycle several times per day which helps to keep load to a minimum at any given time. We run 24x7 so this is great for us. If you run 8-5, for example, you might want to schedule a known patch time at 6:37 daily (avoid hard five and ten minute intervals, especially quarter, half and full hours).
If your server is truly idle daily, reboot daily! Why not. Most shops have a good window each week for a reboot. NTG does late Friday night for some workloads. And early Sunday morning for others (specifically phone and monitoring.) We are strategic about when different workloads will be in use. For example, ScreenConnect might remain busy on Friday evening, so we don't reboot it then but rather during a meeting or something.
Great info, thanks. I have a few boxes serving multiple functions such as web, logging, etc, and a good number running a PBX OS of some sort. Right now, I manually restart everything, including the PBXs, because the number of servers are small, but I fully realize that this won't scale properly. Do you follow the same schedule for PBX distros? Do you schedule cron locally at each server, or from a central point using a tool?
@scottalanmiller said in Wordpress on Vultr 768:
Don't forget to set up your update and reboot schedule now.
Would love to hear a best practice / how-to for this. Any suggestions?
So reinstalling CentOS7, then installing the LAMP stack, followed by Wordpress, seems to have solved my issues. No issues like I was having earlier. Also, I have much more available memory than what i had previously. Strange problem.
@JaredBusch said in Windstream and Earthlink to merge:
@David.Scammell said in Windstream and Earthlink to merge:
@scottalanmiller said in Windstream and Earthlink to merge:
@RojoLoco said in Windstream and Earthlink to merge:
So will the resulting company be called Windlink or Earthstream?I think it is clear that their next acquisition will be Firehost.
And finally, after they merge with NanoH2O, they will hire Captain Planet as their new CEO.
Brought back memories...I had to listen to the entire song.
The question is...is it even possible for Windstream to get any worse?
@dafyre Exactly. Didn't want to waste any more time on it, especially since it was still in testing/setup stages.
I "fixed it" by reinstalling. Now I'm in the process of setting up LAMP and then Wordpress again.
Oh look, I fixed it!
(throws hands up and reinstalls.)
@momurda said in Wordpress on Vultr 768:
Just a bit of browsing I find this. You do actually seem to be out of memory, try adding
performance_schema = offto the [mysqld] section of my.cnf
No go. Same result, same errors
@scottalanmiller Yikes! that happened to me a few months ago. I quick ran to the hardware store and bought another submersible sump pump.
@momurda said in Wordpress on Vultr 768:
@fuznutz04
I think there should be a bit more lines in that file.
What size files are the recreated innodb files?
What is the contents of /var/log/mariadb/mariadb.log
5242880 bytes is the size of the new files.
Seems like I'm in a time warp, as it is warning me that my sequence numbers are in the future!
161107 12:17:20 InnoDB: Waiting for the background threads to start
161107 12:17:20 InnoDB: Error: page 348 log sequence number 133743653
InnoDB: is in the future! Current system log sequence number 107618964.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: for more information.
161107 12:17:21 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
So following the directions to force innodb into recovery mode, the DB starts, but then the logs say this:
InnoDB: A new raw disk partition was initialized or
InnoDB: innodb_force_recovery is on: we do not allow
InnoDB: database modifications by the user. Shut down
InnoDB: mysqld and edit my.cnf so that newraw is replaced
InnoDB: with raw, and innodb_force_... is removed.
InnoDB: A new raw disk partition was initialized or
InnoDB: innodb_force_recovery is on: we do not allow
InnoDB: database modifications by the user. Shut down
InnoDB: mysqld and edit my.cnf so that newraw is replaced
InnoDB: with raw, and innodb_force_... is removed.
InnoDB: A new raw disk partition was initialized or
InnoDB: innodb_force_recovery is on: we do not allow
InnoDB: database modifications by the user. Shut down
InnoDB: mysqld and edit my.cnf so that newraw is replaced
InnoDB: with raw, and innodb_force_... is removed.
161107 12:34:37 mysqld_safe Number of processes running now: 0
161107 12:34:37 mysqld_safe mysqld restarted
161107 12:34:40 [Note] /usr/libexec/mysqld (mysqld 5.5.50-MariaDB) starting as process 11049 ...
161107 12:34:40 InnoDB: The InnoDB memory heap is disabled
161107 12:34:40 InnoDB: Mutexes and rw_locks use GCC atomic builtins
161107 12:34:40 InnoDB: Compressed tables use zlib 1.2.7
161107 12:34:40 InnoDB: Using Linux native AIO
161107 12:34:40 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137756672 bytes) failed; errno 12
161107 12:34:40 InnoDB: Completed initialization of buffer pool
161107 12:34:40 InnoDB: Fatal error: cannot allocate memory for the buffer pool
161107 12:34:40 [ERROR] Plugin 'InnoDB' init function returned error.
161107 12:34:40 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
161107 12:34:40 [ERROR] mysqld: Out of memory (Needed 128917504 bytes)
161107 12:34:40 [Note] Plugin 'FEEDBACK' is disabled.
161107 12:34:40 [ERROR] Unknown/unsupported storage engine: InnoDB
161107 12:34:40 [ERROR] Aborting
@momurda said in Wordpress on Vultr 768:
Have you checked to see if these files exist and are correct size? Have you checked the .cnf file
InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
InnoDB: than specified in the .cnf file 0 8388608 bytes!Check your cnf file to see that it is correct. Rename/move ib_logfile0, ib_logfile1 (they'll get recreated when the service starts again)
I renamed and started the service again, and the files were re-created. The site is online for a few seconds then crashes again. I'm not seeing any configuration file other than /etc/my.cnf, and the file only has a few lines of code in it.
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# Settings user and group are ignored when systemd is used.
# If you need to run mysqld under a different user or group,
# customize your systemd unit file for mariadb according to the
# instructions in http://fedoraproject.org/wiki/Systemd
[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid
#
# include all files from the config directory
#
!includedir /etc/my.cnf.d
The files in /etc/my.cnf.d have almost nothing in them as well.
@scottalanmiller Yeah, that didn't fix it. I'll just start over. I recall discussion on here previously that the "one click" installs of Wordpress on Vultr are not recommended. I couldn't remember (or find the discussion) why this was the opinion...
@scottalanmiller said in Wordpress on Vultr 768:
@fuznutz04 said in Wordpress on Vultr 768:
@scottalanmiller said in Wordpress on Vultr 768:
I see, so this has been running for a while and only recently started having the problem? It seems like InnoDB is having an issue registering as an engine.
Yes, it was runnning fine for at least a week, then I abandoned it for a few months, and recently revisited and started having these issues.
Oh, you hurt it's feelings. That's a standard problem. Talk nice to it for a while.
Could be. It's not a HUGE deal, as I can just blow it away and start over, but it would be nice to find out what's going on for if/when it happens again
@scottalanmiller said in Wordpress on Vultr 768:
I see, so this has been running for a while and only recently started having the problem? It seems like InnoDB is having an issue registering as an engine.
Yes, it was runnning fine for at least a week, then I abandoned it for a few months, and recently revisited and started having these issues.