Re: [suse-oracle] File system cache limits, vm.dirty_ratio

Actually, there is a script which simplifies determining the amount of hugepages to allocate.  It is pretty simple to setup, and frees up kernel resources for doing work rather than managing memory.

HugePages on Linux: What It Is... and What It Is Not...
https://metalink2.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=361323.1

Shell Script to Calculate Values Recommended HugePages / HugeTLB Configuration
https://metalink2.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=401749.1

Regards,
-Michael




________________________________
From: "Levinson, Harry" <[email protected]>
To: Bobby Keegan <[email protected]>; [email protected]; Vladimir Barac <[email protected]>
Cc: [email protected]; [email protected]
Sent: Wednesday, February 25, 2009 7:29:16 PM
Subject: Re: [suse-oracle] File system cache limits, vm.dirty_ratio

 
I didn’t have as much luck with swappiness, but would suggest
trying it. From what I saw in the kernel source code, it should help. As an
alternative to hugepages, you can also try the init.ora parameter LOCK_SGA. It
is OS dependent and I think it is supported on SUSE 9 and 10, though I’ve
never used it there. Hugepages is better with large memory but does take more
time to calculate and implement.
 
http://www.dba-oracle.com/p_lock_sga.htm
 
 
 
 
 
From:Bobby Keegan
[mailto:[email protected]] 
Sent: Wednesday, February 18, 2009 9:05 AM
To: [email protected]; Vladimir Barac
Cc: [email protected]; [email protected]
Subject: Re: [suse-oracle] File system cache limits, vm.dirty_ratio
 
We had something similar a year ago, we’re on SuSE 9. 
We adjusted the /proc/sys/vm/swapiness to 10 and it made a significant
difference.
 
I couldn’t find the original reference that we used but here
are two. The one thing I remember is don’t set it to zero.
 
http://aplawrence.com/Linux/memory_tuning.html
http://www.linuxjournal.com/article/8308
 
Bobby 
Oracle DBA

________________________________
 
From:[email protected]
[mailto:[email protected]] On Behalf Of [email protected]
Sent: Wednesday, February 18, 2009 8:22 AM
To: Vladimir Barac
Cc: [email protected]; '[email protected]'
Subject: Re: [suse-oracle] File system cache limits, vm.dirty_ratio
 

The last year
we had the same issue with Tivoli Data Protector, in our case we set the
parameter vm.nr_hugepages to avoid Oracle SGA swapping during online backups
and tune some parameters for Tivoli. 
After that we
reduce swapping but it doesn't disappear. 

Regards! 

________________________________
Herman Maseberg
Líder de Tecnología
Loma Negra C.I.A.S.A.
Tel: (54-11)4319-3075
[email protected]


[email protected]
escribió el 18/02/2009 09:15:18:

> We want to limit amount of memory that SLES uses to buffer file 
> systems. We have situation like this on our database server: 
>   
> - SGA at around half of physical memory
(SGA 16GB, total RAM 32GB) 
> - Remaining memory is for user sessions 
> - No swapping, everything is fine.
Performance is great, no issues. 
>   
> However, when we initiate backup
(NetBackup client, simple file 
> backups) memory usage peaks at 100% and swapping starts. When we 
> terminate backup, everything slowly goes back to normal. 
>   
> Our assumption is that file system
caching kicks in when we start 
> backup. We want to limit O/S cache for filesystems. Oracle doesn't 
> use file system cache anyway, so it will not affect Oracle (OCFS2 
> with O_DIRECT). 
>   
> vm.dirty_ratio is set to 10, as advised
by Suse support. However, 
> nothing has changed. This is free output: 
>   
> free -m 
>          
   total       used       free  
  shared    buffers     cached 
> Mem:         32173
     32107         65      
   0         66      25896 
> -/+ buffers/cache:      
6145      26028 
> Swap:        32773
       578      32194 
>   
> Also, paging rate increases
tremendously. Here is the part of sar output: 
>   
> sar -B 5 20 
> Linux 2.6.16.46-0.12-smp
(ai-sapgrt-pr1)        02/18/09 
>   
> 12:23:42     pgpgin/s
pgpgout/s   fault/s  majflt/s 
> 12:23:47     64715.80  
 916.60  13664.40      0.00 
> 12:23:52     59247.31  
 710.98  12509.38      0.00 
> 12:23:57     32867.47  
1010.58  11054.29      0.00 
> 12:24:02     49332.20  
 221.20  23691.20      0.00 
> 12:24:07     43291.97  
1972.89  12452.41      0.20 
> 12:24:12     52531.94  
1495.21  11647.31      0.00 
>   
> 12:24:12     pgpgin/s
pgpgout/s   fault/s  majflt/s 
> 12:24:17     30538.00  
1095.80  13729.20      0.80 
> 12:24:22     35545.00  
2260.80  15230.00      0.20 
> 12:24:27     59802.40  
1898.80  15587.80      0.00 
> 12:24:32     46216.57  
2165.07  13352.69      1.00 
> 12:24:37     44167.60  
4573.20  13011.20      2.20 
> 12:24:42     44947.40  
2124.00  12552.80      0.20 
>   
> Is there a way to really limit Linux
buffers? 
>   
> Regards, 
> Vladimir Barac
> Database administrator | Alghanim Industries
> P.O. Box 223, Safat 13003, Kuwait
> Tel: +965 1881 111  / ext. 2960 
> [imagen eliminada] 
>   
> 
> ______________________________________________________________________
> This e-mail message and any attachments to it are for the sole use 
> of the intended recipients and may contain confidential and 
> privileged information. This e-mail message and any attachments are 
> the property of Yusuf A. Alghanim & Sons w.l.l. or any of its 
> subsidiaries or affiliates (“Alghanim Industries”). Any
unauthorized
> review, use, disclosure, or distribution of this e-mail message or 
> its attachments is prohibited. Any opinions expressed in this 
> message are those of the author and do not necessarily reflect the 
> opinion of Alghanim Industries. If you are not an intended 
> recipient, please notify the sender by reply e-mail and destroy all 
> copies of the original message and any attachments.
> ______________________________________________________________________
> _______________________________________________
> suse-oracle mailing list
> [email protected]
> http://listx.novell.com/mailman/listinfo/suse-oracle


.........................................................
Este mensaje, incluyendo sus anexos, contiene informaciones confidenciales
destinadas al individuo y propósito específicos, y está protegido por ley. Caso
no sea el usuario a quien está dirigido, debe borrar este mensaje. 
Está terminantemente prohibida la utilización, el acceso, copia o divulgación
no autorizada de las informaciones presentes en este mensaje. 
Las informaciones contenidas en este mensaje y en sus anexos son de
responsabilidad de su autor, no representando ideas, opiniones, pensamientos o
cualquier forma de posicionamiento por parte del Grupo Loma Negra.

Esta mensagem, incluindo os seus anexos, contém informações confidenciais
destinadas a indivíduo e propósito específicos, e é protegida por lei. Caso
você não seja o citado indivíduo, deve apagar esta mensagem. 
É terminantemente proibida a utilização, acesso, cópia ou divulgação não
autorizada das informações presentes nesta mensagem. 
As informações contidas nesta mensagem e em seus anexos são de responsabilidade
de seu autor, não representando idéias, opiniões, pensamentos ou qualquer forma
de posicionamento por parte do Grupo Loma Negra. 

The information contained in this communication is confidential, is law
protected, and is intended only for business use of the addressee. If you have
received this communication in error, please immediately delete it. 
It's forbidden the unathorized use, access, copy or disclose of the information
contained in this communication. 
The content of this message is responsability of the author, and does not
represent ideas, opinions, thoughts or any kind of statement of Loma Negra
Corporation. 

________________________________
 
The information contained in this email and any attachments may be
privileged and/or confidential and protected from disclosure. It is intended
solely for the use of the recipient(s) to whom it is addressed, or an employee
or agent responsible for delivering this message to the intended recipient(s).
You are hereby notified that any dissemination, distribution, copying or other
use of this communication is strictly prohibited. If you have received this
communication in error, please notify the sender by reply email and delete this
email and all attachments from your system. Thank you.

_______________________________________________
suse-oracle mailing list
[email protected]
http://listx.novell.com/mailman/listinfo/suse-oracle