Wordpress on Vultr 768
-
@fuznutz04 said in Wordpress on Vultr 768:
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.
Too bad we didn't have more time to delve into it.
-
Don't forget to set up your update and reboot schedule now.
-
@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?
-
@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.
-
@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?
-
@fuznutz04 said in Wordpress on Vultr 768:
@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?
I've done both, different strokes for different folks (or situations). At NTG we use local cron. I like local cron whenever possible because it has the benefits of essentially zero overhead and dependencies and in those cases where other things, like networking, fail it will go ahead and reboot anyway potentially fixing itself without intervention!
-
@scottalanmiller Yes! The magic of reboot!
-
Good reading, as well: http://www.smbitjournal.com/2011/02/why-we-reboot-servers/
-
@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. -
@fuznutz04 said in Wordpress on Vultr 768:
@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.That's what killed IBM in the big Australian voting project a few weeks ago. Zero reboots... ever.
-
@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.
-
@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/
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.
A little modern design can get that to zero downtime no problem.
-
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.
-
@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.
-
@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.
-
Just as a note, I've run a Drupal site on the minimal Vultr instance and it was fine. However it was LEMP (NGINX not Apache). Def wasn't super busy but it did fine.
-
@stacksofplates said in Wordpress on Vultr 768:
Just as a note, I've run a Drupal site on the minimal Vultr instance and it was fine. However it was LEMP (NGINX not Apache). Def wasn't super busy but it did fine.
Good to know. So far, performance is much better since re-install. And memory usage is far better.
-
@fuznutz04 said in Wordpress on Vultr 768:
@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.
Would it? What are you running that wouldn't do that today? Wordpress will sure do that.
-
@scottalanmiller said in Wordpress on Vultr 768:
@fuznutz04 said in Wordpress on Vultr 768:
@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.
Would it? What are you running that wouldn't do that today? Wordpress will sure do that.
Well, my comment was based on what the developers were telling me back then. Specifically, the way the websites (IIS & .NET) and databases (MS SQL) handle individual user "sessions". I'm not saying it couldn't be done, but it was more effort and development time than what the company was willing to invest in at that point in time.
-
@fuznutz04 said in Wordpress on Vultr 768:
@scottalanmiller said in Wordpress on Vultr 768:
@fuznutz04 said in Wordpress on Vultr 768:
@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.
Would it? What are you running that wouldn't do that today? Wordpress will sure do that.
Well, my comment was based on what the developers were telling me back then. Specifically, the way the websites (IIS & .NET) and databases (MS SQL) handle individual user "sessions". I'm not saying it couldn't be done, but it was more effort and development time than what the company was willing to invest in at that point in time.
Oh, the developers screwed up and made a bad application that can't scare properly and then got stuck because scaling and transparent updates are done in the same way. Got it.
But for WordPress, it "just works."
