Re: sybase system 10 limitation of 4 processors ?

Paul Chen (chen_p@perfit.zko.dec.com) wrote: : In article <lchutsonD7K3zE.H7p@netcom.com> lchutson@netcom.com (Lawrence Hutson) writes: : >What exactly do you mean support for more than one processor? I have : >heard this talk before, but I was under the same conclusion as : >Dr. Chen that most DBMS are IO bound. But surely those which are not i/o bound are the very same ones that need scalability to large numbers of cpus. Just because most of the world is content with a Ford/Toyota/Nissan/... does not mean that the discriminating purchaser is wrong to insist on Porsche/BMW/Rolls- Royce/... (fill in your own blanks). : By MP support (in the context of DB servers,) people usually mean that : a DB server can utilize multiple CPUs to process multiple tasks at the : same time. Sybase, as well as practically everybody else, does support : MP. MP support is important even if the environment is IO-bound, for : various reasons that I don't want to get into here. By the way, : architecturally, System 10 can support much more than 4 processors. : No problem. At the issue is not really "MP support beyond 4 processors" : per se, but the "performance scalability beyond 4 processors", which, : as some posters point out (as well as reported on trade journals,) will : be addressed by Sybase in their upcoming System 11. What I said in a : previous post is that the widely circulated Sybase "performance scalability" : problem usually only shows up in CPU-bound environment, but most of I am not very familiar with the Sybase architecture, but I had been led to believe that the Sybase architecture, whilst MP capable, was not true SMP, in that certain tasks/functions/activities had to go through a "master" server. I had been further led to believe that these "master" activities were i/o related. This had led me to assume that the scalability issue was *not* restricted to CPU bound installations. : the installations are IO-bound. To most Sybase users, this scalability : problem is really an academic issue, and I believe this is the reason But this is cause and effect! My experience is that most sites that need scalability do not choose Sybase. Therefore most Sybase sites probably do not miss the scalability which they lack! : why Sybase did not address this issue in System 10. (This scalability : problem of Sybase has been known in the technical community for several : years. It's not a new issue at all.) : Usually, if you throw in enough memory and disk controllers and drives : (and if your platform has enough slots for them,) and design your : physical database placement carefully, you can bring your particular : environment to be CPU-bound. However, in practice, very few people : are willing to spend the kind of money and effort to do this, and in : most cases, there is probabily no business need to do this anyway. So, : most of the DB installations out there are IO-bound. Again this is cause and effect. If there is a genuine business need, then businesses find the money and effort, and purchase scalable software on scalable hardware. Most Pyramid installations are not i/o bound. If you configure a Pyramid/scalable-RDBMS combination correctly, then it is memory-bound. (OK, it will then start swapping until it becomes i/o and/or cpu bound, but that is not really a genuine case of i/o "boundness", most sites hit the limits on memory expandability long before they hit the limits of CPU or i/o bandwidth expandability). Although a Pyramid is likely to be i/o bound on something like a TPC benchmark, with real Customer benchmarks, running real Customer applications, we are almost never i/o bound. Being i/o bound (in the Open Systems world) is (nearly always) the result of inappropriate h/w platform, inappropriate s/w platform, inappropriate configuration or a combination of the above. Nevertheless, you are probably correct that most RDBMS sites *are* i/o bound! : -- : Paul Chen, Ph.D. : consulting at DEC : Disclaimer: My opinions only! -- graeme -- Disclaimer: The author's opinions are his own, and not necessarily those of Pyramid Technology Ltd. or Pyramid Technology Inc. --------------------------------------------------------------------------- -m------- Graeme Sargent Voice: +44 (0)252 373035 ---mmm----- Senior Database Consultant Fax : +44 (0)252 373135 -----mmmmm--- Pyramid Technology Ltd. Telex: Tell who??? -------mmmmmmm- Farnborough, Hants GU14 7PL Email: graeme@pyra.co.uk --------------------------------------------------------------------------- We have the technology. The tricky bit is learning how to use it.