Re: [Veritas-bu] Shared memory issue with Solaris 10

Hm I will add that to my notes the next time I do some benchmarking, 
thanks.

Justin.

On Wed, 23 Jul 2008, Spearman, David wrote:

> I will throw this one out for everyone. In test after test what we found
> was 65536 size and 128 num buffers worked best. We are a mixed Win /
> RedHat shop (with other stuff thrown in) . Win2k3 master and 2 media
> servers to an i2000 with 10 lto4 drives. We make sure the size is set on
> all the clients as well. When I say "test" I mean we used the settings
> noted above with the settings mentioned below on regular full backups.
> Our settings ran about 15-20% faster than the typical 256/32 or 131/32.
>
>
>
> David Spearman
>
> County of Henrico
>
>
>
> From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
> [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Jon
> Bousselot
> Sent: Wednesday, July 23, 2008 11:04 AM
> To: Justin Piszcz; NBU
> Cc: VERITAS-BU AT mailman.eng.auburn DOT edu
> Subject: Re: [Veritas-bu] Shared memory issue with Solaris 10
>
>
>
> I'll concur with Justin.  262144 SIZE is a good performer, and 32 NUMBER
> is a sweet spot for LTO-4.  If you have the ram and lots of inbound
> connectivity, you can go to 64 buffers, and it seems to work well.
>
> With 131072 SIZE  and 3072 NUMBER, if you have 1 drive and multiplexing
> set to 1, that tries to allocate a 400MB segment of memory.  Add in
> number of drives and multiplexing, I'm not surprised it cannot allocate
> memory.
>
> The formula from the docs is  (SIZE_DATA_BUFFERS * NUMBER_DATA_BUFFERS *
> Num_Drives * MPX_Factor)
>
> -Jon
>
> ----- Original Message ----
> From: Justin Piszcz <jpiszcz AT lucidpixels DOT com>
> To: NBU <netbackup-forum AT backupcentral DOT com>
> Cc: VERITAS-BU AT mailman.eng.auburn DOT edu
> Sent: Wednesday, July 23, 2008 9:11:06 AM
> Subject: Re: [Veritas-bu] Shared memory issue with Solaris 10
>
> There is your problem right there.
>
> $ cat NUMBER_DATA_BUFFERS
> 32
> $ cat SIZE_DATA_BUFFERS
> 262144
>
> For LTO-2 and LTO-3 you should be using the SIZE_DATA_BUFFERS as shown
> above, for the number of DATA_BUFFERS, anything above 32 is usually
> overkill/makes no differnece in performance.
>
> Justin.
>
> On Wed, 23 Jul 2008, NBU wrote:
>
>>
>> Friends,
>>
>> Fine tunning has been done in /etc/system also but no luck.
>>
>> Following is systems setting:
>>
>> We have set Net_BUFFER SIZE and
>> /usr/openv/netbackup/db/config/SIZE_DATA_BUFFERS = 131072
>> /usr/openv/netbackup/db/config/NUMBER_DATA_BUFFERS= 3072
>>
>> Following is the kernel parameter of Solaris 10 OS
>> root@P075XMED01 # prtctl $$
>> -bash: prtctl: command not found
>> root@P075XMED01 # prctl $$
>> process: 15640: -bash
>> NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT
>> process.max-port-events
>> privileged 65.5K - deny -
>> system 2.15G max deny -
>> process.max-msg-messages
>> privileged 8.19K - deny -
>> system 4.29G max deny -
>> process.max-msg-qbytes
>> privileged 64.0KB - deny -
>> system 16.0EB max deny -
>> process.max-sem-ops
>> privileged 512 - deny -
>> system 2.15G max deny -
>> process.max-sem-nsems
>> privileged 512 - deny -
>> system 32.8K max deny -
>> process.max-address-space
>> privileged 16.0EB max deny -
>> system 16.0EB max deny -
>> process.max-file-descriptor
>> basic 256 - deny 15640
>> privileged 65.5K - deny -
>> system 2.15G max deny -
>> process.max-core-size
>> privileged 8.00EB max deny -
>> system 8.00EB max deny -
>> process.max-stack-size
>> basic 8.00MB - deny 15640
>> privileged 8.00EB - deny -
>> system 8.00EB max deny -
>> process.max-data-size
>> privileged 16.0EB max deny -
>> system 16.0EB max deny -
>> process.max-file-size
>> privileged 8.00EB max deny,signal=XFSZ -
>> system 8.00EB max deny -
>> process.max-cpu-time
>> privileged 18.4Es inf signal=XCPU -
>> system 18.4Es inf none -
>> task.max-cpu-time
>> system 18.4Es inf none -
>> task.max-lwps
>> system 2.15G max deny -
>> project.max-contracts
>> privileged 10.0K - deny -
>> system 2.15G max deny -
>> project.max-device-locked-memory
>> privileged 3.92GB - deny -
>> system 16.0EB max deny -
>> project.max-locked-memory
>> system 16.0EB max deny -
>> project.max-port-ids
>> privileged 8.19K - deny -
>> system 65.5K max deny -
>> project.max-shm-memory
>> privileged 48.0GB - deny -
>> system 16.0EB max deny -
>> project.max-shm-ids
>> privileged 512 - deny -
>> system 16.8M max deny -
>> project.max-msg-ids
>> privileged 256 - deny -
>> system 16.8M max deny -
>> project.max-sem-ids
>> privileged 512 - deny -
>> system 16.8M max deny -
>> project.max-crypto-memory
>> privileged 15.7GB - deny -
>> system 16.0EB max deny -
>> project.max-tasks
>> system 2.15G max deny -
>> project.max-lwps
>> system 2.15G max deny -
>> project.cpu-shares
>> privileged 1 - none -
>> system 65.5K max none -
>> zone.max-swap
>> system 16.0EB max deny -
>> zone.max-locked-memory
>> system 16.0EB max deny -
>> zone.max-shm-memory
>> system 16.0EB max deny -
>> zone.max-shm-ids
>> system 16.8M max deny -
>> zone.max-sem-ids
>> system 16.8M max deny -
>> zone.max-msg-ids
>> system 16.8M max deny -
>> zone.max-lwps
>> system 2.15G max deny -
>> zone.cpu-shares
>> privileged 1 - none -
>> system 65.5K max none -
>>
>>
> +----------------------------------------------------------------------
>> |This was sent by qureshiumar AT rediffmail DOT com via Backup Central.
>> |Forward SPAM to abuse AT backupcentral DOT com.
>>
> +----------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
>> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>>
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>
_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu