Re: Single cpu vp woe

Neil Truby wrote: > 9.20 UC3 on Red Hat 7. > > This site is running the time series datablade in production on a 2- > cpu box. It's all working fine. > > For reasons we needn't go into they want to move to a single cpu box. > [ETC] Neil, you haven't mentioned the settings for NOAGE. I'm assuming you have NOAGE=0 on both systems, or have at least switched it off on the single CPU box? Notwithstanding Richards important points about hyperthreading Intels, following are my expectations. On the 2 CPU box: - if you set single cpuvp and NOAGE=1, you'll basically guarantee upto complete allocation of the cpu cycles of one processor. Since you only have single cpuvp, you will not get any cpuvp type activity on the other CPU. Processes like 4GL, Java, Apache, etc and also the sundry engine processes will probably drift to the free CPU if the database keeps one processor boiling. - if you set dual cpu vp and NOAGE=1, you'll basically guarantee upto complete allocation of the cpu cycles of the two processors. You'd better hope that nothing else is being attempted on this machine apart from database activity, because if the database gets really busy, this configuration will choke out just about every other task. I have seen HP's and Intel crippled by this kind of mistake, however DSS is a prime example of a system where total cpu hogging can be appropriate because there are no 4GL or other processes competing for cpu cycles. - if you set dual cpu vp and NOAGE=0, you'll get two cpuvps, often working in tandem which will only be given CPU allocations in a timesharing manner. However, as long as competing processes do not take too much, it can still add up to more than 1 CPU worth of cycles depending on other load. That's just about all the interesting variations for a 2 CPU machine. Single cpuvp and NOAGE=0 is a very mild-mannered setup which doesn't help anyone except other non-database tasks. On the 1 CPU box: - if you set NOAGE=1, then you'd better hope that no other work is attempted on that machine once the engine gets busy. I recall seeing Intels setup this way having some trouble getting basic O/S work performed, so I believe that this configuration (with NOAGE=1 on a single CPU box) is probably counter-productive. I have found that another alternative (close to your findings) is more effective. Now assuming 1 CPU box and NOAGE=0: - if you set a single cpuvp, it will compete in a time-shared manner with other UNIX processes. If there's a fair set of 4GL, Java, etc processes, then the engine can indeed be restricted to a significantly smaller proportion of the available cycles. Of course, if there is no other work going on apart from the engine, then the cpuvp will naturally end up being the only process which is repeatedly given cpu timeslices, despite the NOAGE=0 setting. If the other 4GL/Java/etc processes are waiting for results from the engine, then eventually the engine will get so backlogged it becomes the only process wanting to do work, but that's not a very efficient approach to scheduling. So how do you get a few more cpu cycles in a democratic time-slicing O/S? With the engine, you can setup 2 or maybe even 3 cpuvps, which collectively will be allocated a larger slice of cpu cycles simply because the UNIX regards them as making separate demands for resources. I'm not surprised you saw better performance. This is how I've set up a fair few single CPU Intels. I've even applied this principle to duals when the benefits either way are not so clear-cut. CPU allocation becomes far more rewarding when you can NOAGE=1 allocate 3 out of 4, or 6/7 out of 8 to the database. Dual and even triple processor boxes are still somewhat vague in their benefits for IDS. My understanding is that the MULTIPROCESSOR parameter must simply be set to reflect the hardware. I'm not sure what to assume for hyperthreading processors, but I believe that MULTIPROCESSOR=1 is the correct setting there. The SINGLE_CPU_VP parameter simply guarantees that you will not allocate two or more cpuvps. I believe this means that the engine can do semaphore and latching activities in a different, more efficient manner. Both these latter two parameters affect the way the engine needs to most efficiently perform semaphore and latching activities, so it's very useful and important to set them correctly to reflect reality, not merely to reflect wishful thinking. You can also muck around with the "niceness" settings in UNIX, but it becomes increasingly fussy, and also there are some sysadmins that you simply don't want to see this trick.