dhepner@hpisod2.HP.COM (Dan Hepner) (11/18/89)
From: forrest@phobos.sybase.com (Jon Forrest) >>> >>> One of the strong points of the Sybase architecture is that we >>> require only one operating system process per Server. >> >>Could you comment on if or how this model affects Sybase's >>ability to exploit multiple processor architectures? > >Instead of replying to this perfectly reasonable question, I'll >defer to descriptions you'll see in the future about our MP product. Maybe you could discuss the abstract question, without offering any claims about any Sybase product. It would seem to the naive that in an MP system, assuming that performance was limited by the CPU cycles available to the server, that you would want your server to consist of at least one OS process per processor. Are there alternatives? Dan Hepner
forrest@phobos.sybase.com (Jon Forrest) (11/20/89)
In article <13520003@hpisod2.HP.COM> dhepner@hpisod2.HP.COM (Dan Hepner) writes: > >Maybe you could discuss the abstract question, without offering >any claims about any Sybase product. > The other reason why I can't comment on matters relating to the MP server is because I don't know anything about it, or at least not enought to present even the relevant abstract questions intelligently. Unhappily, you'll have to wait for someone else from Sybase to respond or you'll have to wait for more general information to appear from Sybase. Sorry. ---- Anything you read here is my opinion and in no way represents Sybase, Inc. Jon Forrest WB6EDM forrest@sybase.com {pacbell,sun,{uunet,ucbvax}!mtxinu}!sybase!forrest 415-596-3422
harrism@aquila.DG.COM (Mike Harris) (11/28/89)
In article <7141@sybase.sybase.com>, forrest@phobos.sybase.com (Jon Forrest) writes: > > In article <13520003@hpisod2.HP.COM> dhepner@hpisod2.HP.COM (Dan Hepner) writes: > > > >Maybe you could discuss the abstract question, without offering > >any claims about any Sybase product. > > > First, my input to your MP question: First, It is VERY advantageous to have a server per processor. That way time can be allocated against your workload, concurrently, by both processors. The overhead involved (not insignificant) is more than made up by the extra cycles that your workload receives. And also by the scalability the product (to >2 MPs, tuning, etc). Also, it is advantageous to have multiple servers even on a singe processor for another reason: That being I/O. Unless a server is very smart (Sybase does have os hooks to take advantage of this in some circumstances where available in the os platform) it will be hung when it performs I/O, or verrrrry long queries. Even with disk caching and async I/O, pended writes are still required during the commit phase. > The other reason why I can't comment on matters relating to the > MP server is because I don't know anything about it, or at least > not enought to present even the relevant abstract questions > intelligently. Unhappily, you'll have to wait for someone else > from Sybase to respond or you'll have to wait for more general information > to appear from Sybase. Sorry. I now understand the reasoning, or lack thereof, in Jons previous discussions. I'm sorry, but I don't see how one can reasonably discuss the merits of even a single server architecture without understanding the basics of multiple server architectures. Especially considering the fact that their product has a notion of "threads". The problems & challenges are very similar in nature. I do respect him for finally admitting it. This is a forum for discussion. Let's ask questions & learn answers - not act like experts where we aren't. > > ---- > Anything you read here is my opinion and in no way represents Sybase, Inc. > Unfortunately, most people forget about this line - esp when the person is arguing the merits of their companies product on a forum such as comp.databases. regards, Mike Harris - KM4UL harrism@dg-rtp.dg.com Data General Corporation {world}!mcnc!rti!dg-rtp!harrism Research Triangle Park, NC