Re: Problem with Lenny
Operating systems don't run themselves out of memory. Applications, processes,
do that. You need to identify why your application mix is consuming more memory
than is available on the system.
A couple of tips regarding virtual machines and guest operating systems:
1. If you're constantly running out of memory, use a dedicated box
2. If you're constantly running out of CPU, use a dedicated box
The entire concept behind virtualization is consolidating light-medium workloads
from many physical hosts to a single (more powerful) host, and enabling system
fault isolation--one consolidated server crashes and the rest keep running.
Roman, give this VM guest Lenny the maximum amount of memory you are allowed to
assign to a single VM, after kicking all other VMs off the hypervisor, and see
if you run out of memory. You likely will.
And it wouldn't hurt to tell us what applications/daemons/etc you're running on
this VM, since *THEY* are what's eating all the damn memory. If you want help,
we need the details.
--
Stan
Roman Gelfand put forth on 2/1/2010 11:16 AM:
> Ran out memory. This is my conclusion. Originally, I had given
> 500mb ram. Though top was showing 300mb utilization, memstat showed
> 1.1gig. It seems the later is the one I was supposed to pay attention
> to. I am currently looking into the difference between the top's
> memory utilization display and that of memstat.
>
> On Thu, Jan 21, 2010 at 9:40 PM, Jeffrey Cao <jcao.linux@gmail.com> wrote:
>> On 2010-01-21, Stan Hoeppner <stan@hardwarefreak.com> wrote:
>>> Roman Gelfand put forth on 1/20/2010 9:26 PM:
>>>> Jan 20 21:59:37 mail kernel: [ 0.000000] Linux version 2.6.26-2-686
>>>> (Debian 2.6.26-19lenny2) (dannf@debian.org) (gcc version 4.1.3
>>>> 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Wed Nov 4 20:45:37 UTC
>>>> 2009
>>>> My machine freezes every so often. I was wodering if there is any
>>>> clues in kernel.log exerpts below. Thanks in advance
>>>
>>> Define "freezes". Post the machine brand/model/specs.
>>>
>>>> Jan 20 21:59:37 mail kernel: [ 0.000000] SMP: Allowing 0 CPUs, 0 hotplug CPUs
>>>> Jan 20 21:59:37 mail kernel: [ 0.000000] PERCPU: Allocating 37992
>>>> bytes of per cpu data
>>>> Jan 20 21:59:37 mail kernel: [ 0.000000] NR_CPUS: 8, nr_cpu_ids: 1
>>>
>>> This ^^ is very odd. "Allowing 0 CPUs" is very strange. Given that, this
>>> "NR_CPUS: 8" is even more strange.
>> "NR_CPUS: 8" is not a strange thing. It's the number of CPUs that the kernel
>> supports, not the CPUs existed in the machine.
>>
>> config NR_CPUS
>> int "Maximum number of CPUs" if SMP && !MAXSMP
>> range 2 8 if SMP && X86_32 && !X86_BIGSMP
>> range 2 512 if SMP && !MAXSMP
>> default "1" if !SMP
>> default "4096" if MAXSMP
>> default "32" if SMP && (X86_NUMAQ || X86_SUMMIT || X86_BIGSMP || X86_ES7000)
>> default "8" if SMP
>> ---help---
>> This allows you to specify the maximum number of CPUs which this
>> kernel will support. The maximum supported value is 512 and the
>> minimum value which makes sense is 2.
>>
>> This is purely to save memory - each supported CPU adds
>> approximately eight kilobytes to the kernel image.
>>
>>>
>>>> Jan 20 21:59:37 mail kernel: [ 0.004000] Memory: 598724k/614336k
>>>> available (1770k kernel code, 14940k reserved, 750k data, 244k init,
>>>> 0k highmem)
>>>
>>> Also very strange ^^
>>>
>>> According to that above, your system has 0 smp cpus, but it has 8 cpus, and only
>>> one of those 8 has an ID. This also says you have ~600MB of system memory.
>>> There is no physical combo of DIMMs that yields 600MB so we can assume you have
>>> motherboard video chip and the BIOS is assigning system RAM for the frame
>>> buffer. But on a modern system, why do you have so little RAM installed?
>>>
>>> Unfortunately the system information provided by kern.log is incomplete. Please
>>> post output from dmesg so we can get a more complete picture of your system.
>>> Your kern.log info alone is not enough to diagnose what is causing your system
>>> to "freeze". Something to consider is that kernel issues usually cause panics,
>>> not freezes. If your system is freezing, or "hard locking", this is usually a
>>> sign of:
>>>
>>> 1. A thermal issue
>>> 2. Defective hardware
>>> 3. Hardware compatibility mismatch
>>>
>>> For comparison to your kern.log, I have a two CPU system, each a single core CPU:
>>>
>>> Jan 20 01:59:42 greer kernel: found SMP MP-table at [c00f5b90] f5b90
>>> Jan 20 01:59:42 greer kernel: SMP: Allowing 2 CPUs, 0 hotplug CPUs
>>> Jan 20 01:59:42 greer kernel: NR_CPUS:2 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1
>>>
>>
>>
>> --
>> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
>> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>>
>>
>
>
Reply to: