This request came in on May 27. It has 2624 rows all of which are bycoord requests. These are the slowest to parse. 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 it 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 around 18:00 The following is a diary of me watching this request process. If some faults occur this may provide a debugging and repair tutorial. {{{ # The program pstampdump can be used to list the contents of a fits table (ippdb02:work/20100527/5977) bills% pstampdump -simple web_1695.fits > dumpreq.txt (ippdb02:work/20100527/5977) bills% wc dumpreq.txt 2624 49856 256353 dumpreq.txt # Each row has a ROWNUM which must be unique in the file. (ippdb02:work/20100527/5977) bills% grep Collected psparse.5977.log | tail -n 1 Collected 1 rows beginning with row 100595. bycoord chip null null # it's working on the 1486th row now (ippdb02:work/20100527/5977) bills% grep -n 100595 dumpreq.txt 1486:100595 205.550874 28.351276 100 100 2 stamp 1 gpc1 bycoord chip null null null null y 0 0 search # We're up to 5123 jobs now. mysql> select count(*) from pstampJob where req_id >= 5977 and fault = 0 ; +----------+ | count(*) | +----------+ | 5123 | +----------+ 1 row in set (0.02 sec) mysql> select count(*) from pstampJob where req_id >= 5977 and fault = 0 and dep_id = 0; +----------+ | count(*) | +----------+ | 200 | +----------+ 1 row in set (0.02 sec) # where are we now? (ippdb02:work/20100527/5977) bills% date ; grep -n `grep Collected psparse.5977.log | tail -n 1 | awk '{print $7}'` dumpreq.txt Thu May 27 16:06:56 HST 2010 1665:100774 205.543583 28.359453 100 100 2 stamp 1 gpc1 bycoord chip null null null null y 0 0 search 1665 of 2564 64% # There are lots of dependents pending. The poll limit in pstamp pantasks is 256 so 1/4 of these are queued for updates. (ippdb02:work/20100527/5977) bills% pst -pendingdependent -simple | wc 1027 11297 94484 No faults in the pstamp or update pantasks as yet. }}}