Week of 160125

WLCG Operations Call details

  • At CERN the meeting room is 513 R-068.

  • For remote participation we use the Vidyo system. Instructions can be found here.

General Information

  • The purpose of the meeting is:
    • to report significant operational issues (i.e. issues which can or did degrade experiment or site operations) which are ongoing or were resolved after the previous meeting;
    • to announce or schedule interventions at Tier-1 sites;
    • to inform about recent or upcoming changes in the experiment activities or systems having a visible impact on sites;
    • to provide important news about the middleware;
    • to communicate any other information considered interesting for WLCG operations.
  • The meeting should run from 15:00 until 15:20, exceptionally to 15:30.
  • The SCOD rota for the next few weeks is at ScodRota
  • General information about the WLCG Service can be accessed from the Operations Web
  • Whenever a particular topic needs to be discussed at the daily meeting requiring information from site or experiments, it is highly recommended to announce it by email to wlcg-operations@cernSPAMNOTNOSPAMPLEASE.ch to make sure that the relevant parties have the time to collect the required information or invite the right people at the meeting.

Tier-1 downtimes

Experiments may experience problems if two or more of their Tier-1 sites are inaccessible at the same time. Therefore Tier-1 sites should do their best to avoid scheduling a downtime classified as "outage" in a time slot overlapping with an "outage" downtime already declared by another Tier-1 site supporting the same VO(s). The following procedure is recommended:
  1. A Tier-1 should check the downtimes calendar to see if another Tier-1 has already an "outage" downtime in the desired time slot.
  2. If there is a conflict, another time slot should be chosen.
  3. In case stronger constraints cannot allow to choose another time slot, the Tier-1 will point out the existence of the conflict to the SCOD mailing list and at the next WLCG operations call, to discuss it with the representatives of the experiments involved and the other Tier-1.

As an additional precaution, the SCOD will check the downtimes calendar for Tier-1 "outage" downtime conflicts at least once during his/her shift, for the current and the following two weeks; in case a conflict is found, it will be discussed at the next operations call, or offline if at least one relevant experiment or site contact is absent.

Links to Tier-1 downtimes

ALICE ATLAS CMS LHCB
  BNL FNAL  

Monday

Attendance:

  • local: Luca (SCOD+Storage), Maarten (ALICE), Jerome (Batch), Julia
  • remote: Stefano (CMS), Mark (LHCb), Francesco (CNAF), Rolf (IN2P3), Sang-Un (KISTI), Pavel (KIT), NDGF (Christian), Onno (NL-T1), Elizabeth (OSG), Jose (PIC), John (RAL), Di Qing (TRIUMF)

Experiments round table:

  • CMS reports (raw view) -
    • CERN/T0:
      • ALARM ticket GGUS:119030 voms-proxy-init failing on increasing numbers of lxplus node. Alarm ticket sent friday after lunch when all nodes were affected. Seems nobody else had noticed. Solved immediately by Steve Traylen.
      • xrootd server for EOS had wrong configuration, why ? Fixed this morning by restart: GGUS:118999
    • Distributed sites
      • All resources used, hit 150k running jobs (well over pledge) for a bit, does not have enough requests to keep more pressure.
      • No major problems to report

  • ALICE -
    • very high activity in the last days: up to 95k+ concurrent jobs today

  • LHCb reports (raw view) -
    • Data Processing
      • Mostly MC and User jobs
    • Site Issues
      • T0: NTR
      • T1:
        • CNAF : Minor issue with some nodes not having Machine Job Features installed
    • Miscellaneous
      • Stripping 24 to reprocess 2015 data hopefully starting tomorrow
      • Pre-staging of turbo data almost complete

Sites / Services round table:

  • ASGC:
  • BNL:
  • CNAF: (1) On 17/Feb and 18/Feb we planned a down of one of our electric power line (red line) for maintenance. Our electric power is redundant so all the services will stay online on the other line (green line). In any case during the intervention we will loose the redundancy and therefore we scheduled a downtime of the site (soon on the gocdb). We will keep on all the resources (job, storage, network, ...). (2) We are updating the version of gpfs client on the WN (to 4.1) to be compatible with the new storage we are installing. The operation is transparent but it requires a reboot of all wns. Even if we are doing it for groups of wns to avoid a disservice, a reduction of the resources available may happen during the transition.
  • FNAL:
  • GridPP:
  • IN2P3: NTR
  • JINR:
  • KISTI: NTR
  • KIT: NTR
  • NDGF: NTR
  • NL-T1:
    • We've declared a warning of a month in the GOCDB to remind people that we're going to move to a new datacenter in October. We'll be down for two weeks.
    • Follow-up on the spacemanager timeouts (GGUS:119025 and others). We think we have a better understanding of this issue, thanks to dCache developer Gerd Behrmann. Under heavy load, a database deadlock of SRM operations and/or space reservation transactions occurred. This is not unusual. Postgres detects a deadlock after 1 second and cancels the transactions. dCache then waits for a while and retries the transaction. This went wrong because of a combination of circumstances:
      • The wait time does not have a random component so many retries were done at the same time, often resulting in a deadlock again;
      • We use Postgres 9.2, which handles locks in a different way than 9.3 and later. From 9.3, some types of locks that are used by dCache are less intrusive, so they don't turn into deadlocks that often.
    • By setting the deadlock_timeout from 1s to 200ms, any backlog of transactions is processed much faster. This seems quite effective: LHCb reported that the problem disappeared a few minutes after we changed the value. Since we set this value, we haven't seen the space manager timeout anymore. That does not mean it couldn't happen again, but it seems we now have an effective "button" to push. Apart from that, we'll soon take these measures:
      • The dCache developers are fixing the backoff mechanism with random sleeps. We've planned a downtime on Feb 2 to install this fix.
      • We'll upgrade to Postgres 9.4 before May.
    • Again many thanks to Gerd Behrmann who was able to pinpoint the problem.
  • NRC-KI:
  • OSG: has been monitoring ATLAS and CMS activity carefully into the new year and has not seen any issues so far.
  • PIC: spurious problem with a CE that was affecting the SAM tests, no reports from the experiments
  • RAL: NTR
  • TRIUMF: NTR

  • CERN batch and grid services: NTR
  • CERN storage services: NTR
  • Databases:
  • GGUS:
  • Grid Monitoring:
  • MW Officer:

AOB:

  • Thanks to all the sites who replied on their batch systems' config. BatchSystemsConfig is almost complete. NDGF is actively working on collecting the info from their multiple sites.
  • NB! GGUS Release this Wednesday 27/1 with ALARM tests as usual. Please comment in https://its.cern.ch/jira/browse/GGUS-1486 if you experience any problem with the release.

Thursday

Attendance:

  • local: Luca (SCOD+Storage), Sabine (ATLAS), Mark (LHCb), Maarten (ALICE), Jerome (Batch)
  • remote: Kenneth (CMS), Michael (BNL), Francesco (CNAF), David (FNAL), Christian (NDGF), Andrew (NLT1), Rob (OSG), Jose (PIC), John (RAL)

Experiments round table:

  • ATLAS reports (raw view) -
    • Sites Jamboree ongoing
    • Data reprocessing (2012 data) started yesterday; note: it involves staging RAW data from tape.
    • CREAM-CE instability reported (mysql connection errors) see GGUS:119144 Several sites impacted. How widespread is it ? Did something change in CREAM ?
      • Jerome: might be related with some wrong MySQL settings for the replay log and that has been fixed.

  • CMS reports (raw view) -
    • Really nothing in particular to report!
    • Still busy but not as busy as over the weekend; averaging about 100K jobs running in the system.
    • Shouldn't CERN be closing the test alarm ticket GGUS:119122 ?
      • Luca: the ticket was closed this morning around 8:46 CET

  • ALICE -
    • CASTOR authZ failures at CERN and RAL (GGUS:119070)
      • the client started using an option that is not supported by the old authZ plugin used by CASTOR
      • upgrading that component did not fix the problem
      • investigations continue
    • myproxy.cern.ch intervention left the service unusable (GGUS:119152)
      • quickly fixed, thanks!

  • LHCb reports (raw view) -
    • Data Processing
      • Mostly MC and User jobs
    • Site Issues
      • T0:
        • Issue with one of the CEs losing jobs. Now fixed. (GGUS:119136)
      • T1:
        • CNAF: Problems with checksums with uploading files (GGUS:119127)
        • PIC: Some issues with getting TURLS from SURLS due to a badly behaving pool node (GGUS:119068)
    • Miscellaneous
      • Stripping 24 was started this afternoon

Sites / Services round table:

  • ASGC:
  • BNL: NTR
  • CNAF: NTR
  • FNAL: NTR
  • GridPP:
  • IN2P3: (Rolf offline) update on GGUS:118972 regarding dCache that led to the discovery of a bug, registering files in Chimera as "migrated" in spite of migration failures. The bug has been already eliminated, however there still entries in chimera without the corresponding file.
  • JINR:
  • KISTI:
  • KIT:
  • NDGF: NTR
  • NL-T1: NTR
  • NRC-KI:
  • OSG: Another case of ticket (GGUS:119142) which is open against OSG for SAM test failing and few debug information are present in the ticket.
    • the matter is being followed up offline
  • PIC: NTR
  • RAL: Hypervisor hosting 2 VOBoxes and the site bdii crashed
  • TRIUMF:

  • CERN batch and grid services: NTR
  • CERN storage services: NTR
  • Databases:
  • GGUS:
  • Grid Monitoring:
  • MW Officer:

AOB:

  • Note: Mon-Wed next week the WLCG Workshop will be held in Lisbon.
  • The next ops meeting will be held on Thursday next week!
Edit | Attach | Watch | Print version | History: r19 < r18 < r17 < r16 < r15 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r19 - 2016-01-28 - LucaMascetti
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LCG All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback