RT 5.0.8 and 6.0.0 minimum system requirements
We’re running 4.4.4 on a Standalone Server VM instance with the following extensions installed: RTIR, MandatoryOnTransition and Automatic Assignment and we’re using nginx version: nginx/1.16.1
The system was installed in August 2019 and our current size is as follows:
Tickets - 641838
Queues - 85
Transactions - 11520665
PrivilegedUsers - 245
UnprivilegedUsers - 19219
Current System Specs
CPU: 8 cores
Memory: 16GB
Disk: 578GB
Disk Used: 486GB (67GB Free)
Can someone please guide me on how much more power I would need to request for our new VM instance if we want to upgrade to 5.0.8 or 6.0.0? I am actually a front-end GUI Admin of RT and we don’t actually have a dedicated developer. The system was installed by a DevOps guy who left years ago leaving the front-end Ops team (i.e. Me) in charge of everything with very little help from my friends. Amazingly, it’s been purring along happily but we have to get her upgraded so I’m trying to research the upgrade process so I can drive the project. I’d really appreciate some guidance. Thanks.
I would think it’ll be about the same. I’m fairly sure the move to HTMX will make a few more queries from the client to the server, but … If you’re using a VM, then hopefully it’ll be trivial to add CPUs or RAM if you need it.
Given the amount of disk space you have assigned it sounds like you have the database in the same VM. I’d personally run the DB in a different VM.
I’d recommend taking a copy of the database and restoring into a test environment so you can make sure things work okay.
Thanks Andrew. Seperating the DB was recommended to us years ago but due to various internal constraints (budget and no skilled RT resources) we weren’t able to follow through with it. We also couldn’t look to BP because we’re in South Africa and the exchange rate made the costs very high for us. So, if we are doing this thing then this time I want it done right first time. I am a little nervous about moving straight to 6.0.0 right now since we need the RTIR as well and it’s not ready yet so I’m leaning toward the stable 5.0.8.
Please would you clarify one more thing for me? Considering that we are now going to spread the load between two servers and as you correctly pointed out once we move the servers to Production we can easily increase the resources in both VMs. How much would you allocate (CPU, Memory and Disk) to each server (Main and DB) for our Test VMs? The disk space question applies mainly to the Main RT Server, for the DB we will have to assess our current size and leave some headroom.
One thing to point out is that in moving from 4.x to 5.x you’ll temporarily need at least twice the amount of disc space (I think we ended up 3x IIRC - it was a good while ago!) , because the upgrade mechanism converts the existing tables to handle internationalised character sets better. You’ll probably want a test VM anyway with a read only copy of your database so that you can run through the migration several times to make sure everything works and you know what you’re doing before you hit your live server upgrade (top tip: don’t have a mail transfer agent such as exim or sendmail running on that one so that you don’t accidentally send out any emails! ).
Thanks Jim! Considering that we are going to have RT installed on one VM and our DB on another. How much disk space will the RT VM itself need? It’s hard for me to get an idea because everything is all in one server at the moment.
Also, which server will work harder and need more CPU and Memory, the main RT Server or the DB Server?
Thanks for the tips, I will be proceeding with utmost caution as instructed
Our live service is all on one VM too, so I can’t tell the you relative load of the database engine and the web front end I’m afraid. I’d guess that the database is doing most of the grunt work though and the web front it is just massaging Mason files and data to give to the user (simplification there to annoy the Best Practical devs!). Certainly the database can suck up CPU cycles if someone gives it a pathological TicketSQL search as we’ve seen in the past.
I’d think if you’re just hosting the web server, RT code and logs on one server that probably won’t need much disc space. You’ll probably be mostly driven by the size of the logs and how long you want to keep them for (which will depend on your usage patterns and how much logging you do for debugging, etc).
“Certainly the database can suck up CPU cycles if someone gives it a pathological TicketSQL search as we’ve seen in the past.”
Someone on our team configured a Custom Field used over several of our Queues as “New values must be unique” by mistake and it caused performance chaos on our server. We chased our tails for ages finding the root cause on that one.
).