A lot of spam attempts. On Tue, Feb 2, 2010 at 5:13 AM, Stan Hoeppner <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>>>> On 2010-01-21, Stan Hoeppner <[email protected]> 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) ([email protected]) (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 [email protected] >>>>> with a subject of "unsubscribe". Trouble? Contact >>>>> [email protected] >>>>> >>>>> >>>> >>>> >>> >>> >>> -- >>> To UNSUBSCRIBE, email to [email protected] >>> with a subject of "unsubscribe". Trouble? Contact >>> [email protected] >>> >>> >> >> > > > -- > To UNSUBSCRIBE, email to [email protected] > with a subject of "unsubscribe". Trouble? Contact [email protected] > >
-- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
