Re: Committed to Linux? (Was: Re: Some Pix)

> ---- Original Msg from: John H Frantz <linux-informix@iiug.org> At: 9/10 15:41 > > Something tells me I've been missing the point with all this SMP talk. > I'm not a DBA so I may be looking at things rather simplistically. > Please, someone tell me if I'm wrong with any of the following > statements. > > 1. Informix Dynamic Server (IDS) spawns a handfull of server processes, > some are called CPU virtual processes, others are IO vps, etc. When > configuring IDS you specify more or less how many of these processes > will be spawned, a number which stays more or less constant. Yes. > 2. You also specify whether Informix should be aware that the machine > has multiple processors (cpus). By telling Informix this you enable > certain features such as parallel queries, i.e. a single select > statement from a user can be processed in parallel by multiple cpus, > etc. These features can greatly improve performance in certain > situations but at a cost of processing power. The overhead is most often > too great for a 2 cpu machine. With 4 cpu's and more the advantages far > outweigh the costs. Yes you tell the engine whether there are multiple processors but that does not enable or disable any user level engine features. All that it does is change the way the engine does resource latching. If MULTIPROCESSOR is 0 the engine recognizes that it does not have to worry about multiple VPs accessing resources simultaneously and that it can rely on certain locally atomic operations to be globally atomic as well. If MULTIPROCESSOR is 1 then more careful and more expensive resource latching must be done as another engine process may interfere if a CPU level latching operation is used rather than a more expensive kernel level operation. Whether a user operation can utilize multiple CPUs depends on how many CPU VPs are running and the PDQPRIORITY level. If you run multiple CPU VPs, even on a uniprocessor system, the engine will attempt to parallelize operations where possible. Obviously the effect will be minimal on a uniprocessor system (there will be some gain if you have an intelligent disk controller with onboard CPU and a VERY fast main CPU, otherwise negligible). The overhead of the safer latching is the main reason that on a 2CPU system IDS does not gain much over running on a 1CPU system. In addition, if you set SINGLE_CPU_VP to 1 you are promising the engine that you will not start up more than one CPU VP. In this case IDS refrains from certain internal calculations and resource controls needed to determine when and where to parallelize and to control the parallel processing. This is used to reduce the overhead and improve performance on 1 & 2 processor systems when running 1 CPU VP. On these systems performance will usually exceed that gotten from running two CPU VPs. This is why I stated the other day, and stand by my statement, that IDS needs more than 2 CPUs to really shine. Since Linux will not perform well with more than 2 CPUs until the next kernel release we must wait until then to take best advantage of IDS on Linux. > 3. You don't have to make Informix aware of a multiple processor > machine. In this case Informix operates in the same way as on single > processor machines with no additional overhead. The server processes are > simply dealt to each cpu by the operating system. The more cpu's, the > more processing power. So if processing power is a bottleneck on a > single cpu system, adding a cpu will certainly improve performance. Not really. As noted in the caviat above about the overhead needed when there are 2+ CPUs and setting MULTIPROCESSOR you do have to tell the engine about multiple CPUs. You do have to set MULTIPROCESSOR to 1 on a 2CPU system or NASTY crashes and hangs are possible. However, also as noted, you can ameliorate the situation somewhat with SINGLE_CPU_VP set. As to whether a one CPU VP instance will perform better on a multiprocessor than on a single processor it really depends on a few factors. If there are other applications running on the system, particularly non-database apps since IDS clients have to sleep while the engine is processing, in general, anyway, then absolutely since there will be less interference between IDS and the other apps. If the system is a dedicated server, and to a large extent also of only IDS clients are running on a non-dedicated system, then there may be little or not gain. If AIO VPs are being used there will be a noticable gain, if only KAIO is used then there will be no gain if Informix processor affinity is used since both the sqlexec and KAIO threads in the CPU VP are bound to the same CPU. > Nils.Myklebust@nmdata.com wrote: > > > > > I am sure Art can answer for himself, but if there's one thing you can't do > > it's calling Art Kagel silly. He simply knows more than most about the > > Informix products. I can indeed Nils, I have just refrained from getting into a pissing match. It really would not be a fair contest. It would be like having a shootout between my Colt 45 and his BB gun. I refuse to respond to people who do not know about what they speak about. My "silly" antagonist has obviously never written any multi-process or multi-threaded applications running on a 20 or 32 CPU system and watched in horror while algorithms that worked fine with a single process, or even multi-tasking on 2 CPUs, trip over itself. The best analogy is a three-legged race. It is easy to coordinate your own two legs but tie one of them to someone else's and coordination becomes half of the job. Now imagine an entire track team with its legs tied each to the next (ie an N+1 legged race). As fast as these people are individually or serially (as in a relay) working in parallel the effort to coordinate may preclude any progress at all. Art S. Kagel, kagel@bloomberg.net