Changes between Version 2 and Version 3 of req_5977
- Timestamp:
- May 27, 2010, 4:14:43 PM (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
req_5977
v2 v3 1 This request came in on May 27. It has 2624 rows all of which are bycoord requests. These are the slowest to parse. 1 pstampRequest 5977 request was submitted through the web upload interaface on May 27. 2 The request file has 2624 rows all of which are bycoord requests for chip stage data. bycoord requests are the slowest to parse. 3 It takes on the order of 2 seconds per request row to process these. 2 4 3 The request started parsing at 13:38 HST May 27. We can see this because that is the time stamp on the request file. At 15:55 itis about half done. 4994 jobs have been queued so far and all but 200 are requests for cleaned up data. So the parsing will probably complete5 The request started parsing at 13:38 HST May 27. We can see this because that is the time stamp on the request file. At 15:55 parsing is about half done. 4994 jobs have been queued so far and all but 200 are requests for cleaned up data. So the parsing will probably complete 4 6 around 18:00 5 7 … … 35 37 1 row in set (0.02 sec) 36 38 39 40 # All but 200 of these are for data that has been cleaned. 41 37 42 mysql> select count(*) from pstampJob where req_id >= 5977 and fault = 0 and dep_id = 0; 38 43 +----------+ … … 44 49 45 50 # where are we now? 51 46 52 (ippdb02:work/20100527/5977) bills% date ; grep -n `grep Collected psparse.5977.log | tail -n 1 | awk '{print $7}'` dumpreq.txt 47 53 Thu May 27 16:06:56 HST 2010 … … 50 56 1665 of 2564 64% 51 57 52 # There are lots of dependents pending. The poll limit in pstamp pantasks is 256 so 1/4 of these are queued for updates. 58 # There are lots of dependents pending. The poll limit in pstamp pantasks is 256 so 1/4 of these have run and have queued 59 their updates. 53 60 54 61 (ippdb02:work/20100527/5977) bills% pst -pendingdependent -simple | wc 55 62 1027 11297 94484 56 63 57 No faults in the pstamp or update pantasks as yet. 64 No faults in the pstamp or update pantasks as yet. The update pantasks queue is full with chip processing and destreaking. 65 66 58 67 }}} 59 68
