Confirmed, no more leaks. I put it 1 hour ago onto 1 production server,
and today evening I'll put it to another one. Every server serves up to 2
million SMTP connections per day: load are heavy. Both servers SMP.
Gleb Smirnoff wrote:
GS> please confirm that the attached patch fix your problem.
On Tue, Oct 25, 2005 at 06:04:15PM +0200, Max Laier wrote:
M> On Tuesday 25 October 2005 17:00, Gleb Smirnoff wrote:
M> > Vladimir,
M> >
M> > please confirm that the attached patch fix your problem. The patch is
M> > relative to src/sys tree.
M> >
M> > Kris, Christian, please review it. Thank
On Tuesday 25 October 2005 17:00, Gleb Smirnoff wrote:
> Vladimir,
>
> please confirm that the attached patch fix your problem. The patch is
> relative to src/sys tree.
>
> Kris, Christian, please review it. Thanks.
Are you sure it's safe to free the nlminfo struct before calling to fdfree()
Vladimir,
please confirm that the attached patch fix your problem. The patch is relative
to src/sys tree.
Kris, Christian, please review it. Thanks.
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
Index: nfsclient/nfs_lock.c
=
Pete French wrote:
>> I found the sources of the leak: if exim accessess ANY configuration/text
>> files over NFS, there will be leak. And, how often exim will be called, then
>> quicker your system dies.
PF> Surely this has to be a problenm wth NFS in the kernel, not with exim
PF> though? Did
> I found the sources of the leak: if exim accessess ANY configuration/text
> files over NFS, there will be leak. And, how often exim will be called, then
> quicker your system dies.
Surely this has to be a problenm wth NFS in the kernel, not with exim
though? Did you log a FreeBSD PR on this ? I
I found the sources of the leak: if exim accessess ANY configuration/text
files over NFS, there will be leak. And, how often exim will be called, then
quicker your system dies.
My main problem now is to build near-realtime mirroring solution nfs-to-local
for around 20 files (up to 1Mb everything)
Kris Kennaway wrote:
>> Looks like kernel leak (thanks for tip to Gleb Smirnov) in lockf.
>> # vmstat -zm | grep lock
>> lockf 2257779 70556K - 19476940 32,64
>> ... and keep raising.
>>
>> That's another one machine with 1Gb RAM, having 512M for vm.kmem_size_max
>> too.
KK> OK,
On Sun, Oct 23, 2005 at 08:07:09PM +0300, Vladimir Sharun wrote:
> Kris Kennaway wrote:
> > >>> We have 2xOpteron/2Gb RAM server with extrensive disk load. Every week
> > >>> or two
> > >>> it suddenly hangs with "kmem_malloc(4096): kmem_map too small
> > >>> 335bla-bla allocated".
> > >>> I lo
Leak in lockf, confirmed:
lockf 80448 2516K - 709113 32,64
lockf 80450 2516K - 709155 32,64
lockf 80453 2516K - 709199 32,64
lockf 80452 2516K - 709207 32,64
lockf 80455 2516K - 709226 32,64
lockf 8045
Kris Kennaway wrote:
> >>> We have 2xOpteron/2Gb RAM server with extrensive disk load. Every week or
> >>> two
> >>> it suddenly hangs with "kmem_malloc(4096): kmem_map too small 335bla-bla
> >>> allocated".
> >>> I look onto handbook and put vm.kmem_size_max="536870912" onto
> >>> /boot/loader
On Sun, Oct 23, 2005 at 12:05:26PM +0300, Vladimir Sharun wrote:
> Kris Kennaway wrote:
> >> We have 2xOpteron/2Gb RAM server with extrensive disk load. Every week or
> >> two
> >> it suddenly hangs with "kmem_malloc(4096): kmem_map too small 335bla-bla
> >> allocated".
> >> I look onto handbook
Kris Kennaway wrote:
>> We have 2xOpteron/2Gb RAM server with extrensive disk load. Every week or two
>> it suddenly hangs with "kmem_malloc(4096): kmem_map too small 335bla-bla
>> allocated".
>> I look onto handbook and put vm.kmem_size_max="536870912" onto
>> /boot/loader.conf.
>> Today was th
On Sun, Oct 23, 2005 at 11:21:10AM +0300, Vladimir Sharun wrote:
> Kris Kennaway wrote:
> KK> On Sun, Oct 23, 2005 at 10:43:42AM +0300, Vladimir Sharun wrote:
> >> We have 2xOpteron/2Gb RAM server with extrensive disk load. Every week or
> >> two
> >> it suddenly hangs with "kmem_malloc(4096): km
Kris Kennaway wrote:
KK> On Sun, Oct 23, 2005 at 10:43:42AM +0300, Vladimir Sharun wrote:
>> We have 2xOpteron/2Gb RAM server with extrensive disk load. Every week or two
>> it suddenly hangs with "kmem_malloc(4096): kmem_map too small 335bla-bla
>> allocated".
>> I look onto handbook and put vm
On Sun, Oct 23, 2005 at 10:43:42AM +0300, Vladimir Sharun wrote:
> We have 2xOpteron/2Gb RAM server with extrensive disk load. Every week or two
> it suddenly hangs with "kmem_malloc(4096): kmem_map too small 335bla-bla
> allocated".
> I look onto handbook and put vm.kmem_size_max="536870912" ont
We have 2xOpteron/2Gb RAM server with extrensive disk load. Every week or two
it suddenly hangs with "kmem_malloc(4096): kmem_map too small 335bla-bla
allocated".
I look onto handbook and put vm.kmem_size_max="536870912" onto
/boot/loader.conf.
Today was the same with the new parameters. Is ther
17 matches
Mail list logo
