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 <s...@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 <s...@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.li...@gmail.com> wrote: >>>>>> On 2010-01-21, Stan Hoeppner <s...@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) (da...@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-requ...@lists.debian.org >>>>>> with a subject of "unsubscribe". Trouble? Contact >>>>>> listmas...@lists.debian.org >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org >>>> with a subject of "unsubscribe". Trouble? Contact >>>> listmas...@lists.debian.org >>>> >>>> >>> >>> >> >> >> -- >> To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org >> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org >> >> > > -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
