Print

Print


Hi


On 18 January 2013 10:44, Mark Slater <[log in to unmask]> wrote:
Hi John,

Our SE is not particularly loaded and we have 1.8.5 running. A couple of things spring to mind:

1) Is your SQL DB on the same machine? Ours is split so this may be a factor....

2) Maybe drop the requests tables in the DB? I know this can certainly have an affect on performance.

3) Enable nscd?



Of these, 3) seems the most likely to help in this instance. 
I seem to recall that that's what fixed your own issues with newer DPM installs, Mark? (It also helped out Matt at Lancaster - or the equivalent process of adding lots of dns entries to the /etc/hosts config.)

Sam

 

I'm guessing others will have more useful ideas but those things have generally solved our problems in the past!

Thanks,

Mark



On 18/01/13 10:27, John Hill wrote:
Yesterday I upgraded our DPM head node from UMD-1 (DPM 1.8.3) to EMI-2 (DPM 1.8.5). The upgrade appeared to be successful, but since then the load average on the SE has stayed stubbornly above 2 (prior to the upgrade it rarely exceeded 0.2). The SE is working (all Nagios tests are passing and I can see no obvious errors in the logs), but some transfers are failing due to timeouts (so ATLAS opened a ticket overnight).
I tried increasing innodb_buffer_pool_size in /etc/my.cnf and this may have helped at the 10-20% level. The most active process is often srmv2.2, but I can't find any discussion of a need to tune it. Any pointers on how to debug this behaviour would be welcome.

John