Attending: Jens (chair+mins), Steve, Marcus, Matt, John H, John B, Daniel, Winnie, Brian, Rob C, Sam, Govind, Raul 0. Operational blog posts Hurrah for JohnB and Brian who have posted blog, er, posts. Fix for the ATLAS space reporting at QMUL: with the value set to -1 in the database, StoRM will apparently re-du the space. Files being deleted through DAV are still not being accounted but ATLAS are deleting through SRM. 1. We will have to do the ISGC summary next week, praps we can get RobA to summarise. There was also a GDB: http://indico.cern.ch/event/578984/ although it seems to be mostly computing focused. Brian points out the IPv6 talk may be of interest. 2. Hmm, we still have some keydocs that could do with a bit of an update. To name a few, those of StoRM and DPM (from 2014), and dCAche and suggestions for hardware are reporting a measly 15-20% completion... It seems there is still a need for having a hardware-for-the-SE type information page. For example, some people may want to run the database (for DPM) on the head node whereas others will want the database separate in which case there is obviously less requirement on the head node. Bristol found, with their StoRM, they had over-spec'd the head node because all the actual load was taken by the GridFTP servers. 3. Ends, loose: accounting, ZFS; there was an SKA kick off in den Haag (the Hague); "small" VOs (LZ?), IPv6 storage(?), data transfers Is anyone interested in commercial support for ZFS? Currently we don't need it but it may be relevant for future options. We haven't got any FreeNAS at the moment. There is a European project called AENEAS ("Advanced European Network of E-infrastructures for Astronomy with the SKA) which brings together data centres for radio astronomy and for "e-infrastructures"; in the UK participants are Cambridge, STFC, and Manchester, as well ask the "SKA organisation" itself. Apropos SKA, we might get someone who went to the the Hague meeting to come and talk to us but coming to think of it it is rather likely to appear on the GridPP agenda in a few weeks' time. Do we have any ready transfer performance numbers for the raw transfer capacity with GridFTP across GridPP sites? As in "we can move a terabyte in an hour" or something. It would need to be a performance we can sustain for more than a few minutes. Dan had numbers between QMUL and other sites, achieving 15 Gb/s. seemingly limited by some internal limit. This data was CMS data. Raul had done some tests with Simon and Duncan, getting 4Gb/s on IPv4 and aiming for 20Gb/s - and achieving 19 - on IPv6. ... no word on LZ...? IPv6 at GDB - sites to lose ATLAS "functionality" if not on IPv6 by Jan '19... LHCb's requests for IPv6 "ASAP", is that for T1s or also T2Ds? 4. If there's time perraps a word on the EGI/EUDAT/Indigo data infrastructure update?! and how they might be relevant to GridPP. There has been some slightly hacky progress but progress nonetheless on linking PRACE to EGI and EUDAT, where at least the latter uses IGTF X.509 certificates and GridFTP, so the process is the same as GridPP's and may therefore be relevant or at least of interest (we had a similar link demonstrated at the cloud workshop in December? last year, moving data between GridPP and EUDAT among others but again it was a bit hacky.) There is more stuff on connecting EGI and EUDAT but we shall get to that when we have a bit more time. 5. AOB Forgot to mention there is a data centre world in London today and tomorrow, it's out in Excel Matt Doidge: (15/03/2017 10:08:27) And good IO for the database! Paige Winslowe Lacesso: (10:08 AM) Thanks Sam, that's a vg explain - we've not run DPM in N (~large) years I sure hope someone's taking notes so I can point DrKreczko to this meeting notes about moving mysql off! raul: (10:11 AM) I move mysql to a separate host a year ago. huge reduction in load on HN. RHUL did the same a few weeks ago Marcus Ebert: (10:13 AM) I think a general recommendation is difficult since it depends on the size of the database (which grows with the used storage space) and also on the computing jobs on site that can run (and query the database) in parallel while not recommended, for us it works fine to run db on the headnode - which is in a VM Govind: (10:14 AM) i did it in last December. I re-indexed database same time to reduce the db size.. Marcus Ebert: (10:14 AM) to reduce the db size it's also good to have each table in its own file instead of a common one Brian @RAL-LCG2: (10:16 AM) https://en.wikipedia.org/wiki/FreeNAS Steve Jones: (10:17 AM) Yes; database layout optimisation is a field all on its own! Don't even talk about query optimisation - you could study it forever. Some people do. The best a normal admin can do is NOT to make terrible mistakes... Samuel Cadellin Skipsey: (10:19 AM) (DPM's puppet configurator for the db does some tuning itself, of course. But it doesn't do separate files for tables.) Marcus Ebert: (10:20 AM) is there a reason why it is not putting this line in the config? Samuel Cadellin Skipsey: (10:28 AM) Because it just hasn;t been added. Marcus Ebert: (10:29 AM) Ah, ok. Then is there a tracker page for feature requests, or just post to the dpm mailing list such things?