| | 120 | processing effectively stopped around 6am this morning, though the |
| | 121 | full analysis was not complete: |
| | 122 | |
| | 123 | * there are a number of chipRuns that have not finished: 37 exposures |
| | 124 | are still pending. This is basically because of point 2: |
| | 125 | |
| | 126 | * ipp014 is unhappy: it is not so unhappy that it has been kicked out |
| | 127 | of nebulous, but files on it are giving I/O errors. The failing chips |
| | 128 | are being caused by this, but coupled to a lingering nebulous error: |
| | 129 | the rules are forcing nebulous to return the ipp014 instance rather |
| | 130 | than randomize among the instances. i'm going to reboot ipp014 and |
| | 131 | kick it out of nebulous for now. |
| | 132 | |
| | 133 | I'm attaching a snapshot of the ganglia load for the past 24 hours. |
| | 134 | you can see where the test started a bit before noon yesterday with |
| | 135 | the initial set of machines, and then the point where I crashed |
| | 136 | pantasks and restarted with and additional set of wave 2, 3, and C |
| | 137 | machines. you can also see the problem machines caused by the |
| | 138 | nebulous distribution (ipp039 and a couple of the ipp04X machines), |
| | 139 | and the ones that have been giving occasional nfs issues (eg ipp016). |
| | 140 | I'm not certain if the latter issues are being cause by glitches in |
| | 141 | those raids, something equivalent to the causes of the ipp005 crashes, |
| | 142 | or because of poor data distribution. this is something we need to |
| | 143 | investigate. |
| | 144 | |
| | 145 | === update === |
| | 146 | |