Re: Performance problem after merging db server

Art S. Kagel wrote: > > Greg Moye wrote: snip..... > I think that Greg is right on with his suggestions. I just want to add > a few things. You have 2CPUs and NUMCPUVPS set to 2. There tends to > be too much overhead in the multiprocessor code for only 2 physical > CPUs to be used effectively, also when load increases there will not be > any cycles free for OS functions which can effect the database as well. Well...now let's not forget who's the boss when it comes to dispatching priorities - if Solaris needs to do something important, it will before it dispatches a CPUVP. If the second CPUVP isn't there, then one CPU's worth of cycles is all that the engine can ever get. There's nothing a CPUVP can do that will keep Solaris from getting CPU cycles if it needs them. Agreed, MP mode requires some overhead, but I can't imagine it consuming the entire second CPU's cycles, which is what is required to make you worse off. This is a CPU with a SpecInt95 of 10-11 after all, that's a bunch of cycles to leave idle (assuming this is a DBMS machine and not much else...). At the very least, you owe it to yourself to try it both ways (1 vs 2 CPUVP's and all that implies...) and see which one you like better. I've tried it and I personally get much better throughput with two. This is one of the Informix suggestions and "common wisdom" I really disagree with, at least on Sun/Solaris platforms. One of my favorite pet peeves.... Of course if you can add another CPU, terrific, but I'd still be caught setting CPUVP's to 3 ;-) snip..... > > I cannot tell if you are using raw or cooked devices. RAW is 15-25% > faster. If you use cooked files you need to increase NUMAIOVPS. Also > your physical log, and presumable the logical logs as well, are in the > rootdbs. This is a major performance hit. Create a separate dbspace > for logs (ideally one each for logical and physical logs but one will > do) on a different disk and controller from rootdbs and your data > disks. I hope you do not have your database catalogs on the rootdbs > either. That's another performance no-no. Nice catch, I blew right past that stuff... > > TAFN. Hope we have helped. > > Art S. Kagel -- Greg Moye The above are my opinions only.