[gmx-developers] upcoming downtime on Monday
Szilárd Páll
pall.szilard at gmail.com
Sat Sep 20 20:40:59 CEST 2014
Hi,
I can increase the memory of the VM, that's not an issue at all.
However, are we really using more than 3 GB of memory with just 5
executors? I was just checking the load and it looked like we maxed
out the memory even with four jobs running:
http://jenkins.gromacs.org/metrics/graph_all_periods.php?h=bs_centos63&m=load_one&r=week&s=by%20name&hc=0&mc=2&st=1411237442&g=mem_report&z=large&c=jenkins
--
Szilárd
On Sat, Sep 20, 2014 at 7:22 PM, Roland Schulz <roland at utk.edu> wrote:
> Hi,
>
> I think we also need to do something about the "Not enough memory." errors
> with which the MdrunTests sometimes fails. It is currently probably one of
> the leading causes of false positives. Example:
> http://jenkins.gromacs.org/job/Gromacs_Gerrit_5_0/958/. Not sure if it is
> enough to increase the memory or decrease the number of jobs executed in
> parallel.
>
> Roland
>
> On Thu, Sep 18, 2014 at 5:55 PM, Mark Abraham <mark.j.abraham at gmail.com>
> wrote:
>>
>>
>>
>> On Thu, Sep 18, 2014 at 8:09 PM, Roland Schulz <roland at utk.edu> wrote:
>>>
>>> Hi,
>>>
>>> I suggest we change the gerrit setting change.largeChange from 500 to
>>> 1000 (at what point the size bar is red).
>>
>>
>> Sounds good for the forseeable future. Not sure where it is - if you know,
>> please do it.
>>
>>>
>>> Also I think we should try harder to break changes into small easy
>>> reviewable patches. Changes such as: https://gerrit.gromacs.org/#/c/3471 are
>>> too big to be reviewed efficiencly.
>>
>>
>> True, but it'd be nice also if we were all a little more cooperative with
>> reviewing low-impact patches (e.g. clean up or file renaming that doesn't
>> change functionality) so that people aren't tempted to write monolithic
>> patches (where, when their ship comes in, they all come in at once...). For
>> example, having gone a fair way into development of 3471, David might
>> recognize that he could split that patch into
>> 1. move the existing functionality into the newly named files, get most of
>> the tools to call it from the new place in the old way
>> 2. import lmfit, change existing functionality to use it, add tests
>> 3. any genuinely new stuff (if any; not apparent to me right now)
>>
>> Patch 1 ought to be easy and fast to review (no functional changes), and
>> patch 2 should be faster to review than 1+2 altogether. Today, I did some
>> review on "new-seeming" code in 3471 that upon closer inspection was just
>> old code moved to a new file - had I submitted that part of my review, David
>> would likely have had to say "well, sure, but that's not code I wrote, or
>> that I'm working on here." The split of 1 & 2 would make that clear to
>> reviewers up front.
>>
>> That said, I've had poor experiences with (say)
>> https://gerrit.gromacs.org/#/q/topic:g-tune-pme-reform, where people have
>> reviewed some changes and not enough people have reviewed their pre-reqs,
>> etc. I have a bunch more (IMO) decently atomic commits for fixing tune-pme
>> sitting in a long-forgotten repo on a drive... I can't say
>> https://gerrit.gromacs.org/#/q/topic:bondeds has been a compelling
>> experience, either. I don't mean this as criticism of any one or any group -
>> but I do think that with more than 100 outstanding patches in Gerrit and a
>> long-time-average merge rate of about 2 per day
>> (https://gerrit.gromacs.org/#/q/project:gromacs+status:merged), we all need
>> to pitch in harder with review and review-response, and less on doing our
>> own cool new things.
>>
>> Mark
>>
>>> Roland
>>>
>>> On Mon, Sep 15, 2014 at 9:20 AM, Mark Abraham <mark.j.abraham at gmail.com>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> We now have gerrit 2.9.1 deployed, and bs_mac upgraded to Mavericks and
>>>> XCode 5.1. Everything should be usable, do yell if not! If bs_mac + icc
>>>> still misbehaves then we'll bump icc version or something.
>>>>
>>>> On Sun, Sep 14, 2014 at 7:32 PM, Roland Schulz <roland at utk.edu> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> we could install Gerrit-Trigger Jenkins-plugin 2.12-beta. It fixes the
>>>>> issue that the matrix job isn't canceled when a newer change is uploaded:
>>>>> https://issues.jenkins-ci.org/browse/JENKINS-24295
>>>>> We would need to build it ourselves because 2.12-beta-5 which will
>>>>> include the patch isn't out yet. Let me know - it should be easy for me to
>>>>> build it.
>>>>
>>>>
>>>> Sounds good. I am out of time for this today, but if you can build it
>>>> then we can deploy it without taking gerrit down.
>>>>
>>>> Mark
>>>>
>>>>> Roland
>>>>>
>>>>> On Sat, Sep 13, 2014 at 7:28 AM, Mark Abraham
>>>>> <mark.j.abraham at gmail.com> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> The Jenkins Mac build slave needs an OS upgrade to keep up with Xcode
>>>>>> versions, which we hope will fix the way the mac+icc CI build segfaults
>>>>>> occasionally. Rossen's going to do that on Monday. There's a newer Gerrit
>>>>>> version out that has a bug fix that I'm keen to use, so I'll also upgrade
>>>>>> Gerrit on Monday so we have less overall downtime. Jenkins and Redmine are
>>>>>> probably OK for now. We should bump our icc versions, but we don't need a
>>>>>> downtime for that. Anything else people can think of we should fix?
>>>>>>
>>>>>> Mark
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
>>>>> 865-241-1537, ORNL PO BOX 2008 MS6309
>>>>>
>>>>> --
>>>>> Gromacs Developers mailing list
>>>>>
>>>>> * Please search the archive at
>>>>> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
>>>>> posting!
>>>>>
>>>>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>>>>
>>>>> * For (un)subscribe requests visit
>>>>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
>>>>> or send a mail to gmx-developers-request at gromacs.org.
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
>>> 865-241-1537, ORNL PO BOX 2008 MS6309
>>>
>>> --
>>> Gromacs Developers mailing list
>>>
>>> * Please search the archive at
>>> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
>>> posting!
>>>
>>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>>
>>> * For (un)subscribe requests visit
>>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
>>> or send a mail to gmx-developers-request at gromacs.org.
>>
>>
>
>
>
> --
> ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
> 865-241-1537, ORNL PO BOX 2008 MS6309
>
> --
> Gromacs Developers mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers or
> send a mail to gmx-developers-request at gromacs.org.
More information about the gromacs.org_gmx-developers
mailing list