Re: Problem with Lenny
Roman Gelfand put forth on 2/2/2010 9:48 AM:
> A lot of spam attempts.
Post your process list. You're probably (unnecessarily) running out of memory
due to too many processes. Try setting "default_process_limit = 30" in
/etc/postfix/main.cf, reload postfix, and see if this helps the memory use
problem. It should have an impact.
You may also want to look into optimizing your policy daemons' memory footprint.
--
Stan
> 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: