Welcome to CHEP 2013

Greetings from CHEP 2013 in a rather wet Amsterdam.

The conference season is upon us and Sam, Andy, Wahid and myself find ourselves in Amsterdam for CHEP 2013. CHEP started here in 1983 and it is hard to believe that it has been 18 months since New York.

As usual the agenda for the next 5 days is packed. Some of the highlights so far have included advanced facility monitoring, the future of C++ and Robert Lupton's excellent talk on software engineering for Science.

As with all of my visits to Amsterdam, the rain is worth mentioning. So much so that it made local news this morning. However, the venue is the rather splendid Beurs van Berlage in central Amsterdam.

CHEP 2013

There will be further updates during the week as the conference progresses.

GridPP At The Top Of Europe

This news article appeared on the GridPP website and is worth reposting to our blog as it gives an overview of the collaborations efforts to date within the WLCG and with the Non High Energy Physics (HEP) communities.
GridPP At The Top Of Europe

The CE is dead. Long live the CE. Nos paenitet incommodo

As part of the on-going developments to the Scot Grid cluster at Glasgow, we have decommissioned our final LCG-CE, which resided on SVR021. The removal of this CE allows us to concentrate the support and development of two CE platforms; Cream and ARC. We are planning to conduct a series of tests around the three CREAM CE's we have deployed at Glasgow in an attempt to gain a better understanding of their maximum loading potential for running jobs and how to tweak them to gain the maximum efficiency from this service.

Additionally, we will be testing our availability metrics over the next month as the LCG-CE was one of the corner stones of Steve Lloyd's tests of our overall availability. This will now be monitored primarily through our SRM availability.

The reasons for decommissioning the LCG-CE are that we would be removing it at some point in the near future, all the big VO's do not have issues with submitting to Cream CEs and it simplifies our internal support requirements.

The new servers running Cream are svr008, svr014 and svr026.

Thank you LCG-CE and goodnight.

'EventRecords' is full

Our accounting database appears to be full.

org.glite.apel.core.ApelException: java.sql.SQLException: The table 'EventRecords' is full

Hmmm, what to do. Increase or archive?

You can see what is set from: SHOW TABLE STATUS FROM accounting LIKE 'EventRecords';

and if you want to increase you can use:ALTER TABLE accounting MAX_ROWS=1000000000 AVG_ROW_LENGTH=338;

But surely the correct thing would be archive. Handily the archival procedure is documented on the APEL wiki.

It is useful to know that the default size of MyISAM tables in MYSQL4 is 4Gb. Luckily in MYSQL5 and above the table limit is much higher. I wonder if the new SL5 APEL will ship with innodb tables?

disinformation

We just got ticketed for a failing SE sam test. Most odd as Steve Lloyds SAM results were all green. Re-read the ticket and it turns out we were publishing info for svr018.beowulf.cluster rather than the external interface name. Despite this being noted before Graeme hacked it around and raised a Savannah Ticket

Local Accounting Pages Ready

Billy's been doing a grand job knocking the local accounting pages into shape. This is based on Jamie's original work, but with some of the nastier hacks taken out and a lot of MySQL/PHP performance improvements from Andrew.

We can now see job numbers, CPU times, wall times and efficiencies for each group, plotted on a day/week or month basis.

There's still some work to be done - it would be nice to have a per-user plot, but the core is there and working well.

Oh, and it's checked into subversion finally. No more panics about losing the code.

It's probably in a good enough shape that other sites would find it useful now, actually.

ScotGrid Review Documents Complete

The site responses for the ScotGrid T2 review have now been given to the reviewers. Inspired by Olivier I decided that some plots of CPU delivery per VO and per site would be useful.

This turned out to be surprisingly hard to do - the accounting portal only gives a summary for a time period, not a plot over the time period. So I had to download the last 12 months as individual CSV files and parse them. Of course, each file contains variable numbers of VOs and sites. As this is essentially data in 3 dimensions, i.e., cpuhours(month, vo, site) it's impossible for Excel to deal with it directly.

Time to bring python out of the box to parse the data and print summary CSV files which Excel can do. Took the best part of 3 hours - however, it's now done and any future work like this should be faster.

Plots shown above, just so they get a wider audience.

APEL Configuration Twiddle

Reviewing some of the ScotGrid status pages I noticed we hadn't published accounting data for about a week. Trying to run APEL by hand revealed why - it was set to use the old sBDII on svr016 instead of the new one on svr021. This had been running on for months, even though the site's published GIIS endpoint had been changed to svr021 months ago - and I had finally switched it off about a week ago.

Once this was corrected (in /opt/glite/etc/glite-apel-pbs/parser-config-yaim.xml) things ran through fine.

Defining SPEC Values for the Cluster

I had a long discussion with Mark about getting the SPEC values correct for Durham. There's no really good answer to this apart from go to the SPEC Website and try and find machines with the same processor types and vintage as your own (ideally with the same motherboard). N.B. One should really use the "base" values - these have a conservative set of compiler flags so are more appropriate for pre-compiled EGEE applications - the peak values enable all the bells and whistles on the compiler.

I was also prompted to look at the numbers I had put in for the new Glasgow cluster. Here we have Opteron 280s. There are now 10 measurements for the SI2K of these machines - these are all very close and average to 1533, so that's what I have now put (up slightly from 1450). The FP2K values have a bigger spread (different chipsets?), but in the absence of any guide I again took the average, which was 1770.

I also noticed that CPU2000 has now officially been retired - replaced by CPU2006. This is going to be a problem as CPU2000 will not be available for newer machines, but CPU2006 will not be available for older ones. How do you express that in your JDL?