> Thought would be easy to use the production master > & slaves and the production memory dump would give real scenario.
Sure. Easier. And by all means, I don't mind ... if just once. I would just hate to see our production server progressively become the Hudson project's "test server" ... they should have their own test server :) (complete with slaves, tough jobs, variable loads, variable file systems, unit tests, functional tests, etc.) ... but this one case makes a lot of sense, since it is an urgent problem and debugging the live production server sounds like an easy and prudent thing to do. I hope it helps ... the "load", the exact jobs ran, etc., will likely differ quite a bit from day to day, week to week, depending on phase of dev. cycle, so hope you "capture" what you need. Is there a bug open for this, so the interested can track progress and results? (I searched, but didn't see anything obvious) Good luck! Sincerely. Thanks so much for helping! From: Winston Prakash <[email protected]> To: Cross project issues <[email protected]>, Date: 02/17/2012 12:42 PM Subject: Re: [cross-project-issues-dev] Hudson testing next week Sent by: [email protected] Actually I need only one restart, some time this weekend. I want to capture the memory dump from the live instance for few days to analyze the progressive memory leaks. I needed the restart because in the current instance the memory is already saturated. My initial analysis tells me the memory leaks happen when builds are delegated to slaves. Main reason I want to capture the memory dump from the production instance is because it has several slaves and lots of builds are done on these slaves. If we set up sandbox then we need to find several slaves. Thought would be easy to use the production master & slaves and the production memory dump would give real scenario. - Winston On 2/17/12 6:28 AM, David M Williams wrote: >> If you have any questions please feel free to ask. > Well ... since you asked us to ask ... :) > > Why not use "sandbox" for this? I know this might take a little more > initial work; back level sandbox, make sure same plugins installed, copy > production configs over to sandbox (saving what ever is in sandbox config > first, naturally). And then if problem is not reproducible there, then yes, > might have resort to using the production server ... but, seems sandbox > would the the first choice to test on? > > I certainly have no objections to improving Hudson, and using production > server to do so, if needed, but it seems overall, long term, there might > be lots of occasions where a "test server" would be needed to track down a > bug, so seems a solution that didn't depend on the production server to > track it down would be preferable. Maybe that's already been tried and the > environments are just too different? but figured it was worth asking. > Using the sandbox might be easier for you and Hudson team long term, since > you could start/stop/experiment a little more freely without worrying about > disrupting on going production work? > > I'd understand if it was decided it was not possible, that sandbox > environment is just too different, but thought the obvious question should > be asked explicitly, and I hope these comments are helpful, > > > > > > > From: "Webmsaster(Matt Ward)"<[email protected]> > To: [email protected], > Date: 02/17/2012 08:59 AM > Subject: [cross-project-issues-dev] Hudson testing next week > Sent by: [email protected] > > > > Hi Folks, > > The Hudson team has found evidence of a memory leak and have asked if > next week(after SR2) if it would be possible to restart our Hudson > instance a few times in order track it's progression. My plan is to > announce the restarts here(as we do for any planned restart). > > Hopefully this will help improve everyones Hudson experience. > > If you have any questions please feel free to ask. > > -Matt. > _______________________________________________ > cross-project-issues-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > > _______________________________________________ > cross-project-issues-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
