Re: Problem with Lenny
A lot of spam attempts.
On Tue, Feb 2, 2010 at 5:13 AM, Stan Hoeppner <stan@hardwarefreak.com> wrote:
> Roman Gelfand put forth on 2/1/2010 11:48 PM:
>> I use this the virtual machine as mail gateway. I run postfix,
>> sqlgrey, opendkim, senderid milter, dspam, grossd, policyd-weight.
>>
>> I gave this machine 2gig of memory. So far, so good. I have already
>> used it for couple of weeks and no issues.
>
> Is this the same VM you mentioned below that ran out of memory when you gave it
> 500MB?
>
> On my Lenny MX (which used to be only a postfix firewall/gateway but now stores
> mail locally) I run postfix+postgrey with some pretty large regexp and cidr
> tables (12,000+ cidr entries), dovecot, lighttpd, roundcube, samba, and
> pdns_recursor. This is a bare metal Debian system with only 384MB of RAM, of
> which over 200MB is normally system cache. It currently has over 100MB free
> memory. Granted, this is a very low volume box. That said...
>
> You must have one helluva mail stream going through that system to exceed 500MB
> of memory and have to kick it up to 2GB.
>
> --
> Stan
>
>
>> On Mon, Feb 1, 2010 at 9:36 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote:
>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
>>> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>>>
>>>
>>
>>
>
>
> --
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
Reply to: