On 22 February 2017 at 20:36, Nadav Goldin <[email protected]> wrote: >> Since we cannot reproduce this, and we cannot easily stop using >> repoman in OST at this point. We implemented a work-around for the >> time being where we directed the master flow to run on a fixed set of >> nodes that have A LOT of RAM [3]. > > Take into account that this will significantly make the suites run > slower(+10 minutes), as iirc all those servers are multi-NUMA. Also > something must be really exploding, because the basic suite does not > take more than 10GB of ram, and most of the low memory servers have > around 48GB.
The alternative is to not run in RAM at all... >> filling up with files, instead, repoman`s memory usage was exploding >> (20G+) to the point where there was not more memory available for use >> by /dev/shm. > > I have a wild guess that this also happens because repoman does > post-filtering, and it first downloads all packages, then filters > them. If that was the case we would see used space in /dev/shm growing. We did not. > About node and appliance, I think we should avoid downloading them, > they are not used anywhere as far as I know. This filter should > work(in extra_sources) last I checked, i.e.: > rec:http://plain.resources.ovirt.org/repos/ovirt/tested/4.1/rpm/el7/:name~^(?!ovirt-node-ng-image|ovirt-engine-appliance).* > If it goes in the groovy it will need some regex escaping love.. > Though if my previous assumption is correct(post-filtering) it > probably wouldn't matter. Its gonna be hard to add this and also allow incorporating the node/HA suits at some point. -- Barak Korren [email protected] RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/ _______________________________________________ Infra mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/infra
