IDS 10.0

Hi, While setting up a test environment, a question concerning the correct setting for NUMCPUVPS popped up. We have a Hitachi SAN with fifty-seven 52 GB chunks allocated to this instance. Memory is 8 GB $ uname -XSystem = SunOS Node = test_1 Release = 5.10 KernelID = Generic_127111-01 Machine = sun4u BusType = <unknown> Serial = <unknown> Users = <unknown> OEM# = 0 Origin# = 1 NumCPU = 4 $ psrinfo -p -vThe physical processor has 2 virtual processors (0 16) UltraSPARC-IV+ (portid 0 impl 0x19 ver 0x22 clock 1800 MHz) The physical processor has 2 virtual processors (2 18) UltraSPARC-IV+ (portid 2 impl 0x19 ver 0x22 clock 1800 MHz) Any pointers would be appreciated.

SAMUEL JAKABOWSKI wrote: > Hi, > > While setting up a test environment, a question concerning the correct setting > for NUMCPUVPS popped up. > So, what's the question? You have 4 cores and you have configured 4 CPU VPs. Looks kosher. Question or should we guess? Do you want to know if this is a good setup? It depends. If this is a dedicated server box with no significant applications running other than IDS I would say that you could be running up to 12 CPU VPs on this system and see incremental throughput improvements for each of the 12 as it is added. Especially if you are running queries under PDQPRIORITY. If it's not dedicated you have to decide how much resource to reserve for IDS. You could us affinity to limit the CPU VPs to cpu cores 16 & 18 ONLY and run just 2 to 6 CPU VPs instead. Art S. Kagel Oninit, LLC > We have a Hitachi SAN with fifty-seven 52 GB chunks allocated to this > instance. > Memory is 8 GB > > $ uname -X> System = SunOS > Node = test_1 > Release = 5.10 > KernelID = Generic_127111-01 > Machine = sun4u > BusType = <unknown> > Serial = <unknown> > Users = <unknown> > OEM# = 0 > Origin# = 1 > NumCPU = 4 > > $ psrinfo -p -v> The physical processor has 2 virtual processors (0 16) > UltraSPARC-IV+ (portid 0 impl 0x19 ver 0x22 clock 1800 MHz) > The physical processor has 2 virtual processors (2 18) > UltraSPARC-IV+ (portid 2 impl 0x19 ver 0x22 clock 1800 MHz) > > Any pointers would be appreciated. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > >

System is dedicated to the Informix project. This system will replace a 7.31 system. Some in the group maintained that since there are just two physical processors the number should be lower while others said higher. Will try the 12 as was suggested.

Hi, let me add my 2 Eurocents Art S. Kagel (Oninit LLC) schrieb: > SAMUEL JAKABOWSKI wrote: >> Hi, >> >> While setting up a test environment, a question concerning the correct > setting >> for NUMCPUVPS popped up. >> > > So, what's the question? You have 4 cores and you have configured 4 CPU > VPs. Looks kosher. Question or should we guess? > > Do you want to know if this is a good setup? It depends. If this is a > dedicated server box with no significant applications running other than > IDS I would say that you could be running up to 12 CPU VPs on this > system and see incremental throughput improvements for each of the 12 as > it is added. Especially if you are running queries under PDQPRIORITY. > > If it's not dedicated you have to decide how much resource to reserve > for IDS. You could us affinity to limit the CPU VPs to cpu cores 16 & > 18 ONLY and run just 2 to 6 CPU VPs instead. > > Art S. Kagel > Oninit, LLC this all is basically correct, but I had to learn that there is an end to heaven. If this is Linux the I/O scheduling is very important, in fact as important as the maximum number of task switches the system can do per second. You can measure this like so: Number of context switching - HW-CPU-thread-wise is reportet by vmstat or sar (which sits in package sysstat) If you add 1 CPU VP (you can do it on the fly using onmode -p, see docs or onmode usage message) AND if you were neither I/O saturated nor CPU saturated beforhand AND # of pswitches does not rise anymore -> you found the sweet spot. Therefore remove that one last CPU VP and you will be happy. In real life this is not as easy as I wrote it, because most of the sites I do see atm either use very expensive I/O subsystems or cheap ones. As a matter of fact, they all run I/O bound only ....., and more of the real cheap ones (speaking about less than 20K USD per 12 terabytes) is much more performant than the very expensive ones. So adding more CPU VPs does not do much good. If this is the case at yours also, go read about the real SSDs (Solid State Disks, _not_ the garbage leftover from MP3 players what they call SSD nowadays) at www.storagesearch.com Then analyze (spelling?) where your I/O is - if your memory throughput is fast enough then increase BUFFERS and split BUFFERS into more than 1 BUFFERPOOLS (onstat -g ppf oder sysptprof is your friend) - if memory throughput is not fast enough then go to magmt and as for bucks / Euros to buy real SSDs (real SSD means identical IOPS when reading and writing, and in the range of 8,000 per second or more) But this is expensive and mgmt will ask you how many you need and how big they must be. And a good strtegy is to put only I/O intensive and smallish stuff on these devices! > >> We have a Hitachi SAN with fifty-seven 52 GB chunks allocated to this >> instance. see my comment about haveing only 1 expensive I/O subsystems, and only 1 because it is so expensive.... >> Memory is 8 GB If it is possible to add another 8GB (and it is possible!) - *do not listen* buy it from Kingston - and add it, this 'd be a good move >> >> $ uname -X>> System = SunOS >> Node = test_1 >> Release = 5.10 hmm. virtual or real? If you want network and I/O performance, simply forget the virtualization hype! >> KernelID = Generic_127111-01 at least the I/O drivers should be alsway patched to the highest possible version. >> Machine = sun4u >> BusType = <unknown> >> Serial = <unknown> >> Users = <unknown> >> OEM# = 0 >> Origin# = 1 >> NumCPU = 4 >> >> $ psrinfo -p -v>> The physical processor has 2 virtual processors (0 16) >> UltraSPARC-IV+ (portid 0 impl 0x19 ver 0x22 clock 1800 MHz) >> The physical processor has 2 virtual processors (2 18) >> UltraSPARC-IV+ (portid 2 impl 0x19 ver 0x22 clock 1800 MHz) this, my friend, means that each and every cheap PC HW has a better memory thruput that that machine. Each phys processor has exactly 1 MMU (memory management unit), but runs 2 threads -> and they must be synchronized every bloody time they look into memory. Bad news that is. Test it: Create a table, having 1 row pewr page and as many pages as you have BUFFERS minus 2000.do a seqscan 2 times, the 2nd time will do no diskreads anymore (onstat -p) then run select '1' from testtable where testcolumn = <this is not in any rows> It must attach each buffer once. Then repeat the test, but this time columnsize is so small, that 200 rows fit into 1 page. Test and blame your harware vendor! Good luck dic_k >> >> Any pointers would be appreciated. >> >> >> > ******************************************************************************* >> Forum Note: Use "Reply" to post a response in the discussion forum. >> >> > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Richard Kofler SOLID STATE EDV Dienstleistungen GmbH Vienna/Austria/Europe