Closed Bug 396064 Opened 13 years ago Closed 13 years ago

9/4 Talos tp regression

Categories

(Core :: General, defect, blocker)

x86
Windows XP
defect
Not set
blocker

Tracking

()

RESOLVED FIXED

People

(Reporter: pavlov, Unassigned)

References

()

Details

(Keywords: perf, regression)

Attachments

(1 file)

There are two regressions shown -- one on 8/31 and one on 9/4.  The 8/31 one seemed to have gone away -- not sure if there was a backout or not.

The initial regression shows on qm-pxp01.  We started running qm-pxp03 in parallel after the regression had started to confirm the numbers we saw and have gone back and run historical numbers on qm-pxp03 (and are waiting on several more days worth of numbers) but based on both graphs, I believe it is fair to say that there is a real regression.
We believe that 383183 caused at least part of the regression and will try backing it out shortly.
Depends on: larry
backing out larry (bug 396064) seems to have resulted in about a 10ms average drop.  Still looking for the rest...
Attached image regressing sites
attached we see sites that were fixed on 09/03, but regressed again on 09/04
It is possible to correlate rises and falls in clarin.com with test box outages.

Is there a VNC or RDP session open on the box?
All of these pages are pretty long, too. Maybe there is a difference in window size?
I take it in comment 2 you meant bug 383183.
Upping severity since we have the tree closed for this.
Severity: normal → blocker
OK, I checked these sites from 8/31 to 9/14, and the sites in attachment 280855 [details] have maintained elevated Tp times. I will add more data from before 8/31.
this is fixed with a reboot of the windows Tp machine. clarin.com and related sites have gone back to normal.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.