Re: Sybase limitations
> > Hi: > > I am trying to find out the conceptual reason why sybase system 10 does > not work well with more than 4 processors. I have heard that it has > scalability problems. Is this true ? Are there any other major problems > related to system 10 ? Is there an architectural flaw that is difficult > to correct ? > > Do most database servers need more than 4 processors ? > > Do oracle/informix have a advantage over sybase because they can handle > upto 32 processors ? > > Any other related information would be greatly appreciated. > > Regards: > -- > Atul H. Lathia, donuts3!ahl,ahl@donuts3.bellocre.com, RRC 5C-114, 908-699-6554 > The necessity for more than one CPU is applications dependant. Having worked with all the major databases, I can give you a brief overview of why Sybase doesn't scale well. Sybase was the first vendor to use a mulit-threaded model, but it was targeted to uni-processor systems prior to the availablity of SMP systems. The basic problem is that the first process, Engine 0, handles the bulk of the I/O which is the biggest bottleneck in RDBMS's. Engines 1-n handle mostly network I/O or user connections. This results in a great deal of context switching by the OS for Engine 0 and causes blocking. This is readily evident if you use UNIX utilities to examine context switches. Furthermore, the threads in Sybase are relatively heavy, thus thread creation is expensive. Since Engine 0 is a bottleneck, the other engines diminish in value as the number increases since they are so dependent on Engine 0 for services. This results in scalability problems beyond 4-6 CPU's. System 10 has a very similar architecture to v4.9 and did not address these issues. There is a great deal of concern by the industry analysts that System 11 will not resolve the problems as well, this is shared by many users of System 10 that found out the hard way that it didn't live up to the promises made by Sybase, resulting in the recent financial diaster in which Sybase lost over 40% in stock values. MicroSoft SQL-Server for NT has these problems as well since it is based on the v4.x Sybase kernel. Oracle has a similar probelm in that the architecture is heavy in multiple processes that block and context switch. Oracle is a mulit-process, not multi-threaded architecture, that uses a multiplexing scheme with a dispatcher. Oracle uses more system resources to accomplish it's tasks resulting in less efficient use of the hardware resources. On Very Large DataBases (VLDB) scalability is limited due to the lack of data partitioning, which drastically reduces the amount of disk I/O, again the most prevalent bottleneck. Both vendors are trying to re-architect their products to match the lightweight multi-threaded model that is core to the Infomix DSA OnLine product. The MT model allows for the internal parallelism that is winning rave reviews by the industry analysts. Coupled with data partitioning to reduce disk I/O and you have a product that scales from uni-processor to large numbers of SMP CPU's. Note that DSA was developed in conjunction with Sequent, a pioneer in large SMP UNIX systems. DSA uses the concept of "Virtual Processors" that are UNIX processes that are individually specialized for RDBMS functions such as CPU, network I/O (NIO), asynchronous I/O (AIO) logging I/O (LIO) and so forth. Each VP executes threads for particular tasks in a non-blocking fashion. This provides very efficient use of hardware resources with minimal context switching. The fundamental architectures of the RDBMS kernel are very important to addressing scalablity and performance. I hope that this sheds some light on the differences in the current RDBMS products in the market. Obviously I have a bias, but the facts remain and are evidenced by the performance or lack thereof in key benchmarks such as the TPC-C which are critical for un-biased assessment of RDBMS products. I hope that you'll take a closerlook at our architecture and technology. Sincerely, -- //////////////// Mark Sigler ////////// // Client Services Engineer ////// / /// Informix Software, Inc. ///// // //// 8675 Hidden River Parkway TBD //// // ///// Tampa, FL 33637 Fort Lauderdale, FL /// // ////// Voice: 813.971.0010 407.883.9319 // // /////// Fax: 813.632.9582 407.883.9319 / /////////// Voicemail: 800.688.4217 x2147 407.883.9319 //////////////// Email: msigler@informix.com WWWeb: http://www.informix.com --