<div dir="ltr"><div dir="ltr"><div>hmm, seems like we have hit the issue again, however in a different job now:</div><div>Latest logs: <a href="https://zuul.opendev.org/t/openstack/build/0565c3d252194f9ba67f4af20e8be65d">https://zuul.opendev.org/t/openstack/build/0565c3d252194f9ba67f4af20e8be65d</a></div><div>Link to the review where it occurred: <a href="https://review.opendev.org/c/osf/refstack-client/+/788743">https://review.opendev.org/c/osf/refstack-client/+/788743</a></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 6 Apr 2021 at 18:47, Clark Boylan <<a href="mailto:cboylan@sapwetik.org">cboylan@sapwetik.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Apr 6, 2021, at 9:11 AM, Radosław Piliszek wrote:<br>
> On Tue, Apr 6, 2021 at 6:02 PM Jeremy Stanley <<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.org</a>> wrote:<br>
> > Looking at the error, I strongly suspect memory exhaustion. We could<br>
> > try tuning xz to use less memory when compressing.<br>
<br>
Worth noting that we continue to suspect memory pressure, and in particular diving into swap, for random failures that appear timing or performance related. I still think it would be a helpful exercise for OpenStack to look at its memory consumption (remember end users will experience this too) and see if there are any unexpected areas of memory use. I think the last time i skimmed logs the privsep daemon was a large consumer because we separate instance is run for each service and they all add up.<br>
<br>
> <br>
> That was my hunch as well, hence why I test using gzip.<br>
> <br>
> On Tue, Apr 6, 2021 at 5:51 PM Clark Boylan <<a href="mailto:cboylan@sapwetik.org" target="_blank">cboylan@sapwetik.org</a>> wrote:<br>
> ><br>
> > On Tue, Apr 6, 2021, at 8:14 AM, Radosław Piliszek wrote:<br>
> > > I am testing whether replacing xz with gzip would solve the problem [1] [2].<br>
> ><br>
> > The reason we used xz is that the files are very large and gz compression is very poor compared to xz for these files and these files are not really human readable as is (you need to load them into journald first). Let's test it and see what the gz file sizes look like but if they are still quite large then this is unlikely to be an appropriate fix.<br>
> <br>
> Let's see how bad the file sizes are.<br>
> If they are acceptable, we can keep gzip and be happy.<br>
> Otherwise we try to tune the params to make xz a better citizen as<br>
> fungi suggested.<br>
> <br>
> -yoctozepto<br>
> <br>
><br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Martin<br></div></div></div>