PS1 IPP Czar Logs for the week 2011-09-12 - 2011-09-18

(Up to PS1 IPP Czar Logs)

Monday : 2011-09-12

• Around 10am Bill finally got all of the pieces checked into the branch for the ppMops memory reduction fix. pantasks were restarted
• 11:00 adjusted pstamp.dependent.run task to not be so agressive at running. Should reduce the database load that it cause.
• 15:00 CZW: Reworked host definitions to be more equitable (hopefully) and to run the processors we have as hard as possible without crashing anything. New definitions for all servers are stored in /home/panstarrs/ipp/ippconfig/pantasks_hosts.input

Tuesday : YYYY.MM.DD

• 09:50 Mark (czar): removed from nebulous and processing stopped on ipp021 for Cindy to upgrade the motherboard.
• 13:00 ipp021 back online. Added back nebulous and pantasks.
• 15:10 ipp026 went down. Removed from nebulous list until back up. Kernel panic similar to what has happened before, Chris rebooted and added details to ipp026-crash-20110913. Put back into nebulous in same state as before: repair.
• 21:30 registration trouble, in pantasks.stdout.log and run manually

  crash for: ipp_apply_burntool_single.pl --exp_id 392018 --class_id XY04 --this_uri neb://ipp006.0/gpc1/20110914/o5818g0058o/o5818g0058o.ota04.fits --continue 10 --previous_uri neb://ipp006.0/gpc1/20110914/o5818g0057o/o5818g0057o.ota04.fits --dbname gpc1 --verbose
  

Wednesday : YYYY.MM.DD

• 06:00 Mark: stalled at o5818g0440o, ipp_apply_burntool_single.pl running for 8ks so killed.
  • stalled again o5818g0448o with check_burntool and ota27 but picked itself up. ipp018 was having trouble connecting to ipp007.0.
• 11:45 excessive CPU use by distribution pcontrol, restarted distribution.
• 12:00 diff faulting from error reading FITS file /data/ipp042.0/nebulous/48/67/1297415775.gpc1:ThreePi.nt:2011:09:14:o5818g0508o.392470:o5818g0508o.392470.wrp.254273.skycell.2361.049.mask.fits. Regenerated with

  perl ~ipp/src/ipp-20110622/tools/runwarpskycell.pl --warp_id 254273 --skycell_id skycell.2361.049 --redirect-output 
  

• 12:10 diffim (diff_id=165304) running on ipp026 for 46ks, ppSub hanging. Killed ppSub to fault and revert. ipp026 has had timeouts to ippb00,01,02 in the past (seen in dmesg, not sure when). Diff completed.
• 112:21-12:56 Serge: stopped pstamp; dumped ippRequestServer to /export/ippc17.0/ipp/mysql-dumps/ippRequestServer.20110914.sql ; all done in less than 2 minutes. Master coordinates: mysqld-bin.000610, 505678724. Dump copied to /export/ippc19.0/pstamp_replication. Stopped slave on ippc19. Dropped existing database on ippc19. Ingested dump. Changed master coordinates. Restarted slave.
• 12:30 Mark: stdscience pcontrol on ippc16 100%, restarting stdscience now that last night's data finished (and start habit of restarting regularly to see if improves rates). Waiting for jobs to finish.
• 13:10 took longer to flush stdscience than normal. Also a hanging warp on ipp026 (warp_id=254454). stdscience now restarted.
• 13:20 diffim repeatedly faulting (diff_id=165610, skycell_id skycell.0982.067) like described in PS1_IPP_czarLog_20110627 for LAP diff 141693. set quality=42, fault=0

  difftool -updatediffskyfile -diff_id 165610 -skycell_id skycell.0982.067 -set_quality 42 -set_fault 0 -dbname gpc1
  

• 14:16 Bill Experimenting with pantasks parameters in update pantasks changed LOADEXEC from default 5 seconds to 20 seconds. Upped POLLIMIT from 32 to 64. Goal is to see if the database load is reduced noticeably
• 14:18 Set LOADEXEC to 30 and POLLLIMIT to 32 in cleanup pantasks. Previous polllimit was 200 which is silly since the jobs are taking a long time.
• 14:34 It turns out thta LOADEXEC gets applied when the task is created and is not subsequently updated. Restarted update pantasks.
• 17:11 CZW: After wondering why none of the lapRuns were completing, I tracked down a stuck magicRun (magic_id = 204696). Since I could see jobs to do by calling magictool -toprocess, I tried resetting the book (magic.reset) in the distribution pantasks. This appears to have unstuck this magicRun.
• 18:00 Mark: 16 remain faulted in magicDS for ThreePi.nightlyscience from missing Skychip.psf table in the diffim CMFs.

  neb://ipp043.0/gpc1/destreak/ThreePi.nightlyscience/392499/diff/392499.mds.697053.165578.skycell.1338.011.log
  

  Regenerated CMF with

  perl ~ipp/src/ipp-20110622/tools/rundiffskycell.pl --redirect-output --diff_id 165578 --skycell_id skycell.1338.011
  

  with same odd/bad result.

• 21:48 CZW: I merged the registration bugfix into the working branch. This of course means that a bug popped up elsewhere. summit_copy.pl exited with a "CRASH" state, which seems to have left a bad entry in the book. Manually running the commands that crashed:

  summit_copy.pl --uri http://conductor.ifa.hawaii.edu/ds/gpc1/o5819g0063o/o5819g0063o36.fits --filename neb://ipp044.0/gpc1/20110915/o5819g0063o/o5819g0063o.ota36.fits --summit_id 388294 --exp_name o5819g0063o --inst gpc1 --telescope ps1 --class chip --class_id ota36 --bytes 51831360 --md5 5ce24a1da3a713695bfabd72fa6df8c8 --dbname gpc1 --timeout 600 --verbose --copies 2 --compress --nebulous
  summit_copy.pl --uri http://conductor.ifa.hawaii.edu/ds/gpc1/o5819g0065o/o5819g0065o04.fits --filename neb://ipp006.0/gpc1/20110915/o5819g0065o/o5819g0065o.ota04.fits --summit_id 388296 --exp_name o5819g0065o --inst gpc1 --telescope ps1 --class chip --class_id ota04 --bytes 49432320 --md5 6a33bfd0cab134dcfb2563431cabef3f --dbname gpc1 --timeout 600 --verbose --copies 2 --compress --nebulous
  

cleared up the problems, and burntool started running and finishing registration for subsequent exposures.

Thursday : 2011-09-15

Serge is czar

• 09:00 Serge: nightly processing finished but a few 3pi at destreak stage. Reverted 4 errors in publishing.
• 11:50 Serge: stopped, shutdown and restarted distribution
• 11:58 heather restarted stack. it crashed on me. I suspect it was because I was doing 'status' too frequently. I also added a small number of stacks for test: MD09.haf
• 14:23 CZW: restarted stdscience, partially to see if that would kick processing rates, partially to add a rate adjustment for the LAP monitor stage to see if that is overloading the database.
• 16:06 Serge: killed ppMops on ippc12 (-exp_name o5814g0052o)

Friday : YYYY.MM.DD

Saturday : YYYY.MM.DD

Sunday : YYYY.MM.DD