Hi Sam,
On 18/01/2013 11:19, Sam Skipsey wrote:
> Hi
>
>
> On 18 January 2013 10:44, Mark Slater <[log in to unmask]
> <mailto:[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.)
As you will have seen, starting nscd hasn't helped me. I might try
setting up /etc/hosts manually - though as we have a local DNS server I
wouldn't have expected to need to do this.
Cheers,
John
>
> 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
>
>
|