Date: Mon, 5 Feb 2001 18:43:08 -0800 (PST) From: Dan Phoenix <dphoenix@bravenet.com> To: Matt Dillon <dillon@earth.backplane.com> Cc: Alfred Perlstein <bright@wintelcom.net>, Jos Backus <josb@cncdsl.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: qmail IO problems Message-ID: <Pine.BSO.4.21.0102051837080.16117-200000@gandalf.bravenet.com> In-Reply-To: <200102060231.f162VL557466@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-459333415-981427388=:16117 Content-Type: TEXT/PLAIN; charset=US-ASCII Nope I have not tweaked any kernel variables other thatn the ones i tried temporarily and put back to normal afterwards. Ok i will recompile the kernel with 256 maxuser setting and recompile included is dmesg.boot from one of the machines.....not sure if that helps as much as info i found in dmesg...as this is just hardware info. Anyways here it is....should be back in a couple hours after basketball game to recompile the kernels on those 2 boxes 2 new settings. Thx for help as of this point. On Mon, 5 Feb 2001, Matt Dillon wrote: > Date: Mon, 5 Feb 2001 18:31:21 -0800 (PST) > From: Matt Dillon <dillon@earth.backplane.com> > To: Dan Phoenix <dphoenix@bravenet.com> > Cc: Alfred Perlstein <bright@wintelcom.net>, Jos Backus <josb@cncdsl.com>, > freebsd-hackers@FreeBSD.ORG > Subject: Re: qmail IO problems > > :ok of those commands some interesting info was from dmesg... > :on one machine i had > :file: table is full > :file: table is full > :file: table is full > :file: table is full > :file: table is full > :file: table is full > :file: table is full > :file: table is full > :file: table is full > :file: table is full > :file: table is full > :file: table is full > :file: table is full > : > :from dmesg > : > :on the other machine > :looutput: mbuf allocation failed > :nfs server 172.16.0.101:/bravenet1/home: not responding > :looutput: mbuf allocation failed > :looutput: mbuf allocation failed > :looutput: mbuf allocation failed > :nfs server 172.16.0.101:/bravenet1/home: is alive again > :looutput: mbuf allocation failed > :looutput: mbuf allocation failed > : > :i doubt that mbuf allocation failed was from the nfs server timeout that > :one time....but cannot be certain......this help you at all? > > This sheds a considerable amount of light on the problems... > methinks you may have a low 'maxusers' setting in the kernel > config. Read on. > > I still need the complete 'dmesg' output, or if it all scrolled off > due to the above errors, cat the '/var/run/dmesg.boot' file. > > You had systat -vm 1 output in the earlier emails, but not > 'vmstat 1' output for 20 seconds. That isn't as big a deal with > all the other info we have now, but still useful. > > > :[root@arwen qmail-1.03]# pstat -s > :Device 1K-blocks Used Avail Capacity Type > :/dev/ad0s1b 1048448 0 1048448 0% Interleaved > :[root@arwen qmail-1.03]# > : > :[root@elrond dphoenix]# pstat -s > :Device 1K-blocks Used Avail Capacity Type > :/dev/ad0s1b 528696 2032 526664 0% Interleaved > :[root@elrond dphoenix]# > > This indicates that you are not swapping or paging significantly, > which is good. We can cross that off the list of possible problems. > > :ps axlww > : > :included is ps.txt..... > :2 perl scripts running only on that machine at moment yet qmail queue keep > :getting larger....seems to be getting abit better but not that great > :either. > : > : (ps output not included in reply) > > The ps output indicates that you are running a relatively light process > load. The prime suspects are thus the file table and mbuf errors. > > These errors normally occur when you configure a much too low > 'maxusers' setting in the kernel config. Since you didn't provide > the complete dmesg output (cat /var/run/dmesg.boot), I can't tell > but I am guessing that you are either using the GENERIC kernel > directly, or you created a custom kernel but didn't tune the > 'maxusers' entry. > > For a machine doing the work this machine is doing, I recommend > a maxusers setting in the kernel config of 256. You need to rebuild > your kernel in that case. Have you ever built a kernel before? > I think all you may need to do is up 'maxusers' in the kernel > config and perhaps mess around with the number of mbuf clusters, > but I suspect increasing maxusers will do the trick. These > changes require recompiling the kernel. > > Also, to make sure... you haven't tweaked any other sysctl's, have > you? > > -Matt > --0-459333415-981427388=:16117 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="dmesg.boot" Content-Transfer-Encoding: BASE64 Content-ID: <Pine.BSO.4.21.0102051843081.16117@gandalf.bravenet.com> Content-Description: Content-Disposition: attachment; filename="dmesg.boot" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDEgVGhlIEZyZWVCU0QgUHJvamVjdC4N CkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwg MTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NA0KCVRoZSBSZWdlbnRzIG9m IHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVz ZXJ2ZWQuDQpGcmVlQlNEIDQuMi1TVEFCTEUgIzA6IEZyaSBGZWIgIDIgMTQ6 NDM6MDcgUFNUIDIwMDENCiAgICBkcm9vdEBhcndlbi5icmF2ZW5ldC5jb206 L3Vzci9vYmovdXNyL3NyYy9zeXMvR0VORVJJQw0KVGltZWNvdW50ZXIgImk4 MjU0IiAgZnJlcXVlbmN5IDExOTMxODIgSHoNCkNQVTogUGVudGl1bSBJSUkv UGVudGl1bSBJSUkgWGVvbi9DZWxlcm9uICg0OTguNzUtTUh6IDY4Ni1jbGFz cyBDUFUpDQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4Njcy ICBTdGVwcGluZyA9IDINCiAgRmVhdHVyZXM9MHgzODNmYmZmPEZQVSxWTUUs REUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0Us TUNBLENNT1YsUEFULFBTRTM2LE1NWCxGWFNSLFNTRT4NCnJlYWwgbWVtb3J5 ICA9IDI2ODM2OTkyMCAoMjYyMDgwSyBieXRlcykNCmF2YWlsIG1lbW9yeSA9 IDI1Njk3NDg0OCAoMjUwOTUySyBieXRlcykNClByZWxvYWRlZCBlbGYga2Vy bmVsICJrZXJuZWwiIGF0IDB4YzA0M2YwMDAuDQpQZW50aXVtIFBybyBNVFJS IHN1cHBvcnQgZW5hYmxlZA0KbWQwOiBNYWxsb2MgZGlzaw0KbnB4MDogPG1h dGggcHJvY2Vzc29yPiBvbiBtb3RoZXJib2FyZA0KbnB4MDogSU5UIDE2IGlu dGVyZmFjZQ0KcGNpYjA6IDxJbnRlbCA4MjQ0M0JYIGhvc3QgdG8gUENJIGJy aWRnZSAoQUdQIGRpc2FibGVkKT4gb24gbW90aGVyYm9hcmQNCnBjaTA6IDxQ Q0kgYnVzPiBvbiBwY2liMA0Kc3ltMDogPDg3NT4gcG9ydCAweDE0MDAtMHgx NGZmIG1lbSAweGZhMjAwMDAwLTB4ZmEyMDBmZmYsMHhmYTIwNDAwMC0weGZh MjA0MGZmIGlycSAxMSBhdCBkZXZpY2UgMTMuMCBvbiBwY2kwDQpzeW0wOiBO byBOVlJBTSwgSUQgNywgRmFzdC0yMCwgU0UsIHBhcml0eSBjaGVja2luZw0K c3ltMTogPDg3NT4gcG9ydCAweDE4MDAtMHgxOGZmIG1lbSAweGZhMjAxMDAw LTB4ZmEyMDFmZmYsMHhmYTIwNDQwMC0weGZhMjA0NGZmIGlycSAxMSBhdCBk ZXZpY2UgMTMuMSBvbiBwY2kwDQpzeW0xOiBObyBOVlJBTSwgSUQgNywgRmFz dC0yMCwgU0UsIHBhcml0eSBjaGVja2luZw0KZnhwMDogPEludGVsIFBybyAx MC8xMDBCLzEwMCsgRXRoZXJuZXQ+IHBvcnQgMHgxMDYwLTB4MTA3ZiBtZW0g MHhmYTAwMDAwMC0weGZhMGZmZmZmLDB4ZmEyMDUwMDAtMHhmYTIwNWZmZiBp cnEgMTAgYXQgZGV2aWNlIDE1LjAgb24gcGNpMA0KZnhwMDogRXRoZXJuZXQg YWRkcmVzcyAwMDo5MDoyNzo3MzpjMDpjMA0KZnhwMTogPEludGVsIFBybyAx MC8xMDBCLzEwMCsgRXRoZXJuZXQ+IHBvcnQgMHgxMDgwLTB4MTBiZiBtZW0g MHhmYTEwMDAwMC0weGZhMWZmZmZmLDB4ZmEyMDIwMDAtMHhmYTIwMmZmZiBp cnEgMTAgYXQgZGV2aWNlIDE2LjAgb24gcGNpMA0KZnhwMTogRXRoZXJuZXQg YWRkcmVzcyAwMDo5MDoyNzphZjozMDoxMw0KaXNhYjA6IDxJbnRlbCA4MjM3 MUFCIFBDSSB0byBJU0EgYnJpZGdlPiBhdCBkZXZpY2UgMTguMCBvbiBwY2kw DQppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjANCmF0YXBjaTA6IDxJbnRlbCBQ SUlYNCBBVEEzMyBjb250cm9sbGVyPiBwb3J0IDB4MTA1MC0weDEwNWYgYXQg ZGV2aWNlIDE4LjEgb24gcGNpMA0KYXRhMDogYXQgMHgxZjAgaXJxIDE0IG9u IGF0YXBjaTANCmF0YTE6IGF0IDB4MTcwIGlycSAxNSBvbiBhdGFwY2kwDQp1 aGNpMDogPEludGVsIDgyMzcxQUIvRUIgKFBJSVg0KSBVU0IgY29udHJvbGxl cj4gaXJxIDExIGF0IGRldmljZSAxOC4yIG9uIHBjaTANCnVoY2kwOiBDb3Vs ZCBub3QgbWFwIHBvcnRzDQpkZXZpY2VfcHJvYmVfYW5kX2F0dGFjaDogdWhj aTAgYXR0YWNoIHJldHVybmVkIDYNCmNoaXAxOiA8SW50ZWwgODIzNzFBQiBQ b3dlciBtYW5hZ2VtZW50IGNvbnRyb2xsZXI+IHBvcnQgMHgxMDQwLTB4MTA0 ZiBhdCBkZXZpY2UgMTguMyBvbiBwY2kwDQpwY2kwOiA8Q2lycnVzIExvZ2lj IEdENTQ4MCBTVkdBIGNvbnRyb2xsZXI+IGF0IDIwLjANCmZkYzA6IDxORUMg NzIwNjVCIG9yIGNsb25lPiBhdCBwb3J0IDB4M2YwLTB4M2Y1LDB4M2Y3IGly cSA2IGRycSAyIG9uIGlzYTANCmZkYzA6IEZJRk8gZW5hYmxlZCwgOCBieXRl cyB0aHJlc2hvbGQNCmZkMDogPDE0NDAtS0IgMy41IiBkcml2ZT4gb24gZmRj MCBkcml2ZSAwDQphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgw NDIpPiBhdCBwb3J0IDB4NjAsMHg2NCBvbiBpc2EwDQphdGtiZDA6IDxBVCBL ZXlib2FyZD4gZmxhZ3MgMHgxIGlycSAxIG9uIGF0a2JkYzANCmtiZDAgYXQg YXRrYmQwDQp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0IDB4M2Mw LTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2EwDQpzYzA6IDxT eXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMA0Kc2MwOiBW R0EgPDE2IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPg0Kc2lvMCBh dCBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IGZsYWdzIDB4MTAgb24gaXNhMA0K c2lvMDogdHlwZSAxNjU1MEENCnNpbzE6IGNvbmZpZ3VyZWQgaXJxIDMgbm90 IGluIGJpdG1hcCBvZiBwcm9iZWQgaXJxcyAwDQpwcGMwOiA8UGFyYWxsZWwg cG9ydD4gYXQgcG9ydCAweDM3OC0weDM3ZiBpcnEgNyBvbiBpc2EwDQpwcGMw OiBHZW5lcmljIGNoaXBzZXQgKEVDUC9QUzIvTklCQkxFKSBpbiBDT01QQVRJ QkxFIG1vZGUNCnBwYzA6IEZJRk8gd2l0aCAxNi8xNi84IGJ5dGVzIHRocmVz aG9sZA0KcGxpcDA6IDxQTElQIG5ldHdvcmsgaW50ZXJmYWNlPiBvbiBwcGJ1 czANCmxwdDA6IDxQcmludGVyPiBvbiBwcGJ1czANCmxwdDA6IEludGVycnVw dC1kcml2ZW4gcG9ydA0KcHBpMDogPFBhcmFsbGVsIEkvTz4gb24gcHBidXMw DQphZDA6IDYxNDlNQiA8UVVBTlRVTSBGSVJFQkFMTCBDWDYuNEE+IFsxMzMy OC8xNS82M10gYXQgYXRhMC1tYXN0ZXIgVURNQTMzDQphY2QwOiBDRFJPTSA8 SURFL0FUQVBJIENELVJPTSA0MFg+IGF0IGF0YTEtbWFzdGVyIHVzaW5nIFBJ TzQNCldhaXRpbmcgMTUgc2Vjb25kcyBmb3IgU0NTSSBkZXZpY2VzIHRvIHNl dHRsZQ0KTW91bnRpbmcgcm9vdCBmcm9tIHVmczovZGV2L2FkMHMxYQ0K --0-459333415-981427388=:16117-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSO.4.21.0102051837080.16117-200000>