[PATCH] Make LNT compatible with PostgreSQL

[Daniel Dunbar]

In the interest of making forward progress, I went ahead and installed
PostgreSQL (9.1, currently, which was what was in the repos for llvm.org's
current Linux) and have set up a new 'perf' database in the LNT
installation:

1. I'm currently doing a batch import of 2014-07's data.

2. I have set up the 'default' database to run a shadow import into the new
database, so any new submissions should go there -- assuming the shadow
import feature is still working. :)

As Tobias mentioned, we can always wipe later if it seems like a good idea.

Once 2014-07 has imported I will probably continue with a batch import of
all of 2014's data, so that we can compare the interactive performance a
bit.

 - Daniel



On Wed, Jul 30, 2014 at 12:26 PM, Tobias Grosser <tobias at grosser.es> wrote:

> On 30/07/2014 20:45, Daniel Dunbar wrote:
>
>> On Tue, Jul 29, 2014 at 9:56 PM, Tobias Grosser <tobias at grosser.es
>> <mailto:tobias at grosser.es>> wrote:
>>
>>     On 30/07/2014 00:30, Daniel Dunbar wrote:
>>
>>         Here are my thoughts on what we should do:
>>
>>
>>     Hi Daniel,
>>
>>     thanks for your feedback.
>>
>>
>>         1. Before doing anything substantial, I want to get Chris'
>>         patches to
>>         rerun tests with significant changes (~= a form of adaptive
>>         sampling)
>>         landed. I have high hopes for that approach in helping making
>>         results
>>         more reliable and actionable.
>>
>>
>>     Adaptive sampling is a very neat idea.
>>
>>     Out of interest. How does a database change require these changes?
>>       From my naive perspective, I would rather have a set of already
>>     running buildbots with some history to allow to understand the
>>     effectiveness of Chris' changes. Hence, having a stable database in
>>     place would be nice.
>>
>>
>> It doesn't, but if the changes work well there is some value in having
>> the data set be consistent, I thought. The other reason was that if the
>> changes have bugs or need tweaks, it would be nicer to sort out the
>> issues before bringing up a new database to keep things "clean" later.
>>
>
> We could still wipe the db after some experimental phase.
>
>
>          2. In the past, when bringing up new databases I have reimported
>>         some
>>         historical data using the JSON files that the server archives
>>         (as Chris
>>         noted). I could do that again here if useful.
>>
>>
>>     Sure. We have the last 500 builds going back to July 16 for the
>>     'clang -O3 builder'. That's 15 days history. Nothing huge, but just
>>     enough to get us history starting from the 3.5 branch.
>>
>>
>> The server actually has much more data than that, I have the files to
>> import back to 2012.
>>
>
> Amazing.
>
>          3. I'm not sure exactly when I will have time to bring up a
>>         PostgreSQL
>>         instance on llvm.org <http://llvm.org> <http://llvm.org>. I
>>
>>         would really love to move to a
>>
>>         PaaS solution like Heroku to make managing this kind of thing
>> easier
>>         (and easier to collaborate on), but we might not yet have the
>>         organizational clout for that.
>>
>>
>>     You seem very busy and Yi Kong has done a great job in moving LNT
>>     ahead the last months. Maybe he could help out with the installation
>>     work?
>>
>>
>> Undoubtedly, the problem with having the server on llvm.org
>> <http://llvm.org> currently is we have to manage access carefully and
>>
>> also be careful. If it was hosted elsewhere, we wouldn't need to worry
>> nearly as much about changes.
>>
>
> Right. Maybe someone has a virtual machine to do exactly this? Or the LLVM
> Foundation has funds to get such a virtual machine?
>
>          4. Last I looked, the llvm.org <http://llvm.org>
>>         <http://llvm.org> instance mostly had
>>
>>         polly related bots. It would be nice to start off with a more
>>         standard
>>         set of bots trying to cover the diversity of platforms, in the
>>         hopes of
>>         making the results more interesting to the larger community.
>>
>>
>>     Right, it is important that we get wider test coverage. On the other
>>     side, one server is just badly named:
>>
>>     http://llvm.org/perf/db___default/v4/nts/recent_activity
>>
>>     <http://llvm.org/perf/db_default/v4/nts/recent_activity>
>>
>>     Those are five machines building 'clang -O3' on X86 without any
>>     Polly involved. So for X86 at least one configuration is rather
>>     strongly tested.
>>
>>
>> Ah, ok. Can we rename that bot?
>>
>
> r214324
>
> This breaks all history on the perf builder so it would be in fact a good
> time to introduce a new database. ;-) (Possibly with old data reimported
> with matching builder names).
>
> Cheers,
> Tobias
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140801/d2e4add6/attachment.html>