Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Infra performance and how to boost?

Hi Martin,

Thanks for the suggestion. We have been battling the git cloning speed for a while. Just this week I found the root cause and for the last while a workaround has been running. You can follow progress on this issue in Bug 560283

We haven't had a single failure due to git since implementing an earlier version of the workaround described in Comment 18. I will be rolling out Comment 18 everywhere soon.

The summary of the underlying problem is that the container that the git fetch was done is very limited, just .1 CPU and 256M ram. With that little cpu/ram sometimes the fetch simply fails, not surprising given the pack file itself is > 200M and git likes memory a lot!

The mitigation around the Jenkins bug (JENKINS-30600) is to use sh to do the git fetch in the main container which has >1 CPU and >1G ram. When the Kubernates cluster (presumably) is not overloaded, the full depth fetch takes < 30 seconds (git fetch stage in recent build)

Finally, we can't do a shallow fetch on the check_cleanliness job, the one that was failing most, as that job needs the last commit time for each plug-in to generate and check version numbers.

----

That said - there have been a LOT of timeouts and slow downs. This seems to have gotten much worse recently. I have been considering how to run with a lot less tests in the gerrits - it is incredibly frustrating to have a gerrit that spends 1+ hour running irrelevant (to the change) tests, and worse of all reports unstable or worse!

For me it is very motivating that other people are interested in this and I appreciate your feedback, like changing some of the gerrit plug-in settings. I think I will change the gerrit jobs so that the CDT UI and CDT Other ones don't run when they are useless (like cmake, terminal etc changes - the EPP project has a clever script that I am going to adapt). On the unlikely case that a regression gets merged in that case the test failure will be reported by master build and we can take corrective action.

Short summary - I don't want to see another unstable report on AutomatedIntegrationSuite.testBuildAfterSourcefileDelete or similar. 

Please follow and contribute to this in Bug 499777 and its dependencies. I am just about to make one for handling the running less tests I mentioned above.

Jonah


~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Sat, 30 May 2020 at 13:25, 15 knots <fifteenknots505@xxxxxxxxx> wrote:
Hi all,

it seems gerrits verification jobs are often suffering from time-out during git check-out.

I would suggest to modify at least the jenkins verification builds to use git´s *shallow clone* feature for checkout.

I did a Q&D comparison of shallow vs. non shallow checkout. Here are the results:

## shallow
 > time git clone -b master git://git.eclipse.org/gitroot/cdt/org.eclipse.cdt.git --depth=1
real    0m27,439s
user    0m1,592s
sys     0m0,947s

## non-shallow
 > time git clone -b master git://git.eclipse.org/gitroot/cdt/org.eclipse.cdt.git
real    2m40,427s
user    0m20,746s
sys     0m3,541s

Note that in both cases the download rate was at the maximum (15.2 MB/s) of my ISP connection (according to KDE´s network monitor).

The following roughly shows the disk space needed for git history data in both cases:
 
## shallow
 > du -hs org.eclipse.cdt-shallow/.git
40M     org.eclipse.cdt-shallow/.git

## non-shallow
 > du -hs org.eclipse.cdt/.git
253M    org.eclipse.cdt/.git

WDYT?

Martin
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev

Back to the top