IDS Forum

Re: IDS 10.0

Posted By: Richard Kofler
Date: Friday, 30 November 2007, at 11:43 a.m.

In Response To: Re: IDS 10.0 (Art S. Kagel (Oninit LLC))

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

Messages In This Thread

• IDS 10.0
  SAMUEL JAKABOWSKI -- Friday, 30 November 2007, at 10:19 a.m.
  • Re: IDS 10.0
    Art S. Kagel (Oninit LLC) -- Friday, 30 November 2007, at 10:31 a.m.
    • Re: IDS 10.0
      SAMUEL JAKABOWSKI -- Friday, 30 November 2007, at 10:45 a.m.
    • Re: IDS 10.0
      Richard Kofler -- Friday, 30 November 2007, at 11:43 a.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.