Open Stack

Hi,
I sent in my previous email what happens in the first lige migration:


*migration running for 30 secs, memory 89% remaining; (bytes
processed=1258508063, remaining=15356194816, total=17184923648)2022-08-05
10:47:23.910 55600 INFO nova.virt.libvirt.driver
[req-ff02667e-9d38-4a08-9c63-013ed1064218 66adb965bef64eaaab2af93ade87e2ca
85cace94dcc7484c85ff9337eb1d0c4c - default default] [instance:
d1aae4bb-9a2b-454f-9018-568af6a98cc3] Migration running for 60 secs, memory
87% remaining; (bytes processed=1489083638, remaining=15035801600,
total=17184923648)08-9c63-013ed1064218 66adb965bef64eaaab2af93ade87e2ca
85cace94dcc7484c85ff9337eb1d0c4c - default default] [instance:
d1aae4bb-9a2b-454f-9018-568af6a98cc3] Migration running for 90 secs, memory
86% remaining; (bytes processed=1689004421, remaining=14802731008,
total=17184923648)*

and so on

Tcpudumping from A to B I can see a lot traffic.

Do you suggest to enable debug ?
It seems clear that the memory content migration is slow.
Ignazio

Il giorno ven 5 ago 2022 alle ore 11:33 Radosław Piliszek <
radoslaw.piliszek at gmail.com> ha scritto:

> On Fri, 5 Aug 2022 at 11:06, Ignazio Cassano <ignaziocassano at gmail.com>
> wrote:
> >
> > Hi,
> > migration from A to B (750 sec)
> > migration from B to A (10 sec)
> > Migration from A to B (10 sec)
>
> Interesting! So it indeed looks like a dirty/cold case. However, as
> Gorka and others have already mentioned - you need to really pinpoint
> WHAT takes that long. Which involved component does its thing for too
> long.
> It could be that in these 740 secs there is actually no real
> throughput happening, just some thing waiting for timeout to progress
> on the 2nd try.
>
> -yoctozepto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20220805/7ff7d4ce/attachment-0001.htm>