Veritas-bu

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

2008-07-23 11:44:13
Subject: Re: [Veritas-bu] Shared memory issue with Solaris 10
From: "Spearman, David" <spe08 AT co.henrico.va DOT us>
To: "Jon Bousselot" <jon-bousselot AT pacbell DOT net>, "Justin Piszcz" <jpiszcz AT lucidpixels DOT com>, "NBU" <netbackup-forum AT backupcentral DOT com>
Date: Wed, 23 Jul 2008 11:19:50 -0400

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
<Prev in Thread] Current Thread [Next in Thread>