On Oct 10, 2019, at 10:25 AM, Kirk Brooks wrote: > The other thing about VM vs metal is the whole pre-emptive process > benefit basically goes away. Thomas Maul has shown this at the Summit. > Having n+ virtual cores doesn't do anything to actually increase processing > speed because the VM is running on whatever is allocated to it. > Theoretically you could have a VM with 4 cores running an instance with 32 > cores. So preemptive threading is looking to be mainly a benefit for > companies that run their own hardware and for desktop apps.
I was not aware of this. So what you are saying is that if you are deploying 4D Server in a VM there is not need to try and use preemptive mode. You get no benefit from doing that. It’s a waste of time? Sounds like a giant bummer. Hope you are wrong. I’ll put in the secret distress call code “JPR" in this message and see if JPR catches this and knows anything about this and can comment. If not, I’m going to make it a point to ask one of the Laurents about this at 4D Summit so I’m clear on when you get preemptive benefits. Do you get any when running 4D Server or 4D Client in a VM? As you know I love running 4D Server in a VM environment that is properly configured on great hardware. Performance is great for 4D Server and for 4D Client instances. And when you need more disk space you can get it in a few minutes by just altering some VM parameters. Same for adding more RAM, just takes a few minutes and a reboot. And since the disks are all allocated from a SAN that is RAID “whatever” you don’t have to worry about a disk failure and losing data. RAID will protect you from that. And putting the .4dd on a separate physical disk than the .journal file can’t be done and is not a consideration for providing additional protection from hardware failure. The last part of fault tolerance and recover from failures is to implement “Volume Shadow Copy” and get a snapshot of the machine. I have another client that does this every hour. So if the VM goes completely bad you can restore it back to what it was up to 1 hour ago. That brings drive “C:\” back to where it was. And if your data file is on “D:\” it is stored on the SAN “hard drives” so it is suppose be accurate and good up to the last operation. This is what I am told. That last thing I tell myself when running 4D in a VM environment is that server hardware failure and disaster recover is not longer my problem. It’s the IT department’s problem. I’m just providing a 4D Server application that runs on their “machine”. I didn’t set up or configure the “machine”. I didn’t implement the backup plan or strategy. Everything depends on IT doing it right and providing an environment that can recover from hardware failures. In the past I was very involved with server hardware setup and configuration and backups, and so this was another of my “worries” or considerations. Did we buy enough RAM. Did we get enough hard drive space and are we using the drives the right way. Is the backup software running and working. And if there was a problem or failure I was the first one called to help fix it. That’s all gone when 4D Server is running in a VM. It’s all someone else’s problem. All I have to say is “when you get the VM restored and online again, let me know. I’ll check 4D Server and see if we lost any data.” I like it that way. Tim ***************************************** Tim Nevels Innovative Solutions 785-749-3444 [email protected] ***************************************** ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
