[ovs-discuss] 答复: [ovs]deleting interfaces connnected to ports results in ovs-vswitchd memory growing
pengyi Peng(Yi)
pengyi.pengyi at huawei.com
Thu Apr 18 11:37:56 UTC 2013
I have tested in ovs1.7.3 and ovs1.9.0, but the problem still exists.
I find that in jsonrpc_run function, the ovs won't free the memory in variable rpc immediately if stream_send returns -EAGAIN .
And when the memory of ovs-vswitchd is growing after I delete all interfaces, stream_send will return -EAGAIN .
void
jsonrpc_run(struct jsonrpc *rpc)
{
if (rpc->status) {
return;
}
stream_run(rpc->stream);
while (!list_is_empty(&rpc->output)) {
struct ofpbuf *buf = ofpbuf_from_list(rpc->output.next);
int retval;
retval = stream_send(rpc->stream, buf->data, buf->size);
if (retval >= 0) {
rpc->backlog -= retval;
ofpbuf_pull(buf, retval);
if (!buf->size) {
list_remove(&buf->list_node);
ofpbuf_delete(buf); // the memory should be freed here normally
}
} else {
if (retval != -EAGAIN) {
VLOG_WARN_RL(&rl, "%s: send error: %s",
rpc->name, strerror(-retval));
jsonrpc_error(rpc, -retval);
}
break;
}
}
}
So, why stream_send returns -EAGAIN and how to free the memory in this situation?
-----邮件原件-----
发件人: Ben Pfaff [mailto:blp at nicira.com]
发送时间: 2013年4月18日 0:47
收件人: pengyi Peng(Yi)
抄送: discuss at openvswitch.org; Liuyongan; Zhangkun (K)
主题: Re: [ovs-discuss] [ovs]deleting interfaces connnected to ports results in ovs-vswitchd memory growing
On Wed, Apr 17, 2013 at 01:23:56AM +0000, pengyi Peng(Yi) wrote:
> When using ovs1.7.1, I find something strange:
>
> First, I create br-0 using "ovs-vsctl add-br br-0";
>
> Then, I create 1000 taps with "tunctl -t tap$i" and create 1000 ovs ports connected to tap (ovs-vsctl --timeout=5 --no-wait add-port br-0 tap$i vlan_mode=access tag=0 -- set interface tap$i type=system). At this time, the memory of ovs-vswitchd is about 19MB.
>
> After I delete all taps at one time, the memory of ovs-vswitchd is slowly growing with the count of ports decreasing. This moment, ovs keeps printing logs as below in ovs-vswitchd log:
I see that there are some memory leak fixes in branch-1.7. Could you
try the newest commit from that branch or, failing that, at least
upgrade to 1.7.3?
Thanks,
Ben.
More information about the discuss
mailing list