On Fri, May 18, 2012 at 11:23 AM, John R Pierce wrote:
> On 05/18/12 10:09 AM, Michael Coffman wrote:
> > 99 2425 1 4052 136382123488
> /opt/ictools/64bit/synopsys-aserver/bin/AServer
> ^^
>
> well, I dunno what that process is, but thats a HUGE vsiz
On 05/18/12 10:09 AM, Michael Coffman wrote:
> 99 2425 1 4052 136382123488
> /opt/ictools/64bit/synopsys-aserver/bin/AServer
^^
well, I dunno what that process is, but thats a HUGE vsize.
--
john r pierceN 37, W 122
sa
On Fri, May 18, 2012 at 10:39 AM, Les Mikesell wrote:
> On Fri, May 18, 2012 at 11:24 AM, Michael Coffman
> wrote:
> >
> >> If you are already overcommitted, what do you expect to happen when
> >> you say not to allow that? The kernel doesn't have a really good way
> >> to handle that situation
On Fri, May 18, 2012 at 10:39 AM, Les Mikesell wrote:
> On Fri, May 18, 2012 at 11:24 AM, Michael Coffman
> wrote:
> >
> >> If you are already overcommitted, what do you expect to happen when
> >> you say not to allow that? The kernel doesn't have a really good way
> >> to handle that situation
On Fri, May 18, 2012 at 10:39 AM, Les Mikesell wrote:
> On Fri, May 18, 2012 at 11:24 AM, Michael Coffman
> wrote:
> >
> >> If you are already overcommitted, what do you expect to happen when
> >> you say not to allow that? The kernel doesn't have a really good way
> >> to handle that situation
On Fri, May 18, 2012 at 11:24 AM, Michael Coffman
wrote:
>
>> If you are already overcommitted, what do you expect to happen when
>> you say not to allow that? The kernel doesn't have a really good way
>> to handle that situation (or any other OOM condition for that
>> matter...).
>>
>>
> OK. S
On Fri, May 18, 2012 at 7:50 AM, Les Mikesell wrote:
> On Fri, May 18, 2012 at 8:46 AM, Michael Coffman
> wrote:
> >
> >> Just because one machine fails gracefully does not mean the next will.
> >>
> >
> > I don't even know what the above means.
> >
> >
> >> But really buy some ram for real. OR
On Fri, May 18, 2012 at 8:46 AM, Michael Coffman
wrote:
>
>> Just because one machine fails gracefully does not mean the next will.
>>
>
> I don't even know what the above means.
>
>
>> But really buy some ram for real. OR solve the real problem.
>>
>>
>
> Well that's just ridiculous. 'Real probl
On Fri, May 18, 2012 at 6:15 AM, John Stanley wrote:
> On Thu, 2012-05-17 at 13:08 -0600, Michael Coffman wrote:
>
> > vm.overcommit_ratio = 50
> ^^
>
> Try changing the commit ratio to a greater value (yes you can go over
> 100).
> Then sysctl -w vm.overcom
On Thu, 2012-05-17 at 13:08 -0600, Michael Coffman wrote:
> vm.overcommit_ratio = 50
^^
Try changing the commit ratio to a greater value (yes you can go over
100).
Then sysctl -w vm.overcommit_memory=2
Just because one machine fails gracefully does not me
Hello,
In general I am in the habit of turning off memory overcommit because I
believe it's a bad thing in a multi-user environment. This was never a
problem on rhel5 systems, but on rhel6, I am having issues.When I try
to set overcommit_memory=2, my system locks up. It basically behaves a
11 matches
Mail list logo