> > And that's where both improved scheduling and closer coordination would
> > help. Meaning I'd appreciate some advance warning if something big comes
> > down the pipeline, so we can shunt it to the right machine to deal with
> > it.
>
> Are there stats about memory, disk, and CPU usage for the previous build, upon
> which you can base decisions about which buildd to use?
Per-machine stats on disk and CPU usage are kept on each buildd. They are
also appended at the end of each log file. Peak virtual memory usage I
don't know how to measure per process group ... I've looked into that in
the past.
Currently, packages are taked by the buildds on a first come, first served
basis. Packages are taken off the top of the list (which is sorted by
package priorities, basically, and the number of packages waiting on a
particular other package doesn't currently enter into this). We'll need to
distribute at least the latest build space requirements to all machines,
or get it on the fly from buildd.debian.org where it can be gotten from
the logs easily. Just tailing the last successful log for a given package
would suffice, really.
A central blacklist of packages that make no sense to build on a slow
machine is already being distributed. But that's just a stopgap measure,
really.
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
