Re: Problems with rpc.statd and PAE

看板FB_hackers作者時間18年前 (2007/08/13 14:38), 編輯推噓0(000)
留言0則, 0人參與, 最新討論串4/5 (看更多)
Don Lewis wrote: > On 31 Jul, Jo緌 Carlos Mendes Lu疄 wrote: > >> Hi, >> >> Sent this to -questions, but got no answer. Now I'll try -hackers... >> >> I've just configured my first server with 4G RAM. To use it, I had >> to select PAE in kernel config. I was a little bit troubled by it's >> advice not to use modules (is it that critical?), but got it running. >> >> But when it is running on PAE, NFS statd refuses to run: >> >> # /etc/rc.d/nfslocking start >> Starting statd. >> rpc.statd: unable to mmap() status file: Cannot allocate memory >> Segmentation fault >> # >> >> Using strace I found it was trying to mmap the status file, at >> /var/db/statd.status: >> >> open("/var/db/statd.status", O_RDWR) = 10 >> mmap(0, 268435456, PROT_READ|PROT_WRITE, MAP_SHARED, 10, 0) = -1 ENOMEM >> (Cannot allocate memory) >> >> It's really strange to have mmap len = 256M, specially because the >> file is always small. But it works without PAE, and do not work with >> PAE. And it is described in the handbook: >> >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html#STATD-MEM-LEAK >> > > I've been seeing this same problem for a long time on an 7.0-CURRENT > i386 machine with 1GB of RAM, and I'm not using PAE. I haven't > discovered any obvious cause for the problem. > It's a production file server, so I cannot make any test today, but this weekend I'll try to recompile statd to use less memory. Is there a good reason to map 256M at once? Jonny -- Jo緌 Carlos Mendes Lu疄 - Networking Engineer - jonny@jonny.eng.br _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
文章代碼(AID): #16l_nY00 (FB_hackers)
文章代碼(AID): #16l_nY00 (FB_hackers)