[CRIU] [Users] socket will take at least 0.5 seconds to recovery after docker restore done
Yanbao Cui
yygcui at gmail.com
Fri Jul 17 08:50:15 PDT 2015
I use the latter one. And we integrade C/R functionality into Docker based
on https://github.com/SaiedKazemi/docker/wiki
And I found there is another one based on Docker 1.7
Did you guys test it and focus on the time consumed?
On Fri, Jul 17, 2015 at 10:45 PM, Saied Kazemi <saied at google.com> wrote:
> Are you doing external checkpoint restore, calling CRIU directly to dump
> and restore the container, or are you using native "docker checkpoint" and
> "docker restore" commands? If latter, did you integrate C/R functionality
> into Docker yourself?
>
> --Saied
>
>
> On Fri, Jul 17, 2015 at 5:56 AM, Yanbao Cui <yygcui at gmail.com> wrote:
>
>> I use docker 1.6.0 and 1.6.2, they all have this problem.
>>
>> the needed files are shared via NFS.
>>
>> On Fri, Jul 17, 2015 at 11:15 AM, Saied Kazemi <saied at google.com> wrote:
>>
>>> Which Docker version are you using to checkpoint and restore your
>>> containers? Also, for migration, are you manually copying the container to
>>> a target machine?
>>>
>>> --Saied
>>>
>>>
>>> On Tue, Jul 14, 2015 at 7:36 AM, Yanbao Cui <yygcui at gmail.com> wrote:
>>>
>>>> Correct my reply:
>>>>
>>>> _existing_ migrated connections hang.
>>>>
>>>> New connection (here I mean new socket or a new process, not as like
>>>> reconnection manually) is OK
>>>>
>>>>
>>>> Yanbao Cui <yygcui at gmail.com>于2015年7月14日 周二 22:07写道:
>>>>
>>>>> _existing_ migrated connections hang.
>>>>>
>>>>> New connection is OK
>>>>>
>>>>> Pavel Emelyanov <xemul at parallels.com>于2015年7月14日 周二 21:59写道:
>>>>>
>>>>>> On 07/14/2015 04:43 PM, Yanbao Cui wrote:
>>>>>> > Server is working always and waiting. It seems the client, which is
>>>>>> in the container, cannot send data out after restored.
>>>>>> >
>>>>>> > For TCP, yeah, the client try to reconnect manually.
>>>>>>
>>>>>> You mean that after restore new connect()-s hang for a while? Why do
>>>>>> these connect()-s happen?
>>>>>> Or _existing_ migrated connections hang?
>>>>>>
>>>>>> > The delay is happened after restore successful, although the
>>>>>> network is recovered
>>>>>> >
>>>>>> >
>>>>>> > Pavel Emelyanov <xemul at parallels.com <mailto:xemul at parallels.com>>于2015年7月14日
>>>>>> 周二 21:31写道:
>>>>>> >
>>>>>> > On 07/14/2015 04:15 PM, Yanbao Cui wrote:
>>>>>> > > Sorry for mistake.
>>>>>> > > For UDP, I mean the sever can receive the packet from client
>>>>>> again.
>>>>>> >
>>>>>> > So where's the 0.5 seconds delay? Server sleeps and doesn't
>>>>>> wake up, packets
>>>>>> > do not reach the server or something else?
>>>>>> >
>>>>>> > > Actually, I have analysis the tcpdump output, in my case, the
>>>>>> client try to reconnect
>>>>>> > > to the server again, but can not receive SYN+ACK, so it
>>>>>> re-transmission after 1 second
>>>>>> > > according to the client rule, and then try again.
>>>>>> >
>>>>>> > During migration we don't reconnect TCP (with regular SYN,
>>>>>> SYNACK, ACK sequence),
>>>>>> > do you reconnect them manually?
>>>>>> >
>>>>>> > -- Pavel
>>>>>> >
>>>>>>
>>>>>>
>>>> _______________________________________________
>>>> CRIU mailing list
>>>> CRIU at openvz.org
>>>> https://lists.openvz.org/mailman/listinfo/criu
>>>>
>>>>
>>>
>>
>>
>> --
>> Best Regards
>> Cui Yanbao | 崔言宝
>> --
>> 龍生玖天,豈能安於凡塵!
>>
>
>
--
Best Regards
Cui Yanbao | 崔言宝
--
龍生玖天,豈能安於凡塵!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20150717/1eaf883b/attachment.html>
More information about the CRIU
mailing list