答复: 答复: [Samba] The memory maybe leak in samba 4.3.11
Zhangxiaoxu
zhang.xiaoxu at h3c.com
Wed May 10 01:52:49 UTC 2017
> What exact version are you using and
Version 4.3.11.
> what code did you add ?
I add some code in the 'queue_msg' function, if the length of the queue is more than 100, the msg will be droped.
So, it won't to malloc too much more memory for the msg.
The msgs is generated when 'ctdbd_migrate', I don’t whether it can be droped.
The messages may be too much, or the sokcet maybe too busy.
Now my application scene is:
There are 3 samba server nodes, 3 clients connect to different servers, every client write 64k to 30 files every 40ms.
If open the current folder with windows explorer in a client, the RES with top command of smbd in that server will grow up very very quickly.
top -d 1 -p 2708752 -b | grep smbd
2708752 nobody 20 0 701928 299184 18616 R 107.8 0.3 1:34.64 smbd
2708752 nobody 20 0 701928 299184 18616 R 112.9 0.3 1:35.77 smbd
2708752 nobody 20 0 701928 299184 18616 R 92.9 0.3 1:36.70 smbd
2708752 nobody 20 0 701928 299184 18616 R 101.8 0.3 1:37.72 smbd
2708752 nobody 20 0 701928 299184 18616 D 18.0 0.3 1:37.90 smbd
2708752 nobody 20 0 701928 299184 18616 D 0.0 0.3 1:37.90 smbd
2708752 nobody 20 0 701928 299184 18616 D 0.0 0.3 1:37.90 smbd
2708752 root 20 0 703336 300528 18616 R 35.0 0.3 1:38.25 smbd
2708752 nobody 20 0 707052 304196 18684 D 20.0 0.3 1:38.45 smbd
2708752 nobody 20 0 707052 304196 18684 D 0.0 0.3 1:38.45 smbd
2708752 nobody 20 0 707052 304196 18684 D 0.0 0.3 1:38.45 smbd
2708752 nobody 20 0 707052 304196 18684 D 0.0 0.3 1:38.45 smbd
2708752 nobody 20 0 720364 317564 18684 R 46.9 0.3 1:38.92 smbd
2708752 nobody 20 0 723360 320564 18564 R 87.9 0.3 1:39.80 smbd
2708752 nobody 20 0 724716 321916 18564 R 96.9 0.3 1:40.77 smbd
2708752 nobody 20 0 724716 321916 18564 R 112.8 0.3 1:41.90 smbd
2708752 nobody 20 0 724716 321916 18564 R 93.9 0.3 1:42.84 smbd
2708752 nobody 20 0 724716 321916 18564 R 100.8 0.3 1:43.85 smbd
2708752 nobody 20 0 724716 321916 18564 D 26.0 0.3 1:44.11 smbd
2708752 nobody 20 0 724716 321916 18564 D 0.0 0.3 1:44.11 smbd
2708752 nobody 20 0 724716 321916 18564 D 0.0 0.3 1:44.11 smbd
2708752 root 20 0 725484 322624 18564 R 17.0 0.3 1:44.28 smbd
2708752 nobody 20 0 734464 331480 18568 D 71.9 0.3 1:45.00 smbd
2708752 nobody 20 0 735456 332660 18568 R 90.9 0.3 1:45.91 smbd
2708752 nobody 20 0 736932 334140 18568 R 106.8 0.3 1:46.98 smbd
2708752 nobody 20 0 738496 335624 18568 D 48.0 0.3 1:47.46 smbd
2708752 nobody 20 0 738496 335624 18568 D 0.0 0.3 1:47.46 smbd
2708752 nobody 20 0 745548 342752 18568 R 68.9 0.3 1:48.15 smbd
2708752 nobody 20 0 747048 344120 18568 R 100.9 0.3 1:49.16 smbd
2708752 nobody 20 0 749148 346184 18568 D 52.9 0.4 1:49.69 smbd
2708752 nobody 20 0 749148 346184 18568 D 0.0 0.4 1:49.69 smbd
2708752 nobody 20 0 755772 352980 18568 R 74.9 0.4 1:50.44 smbd
2708752 nobody 20 0 756632 353840 18568 R 108.8 0.4 1:51.53 smbd
-----邮件原件-----
发件人: Jeremy Allison [mailto:jra at samba.org]
发送时间: 2017年5月10日 2:14
收件人: zhangxiaoxu 13123 (RD)
抄送: 'L.P.H. van Belle'; samba at lists.samba.org; 'samba-technical at lists.samba.org'
主题: Re: 答复: [Samba] The memory maybe leak in samba 4.3.11
On Tue, May 09, 2017 at 02:59:51AM +0000, Zhangxiaoxu via samba-technical wrote:
> Hi,
> Thanks a lot.
>
> Use the valgrind, we found the stack of the malloc as below, so, maybe it is not memory leak.
> ==2796353== 36,334,440 bytes in 100,929 blocks are still reachable in loss record 774 of 774
> ==2796353== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==2796353== by 0x953B88F: ??? (in /usr/lib/x86_64-linux-gnu/samba/libmessages-dgm.so.0)
> ==2796353== by 0x953BCA0: ??? (in /usr/lib/x86_64-linux-gnu/samba/libmessages-dgm.so.0)
> ==2796353== by 0x953C342: unix_msg_send (in /usr/lib/x86_64-linux-gnu/samba/libmessages-dgm.so.0)
> ==2796353== by 0x953E3B6: messaging_dgm_send (in /usr/lib/x86_64-linux-gnu/samba/libmessages-dgm.so.0)
> ==2796353== by 0x71732FF: messaging_send_iov_from (in /usr/lib/x86_64-linux-gnu/libsmbconf.so.0)
> ==2796353== by 0x716E1BA: ??? (in /usr/lib/x86_64-linux-gnu/libsmbconf.so.0)
> ==2796353== by 0x716E869: ??? (in /usr/lib/x86_64-linux-gnu/libsmbconf.so.0)
> ==2796353== by 0x716EA91: ??? (in /usr/lib/x86_64-linux-gnu/libsmbconf.so.0)
> ==2796353== by 0x7171207: ctdbd_migrate (in /usr/lib/x86_64-linux-gnu/libsmbconf.so.0)
> ==2796353== by 0x716BD6E: ??? (in /usr/lib/x86_64-linux-gnu/libsmbconf.so.0)
> ==2796353== by 0xAE6692F: ??? (in /usr/lib/x86_64-linux-gnu/samba/libdbwrap.so.0)
>
> Ifound the sendmsg is always failed because erron=EINTR, but smbd also need to malloc for the new msgs, so the res of the smbd grows up quickly.
>
> I add some code in unix_dgram_send_job, just send 10 times if sendmsg faild with EINTR, the res will not grows up anymore.
> Another, keep the max queue length to 100 also work well.
>
> I don’t know whether it is suitable for the process, also, I want to know why sendmsg return EINTR.
EINTR always means a signal was received and interrupted the send.
You're using 4.3.x yes ? In that branch:
static void unix_dgram_send_job(void *private_data) {
struct unix_dgram_msg *dmsg = private_data;
do {
struct msghdr_buf *hdr = unix_dgram_msghdr(dmsg);
struct msghdr *msg = msghdr_buf_msghdr(hdr);
dmsg->sent = sendmsg(dmsg->sock, msg, 0);
} while ((dmsg->sent == -1) && (errno == EINTR));
if (dmsg->sent == -1) {
dmsg->sys_errno = errno;
}
}
we already loop on EINTR. What exact version are you using and what code did you add ?
-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有杭州华三通信技术有限公司的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from H3C, which is
intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender
by phone or email immediately and delete it!
More information about the samba-technical
mailing list