FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Red Hat Linux

 
 
LinkBack Thread Tools
 
Old 05-23-2011, 06:17 PM
"Allen, Jack"
 
Default 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
 
Old 05-31-2011, 10:15 PM
"Allen, Jack"
 
Default 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

--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
 
Old 06-01-2011, 05:06 PM
Yong Huang
 
Default Limiting systems buffers

> 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?

(While waiting for expert advice...) I think you can lower
/proc/sys/vm/pagecache and swappiness. But I heard pagecache may not
work in newer kernels.

The real problem is, applications make memory dirty, unnecessarily. Let's
say I copy a big file, or gzip it. Lots of memory pages will become
dirty and they'll be written to disk. If the application (cp, gzip, or
your Storix) can open files with O_DIRECT option, then the filesystem
page cache won't be used.

Otherwise, we could use a filesystem that allows direct I/O mount option.
I know ext2 or ext3 doesn't support it. (Linus doesn't like the idea.)

Yong Huang

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

Thread Tools




All times are GMT. The time now is 12:49 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org