Skip to Content
avatar image
Former Member

CI/DB Server performance on Vmware?

I am looking at Vmware compared to physical hosting for a replacement SAP infrastructure.

Would anyone care to pass comment on the following comment in OSS note: 674851.

"...applications that actually access the database, or communicate or print using the network, are significantly slower " [on a virtualized server, when compared to a physical server]

and (even more frightening)

"For release upgrades and Unicode migrations in a virtual environment, runtimes that are up to five times longer than the runtimes in a non-virtualized environment have occurred."

Are these comments borne out by your experiences??

It seems to me that almost every program in SAP 'actually accesses the database', so that means everything is significantly slower under vmware. I can accept the touted 10-20% slower than the physical hardware; I can't accept 5x slower...

If so, is there any real benefit in virtualising the CI/DB in an ABAP based system?

Or is a better approach to virtualise only non-production environments?

Thanks in advance,

Andy

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • Best Answer
    Mar 24, 2010 at 10:12 PM

    > It seems to me that almost every program in SAP 'actually accesses the database', so that means everything is significantly slower under vmware. I can accept the touted 10-20% slower than the physical hardware; I can't accept 5x slower...

    I'd say (as a diplomatic answer): it depends.

    > If so, is there any real benefit in virtualising the CI/DB in an ABAP based system?

    You get a "free high availability"; if one server crashes you can just boot the instance on another one.

    > Or is a better approach to virtualise only non-production environments?

    I agree that virtualization is a big hype, it has many advantages (apart from the HA point) but it comes with a cost. On small to medium size (where size = I/O load and number of users) systems the users won't even notice that the system runs virtualized on bigger systems with lots of I/O you may have a significant performance penalty. This all depends on your environment and how you use the system and what you do with them. I also have a problem with big systems (> 64 GB RAM and > 1000 users) putting them on VMWare (or other virtualizing environments).

    I'd set up a copy of your production system and simulate (e. g. batch jobs) a more or less production load and check the runtimes of the jobs. It's very difficult to give a general advise.

    Markus

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      As a roundup of this thread, I would like to share my findings.

      - we found we could significantly improve the database time by simply rearranging the storage to a more traditional mirror set approach (4 volumes, mirrored, one per SQL server data file, separate mirror set for t-logs)

      - we found that the cpu (individual core) performance on the vm was not significantly better on this relatively new AMD based server (dl385), however, of course there are now 12 cores on the server, rather than the 4 on the old hp rp7410.

      - overall batch runtimes were significantly better once the io paths were improved (typically 20-30% better runtime, e.g. 1000 seconds down to 700 seconds).

      We aim to perform proper loadrunner performance tests prior to go live but the indications for us are that:

      - we will get acceptable performance (though it is a smallish system - < 200 concurrent users)

      - a reduced infrastructure footprint

      - inherent poor-mans 'HA' by implementing a small vm host farm and manually restarting on another host in case of hardware failure

      - lower hardware costs

      - lower software costs (actually nothing to do with vmware, just moving oracle->sql)

      - increased agility to adopt newer server technology as it becomes available.

      - improved integration/resource sharing with other applications

      So, it seems for us to be a sensible way forward to go with a vmware based solution

      Andy.