This is consistent with what I've observed, but it's nice to have confirmation.
Here's the current swap configuration: Filename Type Size Used Priority /dev/dasdd1 partition 516136 40360 -1 /dev/dasdf1 partition 1032460 11732 -2 At the request of another, I supplied /proc/meminfo in a separate post. Note that the above reflects the current (idle) state of the instance. We have another load test scheduled this week, so we hope to get some more info then. > -----Original Message----- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of > Alan Cox > Sent: Wednesday, August 30, 2006 9:06 AM > To: [email protected] > Subject: Re: [LINUX-390] Swap partition "filling up" on RHEL4 > > > Ar Mer, 2006-08-30 am 08:21 -0400, ysgrifennodd Hall, Ken (GTI): > > We've been going around trying to figure out: 1) why we suddenly > > should have run out of virtual memory (if we did, because we never > > even got close to that before), and 2) why it was reported in this > > way. Does anyone know if there's anything in the swap space > > management mechanism that would cause Linux to fail malloc > if a single > > swap partition fills up? Is there some kind of process affinity for > > paging to swap spaces? > > #1 no idea - maybe you hit a worst case or a memory leak in it ? Java > and other garbage collectors are also a common source of large brief > spikes in memory usage. > > #2 Linux uses the swap according to the priority of the swap files and > swap partitions. When one fills it will move onto the next. Memory > allocations are failed according to the overcommit settings. > > The default behaviour is "fail allocations that will obviously fail". > This allows overcommit of resources (so you can get process > kills due to > out of memory) but tries to avoid obvious cases. > > A seperate mode is available which assumes all allocation requests > should be allowed until the box goes totally out of memory. > This is only > for specialist scientific applications > > The third mode prevents overcommit and will fail allocations > when it is > theoretically possible for an overcommit situation to occur, this is > used for high reliability environments where having to deploy > extra swap > "just in case" is preferable to, say, having your air traffic control > system self destruct. > > Alan > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: INFO > LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -------------------------------------------------------- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ -------------------------------------------------------- ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
