Re: NET or CPU VP Class : confusing NETTYPE recommendatio

MOPSOMER@raychem.com wrote: > > Hi John, > > You indicate that large SAP R/3 benchmarks use CPU VPs (also for the TLI > connections). This is what the SAP OSS note seems to recommend as well. > I was using CPU VPs for SHM and TLI until a few weeks ago. At that moment, > someone recommended to use CPU VPs for SHM and NET VPs for TLI connections. > > Do you know more details about the setup for these large SAP benchmarks ? > I would be VERY GLAD to receive more details as we are a large Informix/SAP > site (on SUN). We are using a SUN ES6000 with 18 CPUs as a database > server. This database server also contains a small SAP Central Instance. > Users log on (using SAP Logon - logon groups) to one of the 8 application > servers (SUN E4000 - 8 CPUs - 2GB RAM) ? We have about 35 workprocesses > per application server (these represent 35 permanent Informix sessions). > As SAP workprocesses are similar to the Informix virtual processor concept, > these workprocesses can handle incoming work from more than 35 SAP users. > > Until a few weeks ago, I had the following NETTYPE/NUMCPUVPS settings : > NETTYPE ipcshm,1,60,CPU # settings until April 4, 1999 (MOP) > NETTYPE tlitcp,4,80,CPU # settings until April 4, 1999 (MOP) > NUMCPUVPS 17> > I changed these to the following because many DBAs found them strange : > NETTYPE ipcshm,1,60,CPU # Override sqlhosts nettype parameters > NETTYPE tlitcp,3,100,NET # Override sqlhosts nettype parameter > NUMCPUVPS 14> > What would you recommend ? > > I do NOT use affinity yet, but I was planning to manually bind the 14 CPU > VPs to 14 CPUs and bind the 3 NET VPs to 3 of the remaining processors so > that they don't interfer with each other. Should I use CPU VPs for both > protocols (SHM and TLI) again; and if so, would you stick to a few poll > threads (on CPU VPs) which support many connections or many poll threads ? I respect John Miller greatly but I think that John is not seeing the forest for the trees. I know the wisdom of the benchmark guys, and do myself take many of my own recommendations from their work. But on this one the problem is yes there will be fewer context switches and the CPU VP will indeed be ready to receive requests immediately because it is spinning the CPU not sleeping. However, NO OTHER PROCESSES CAN GET ANY WORK OUT OF THAT CPU BECAUSE THAT VP IS SPINNING. Sorry for shouting. I know also that in my article I said we assume "dedicate server" but that is NOT realistic. We all have to get other work done on the machine independent of the CPU VPs, even if it is only running ontape or oncheck or Legato Networker. How can you do that if the engine is hogging all the cycles? In addition, on our systems before we moved from 16 CPUs to 32 CPUs the OS would bog down and EVEN the engine would slow if the number of system calls per second passed 14000. After doubling the number of CPUs that limit rose to about 25000 system calls per second. Having the CPU VPs polling the network drove the number of system calls over the limit and throughput dropped! For you, Mario, I would recommend sticking to SHM on CPU and TCP on NET however, I would run a shared memory listener in EVERY CPU VP if you have 14 CPU VPs make 14 listeners. Otherwise you will find that CPU VP #1 is doing the lions share of the work and you are not getting much parallelism between sessions. And since this VP is so busy it will have less time to poll the net or shared memory so it will be less responsive. One may say: "So what it VP #1 does most of the work, if it can handle it why not? It will pass off work when it is too busy won't it?" The answer takes some digging into the working of the engine. One problem I can address here quickly is that the checkpoint thread always runs in CPU VP #1 and will hog the VP and not release it unless there are no cleaners available when it is ready to launch a cleaner. The engine does NOT reassign active threads out of CPU VP #1 when the checkpoint starts it just places them all on the ready queue. So the more you rely on CPU VP #1 to listen the more work it will take for itself and the more queries will be suspended during the checkpoint. Not only that but if there indeed is no cleaner available at some point during the checkpoint the checkpoint thread suspends itself, releasing the VP finally, and placing itself at the bottom of the ready queue. The more threads already on the ready queue the longer the checkpoint will be suspended while these are all serviced before the checkpoint can continue/complete. This is one source of long checkpoints. And do not forget that long checkpoints cause update/insert delays and reduce the timeliness of the data not to mention making users and clients wait for completion. Does John think that i.Sell will be a success if customers get complaints from their customers about long delays processing orders because of checkpoints? Do not forget that official benchmarks only require one or two checkpoints to be passed during the run and less official benchmarks, like SAS's, may NEVER checkpoint during the duration of the testing. Real world? Set: NETTYPE ipcshm,14,60,CPU NETTYPE tlitcp,7,80,NET Art S. Kagel