[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: Limiting systems buffers



BUMP --- Nobody has any comments on this?

-----Original Message-----
From: redhat-list-bounces redhat com
[mailto:redhat-list-bounces redhat com] On Behalf Of Allen, Jack
Sent: Monday, May 23, 2011 2:17 PM
To: General Red Hat Linux discussion list
Subject: Limiting systems buffers

Hello:

        Is there a sysctl parameter that will limit the amount of memory
the kernel uses for systems buffers used for file systems and direct I/O
to a block device?

        The reason for the questions is I have an Application that uses
a chunk of Shared Memory and when a Storix BMR (Bare Metal Restore)
backup is done to a USB drive the Application is affected, the users say
it locks up. My first thought was the USB interface to the drive is slow
and the Storix backups is copying several complete file systems to block
device of the USB drive for a bootable image and therefore the system
allocates a lot of system buffers, waiting for them to be flushed and
then starts paging out Shared Memory because it is not happening as fast
as more read and writes are done. This is based on some things I read at
one time that Shared Memory is one of the first things to get paged out
when memory get tight. So I changed the Application to lock Shared
Memory in Physical Memory thinking that would help and I think it did
some.

        But I need some way to keep the Storix backups for affecting the
Application, so I am looking for ways to control it, other than the
vendor making changes, which would probably take a while and then would
not help my customers that would probably not upgrade unless that are
having real bad problems.

-------------------------
Jackson C. Allen
McKesson Provider Technologies
5995 Windward Parkway
Alpharetta, GA 30005
(404) 338-2023
 <mailto:Jack Allen McKesson com> Jack Allen McKesson com 

Confidentiality Notice: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and may contain
confidential and privileged information.  Any unauthorized review, use,
disclosure or distribution is prohibited.  If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all
copies of the original message.

-- 
redhat-list mailing list
unsubscribe mailto:redhat-list-request redhat com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]