thoughts on the new server

Y’all may remember the server that ran the bdp wordpress blog instance, personal website, the rvwiki and various other doodads was EOL by my virtual server provider. I actually had a few services running with them and decided to consolidate them when I was forced to the new server.

**old setup on Frantech/BuyVM**	**new setup on Flaunt7**
512MB [OpenVZ](https://en.wikipedia.org/wiki/OpenVZ) Debian linux [VPS](https://en.wikipedia.org/wiki/Virtual_private_server), 30GB drive, "fair share" of multiple cores (ie, don't be a jerk with the CPU) 128MB OpenVZ Debian linux virtual, 10GB drive, "fair share" cpu. offloaded MySQL database service, which I was using for some projects and as the backend for the BDP wordpress.	1GB [KVM](https://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine) Debian linux virtual, 30GB drive, 0.5 core.

The cost for both setups is right at $60/yr.

Backstory: when I first signed up with Frantech they had both OpenVZ and KVM virtual private server platforms available, and the OpenVZ cost less. Frantech announced they wanted to phase out the OpenVZ option to make their lives easier, (I have no problem with that). I would have stuck with them but at the time they didn’t have a KVM slots open how and where I wanted it. So I hopped to someone who did. It was a logistics thing moreso than a commentary on Frantech vs. the competition.

relative performance

The “half a core” thing might seem to hamstring the new setup, but I don’t do much real-time CPU heavy lifting. The most CPU-intensive thing I do there is re-encode podcasts to lower-bitrate .ogg files to reduce bandwidth, and that runs “nice -19” (idle cycles only) in the background anyhow – I’m not watching it run. My mosh/ssh sessions are pretty laggy anyhow due to my dependence on cellular data.

The main bottlenecks I was experiencing on the old setup was processes killed when they ran out of RAM on the 128MB instance, something that had only started in the last 6mos. And increasing instability on both instances that required tickets to rectify. So the new setup is an improvement on both fronts.

So while CPU-intensive actions like distribution updates can sometimes take noticeably longer I find the new setup easier to maintain and work with. Multiple detached tmux sessions can be doing their thing in the background without getting memory-starved. The server idles along most of the time: