Problem with Lenny
in [Debian]
|
Prev: HTTP Filter Proxy
Next: Synchronize two computers
From: Stan Hoeppner on 1 Feb 2010 21:40 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(a)gmail.com> wrote: >> On 2010-01-21, Stan Hoeppner <stan(a)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(a)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(a)lists.debian.org >> with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org >> >> > > -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Roman Gelfand on 2 Feb 2010 00:50 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. On Mon, Feb 1, 2010 at 9:36 PM, Stan Hoeppner <stan(a)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(a)gmail.com> wrote: >>> On 2010-01-21, Stan Hoeppner <stan(a)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(a)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(a)lists.debian.org >>> with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org >>> >>> >> >> > > > -- > To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian..org > > -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Stan Hoeppner on 2 Feb 2010 05:20 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(a)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(a)gmail.com> wrote: >>>> On 2010-01-21, Stan Hoeppner <stan(a)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(a)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(a)lists.debian.org >>>> with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org >>>> >>>> >>> >>> >> >> >> -- >> To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org >> with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org >> >> > > -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Roman Gelfand on 2 Feb 2010 10:50 A lot of spam attempts. On Tue, Feb 2, 2010 at 5:13 AM, Stan Hoeppner <stan(a)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(a)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(a)gmail.com> wrote: >>>>> On 2010-01-21, Stan Hoeppner <stan(a)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(a)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(a)lists.debian.org >>>>> with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org >>>>> >>>>> >>>> >>>> >>> >>> >>> -- >>> To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org >>> with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org >>> >>> >> >> > > > -- > To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian..org > > -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Stan Hoeppner on 2 Feb 2010 19:30
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(a)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(a)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(a)gmail.com> wrote: >>>>>> On 2010-01-21, Stan Hoeppner <stan(a)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(a)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(a)lists.debian.org >>>>>> with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org >>>> with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org >>>> >>>> >>> >>> >> >> >> -- >> To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org >> with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org >> >> > > -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org |