Hi Mark,
Thanks for the suggestions.
On 18/01/2013 10:44, Mark Slater 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....
The DB is on the same machine (which was fine under 1.8.3). This is a
bare metal (though quite old) server with plenty of memory (8GB).
>
> 2) Maybe drop the requests tables in the DB? I know this can certainly
> have an affect on performance.
I'll have a look at this.
>
> 3) Enable nscd?
I've tried this, but it hasn't helped. We have a DNS server on our local
network (mainly to make the non-GRID stuff resilient against the campus
connection going down, and we get it for free anyway with our Windows
2008 domain) so I would not have expected problems with DNS lookups.
That's not to say that it wasn't a useful suggestion.
>
>
> I'm guessing others will have more useful ideas but those things have
> generally solved our problems in the past!
I hope so...
I was expecting EMI-1 to EMI-2 to be relatively painless for the DPM
head node. I should really know better by now.
Cheers,
John
>
> 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
>
|