3 ms·

> The entire scenario outlined is for a production deployment of Websphere backed by Oracle. IBM specifically calls out 1:1 memory for production workloads (whi

> The entire scenario outlined is for a production deployment of Websphere backed by Oracle. IBM specifically calls out 1:1 memory for production workloads (which oracle very much is) in their performance documentation: This discussion is about the configuration of the systems, not this specific scenario. While this may have been the scenario outlined for you, it wasn't apparent from your comment. Production workloads on busy servers have very different requirements than consolidation, VDI, resiliency/redundancy, hardware abstraction, etc. Every workload needs a different evaluation. All of these VMs running production Ora/OAM/OEM/Websphere workloads? No, don't oversubscribe. Some of them running similar workloads? More oversubscribe is ok. Few of them? Lots of oversubscribe. Similar for interrupt locking. The "old" synchronous interrupt lock I was speaking about was "I have a bunch of VMs with CPU oversubscribe, and even if they're doing nothing, 30% or more of your CPU time goes to interrupt scheduling so every vCPU for a given VM can schedule simultaneously". This is solved. "I'm running a CPU-intensive workload on a massively oversubscribed server" is not, and we really shouldn't expect it to be. I am having a generalized discussion about virtualization oversubscribe. You are having a specific discussion about CPU-heavy DB workloads. Apples cannot be compared to oranges.

tw04 5y ago
I guess you can move the goal posts now, but it should have been exceedingly clear that I was commenting on the workload in the link, because I'm replying to the link. My outline of hardware is the hardware in the link, I didn't just make up an imaginary scenario. Literally everyone else in the thread is commenting on the link, you appear to be the only one confused about what we're talking about. >All of these VMs running production Ora/OAM/OEM/Websphere workloads? No, don't oversubscribe. Some of them running similar workloads? More oversubscribe is ok. Few of them? Lots of oversubscribe. All of the VMs are running Oracle/Websphere/Apache, per the link. That is what the article is recommending, which is where my skepticism came and is coming from. >I am having a generalized discussion about virtualization oversubscribe. You are having a specific discussion about CPU-heavy DB workloads. Apples cannot be compared to oranges. Everyone in this thread is talking about the article, I guess everyone but you.
- evol262 5y ago
  If those were goalposts, they weren't clear. The miss is that the article in the link doesn't discuss VMs or virtualization at all, so talking about oversubscription/etc seemed like an ad-hoc commentary on the hardware configuration unless I totally missed that in the article, but searching for "virtual", "VM", "vCPU", "subscribe", etc didn't find anything. There's a limited amount of effort I'm gonna put into digging into additional links on "Planet Mainframe" pushing mainframes. That aside, comments on articles are sometimes more general. "How do mainframes compare in 2021?" is a conversation which is not intrinsically linked to "should you oversubscribe VMs 66:1 for this specific workload?", and I interpreted your comment at the former. I wasn't talking about the article at all.
  - tw04 5y ago
    > The miss is that the article in the link doesn't discuss VMs or virtualization at all, so talking about oversubscription/etc seemed like an ad-hoc commentary on the hardware configuration unless I totally missed that in the article There is a giant table in the middle of the article that is impossible to miss if you read it. It literally says # of VMs. As well as calling out VMware, and z/VM as tye hypervisors in use. The oversubscription is a simple math problem, and that's assuming best case scenario.

tw04 5y ago

I guess you can move the goal posts now, but it should have been exceedingly clear that I was commenting on the workload in the link, because I'm replying to the link. My outline of hardware is the hardware in the link, I didn't just make up an imaginary scenario. Literally everyone else in the thread is commenting on the link, you appear to be the only one confused about what we're talking about. >All of these VMs running production Ora/OAM/OEM/Websphere workloads? No, don't oversubscribe. Some of them running similar workloads? More oversubscribe is ok. Few of them? Lots of oversubscribe. All of the VMs are running Oracle/Websphere/Apache, per the link. That is what the article is recommending, which is where my skepticism came and is coming from. >I am having a generalized discussion about virtualization oversubscribe. You are having a specific discussion about CPU-heavy DB workloads. Apples cannot be compared to oranges. Everyone in this thread is talking about the article, I guess everyone but you.

evol262 5y ago
If those were goalposts, they weren't clear. The miss is that the article in the link doesn't discuss VMs or virtualization at all, so talking about oversubscription/etc seemed like an ad-hoc commentary on the hardware configuration unless I totally missed that in the article, but searching for "virtual", "VM", "vCPU", "subscribe", etc didn't find anything. There's a limited amount of effort I'm gonna put into digging into additional links on "Planet Mainframe" pushing mainframes. That aside, comments on articles are sometimes more general. "How do mainframes compare in 2021?" is a conversation which is not intrinsically linked to "should you oversubscribe VMs 66:1 for this specific workload?", and I interpreted your comment at the former. I wasn't talking about the article at all.
- tw04 5y ago
  > The miss is that the article in the link doesn't discuss VMs or virtualization at all, so talking about oversubscription/etc seemed like an ad-hoc commentary on the hardware configuration unless I totally missed that in the article There is a giant table in the middle of the article that is impossible to miss if you read it. It literally says # of VMs. As well as calling out VMware, and z/VM as tye hypervisors in use. The oversubscription is a simple math problem, and that's assuming best case scenario.