SCIENTIFIC-LINUX-USERS Archives

May 2008

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Eduardo Bach <[log in to unmask]>
Reply To:
Eduardo Bach <[log in to unmask]>
Date:
Fri, 30 May 2008 14:55:02 -0300
Content-Type:
text/plain
Parts/Attachments:
text/plain (94 lines)
Hello to all.

I would like first to thanks Rhys and Troy who responded so promptly.

About the replacement of the kernel, I will do it, not now only because 
I have not had a window for that.

About controller is deteriorating (if I do not committed any mistake), I 
find it unlikely for the following. First because I not found, now or at 
the time of server's installation, any error messages from disk. When 
the LSI controller was on the server, I even tried to use the modules 
from the manufacturer and the performance only got worse. So I resolved 
boot the server with a gentoo livecd, just to experience, and all the 
problems disappeared. The server had the performance expected and 
everything else. Returning to the SL45, with the removal of the LSI 
controller, we began to use the motherboard controller  and do raid by 
software. The value reached by wa in top was falores acceptable. Just 
after a long time we have seen the problem appears again, and quite 
intermittent. I suspect that the problem is becose some kernel 
parameters, but in fact the options that I knew well already been exhausted.

Thanks again.

Eduardo Bach

Troy Dawson escreveu:
> Hi Eduardo,
> What Rhys said could be the problem, and it is worth a try.
>
> But I would also check in /var/log/messages to see if there are any 
> disk related messages.  Something about a controller or device timing 
> out.
> It is usually a sign that a drive is starting to die and should be 
> replaced before it's completely dead.  It is also occasionally the 
> sign that the controller is dying, but that doesn't happen as much as 
> a drive.
>
> Troy
>
> Rhys Morris wrote:
>> Hi Eduardo,
>>
>> Try running kernel-hugemem instead of the normal kernel, I recently
>> had similar problems to you which were fixed by running
>> kernel-hugemem.
>>
>> I upgraded the RAM in a machine from 2gb to 4gb and it ran really
>> slowly with the normal kernel, but fine with kernel-hugemem
>>
>> yum install kernel-hugemem
>>
>> rebboot and pick kernel-hugmem on boot.
>>
>> Good luck,
>>
>> Rhys
>>
>>
>> On Thu, 29 May 2008, Eduardo Bach wrote:
>>
>>> Hello to all.
>>> First sorry my terrible english.
>>> Some time ago we buy a new server on which we have installed SL-45.
>>> The server has the following characteristics:
>>> Super Micro motherboard
>>> 2 cpus dualcore Intel Xeon 2GHz
>>> 4GB of ram, 250GB of disc.
>>> On that occasion the server had a LSI SATA RAID controller, with the 
>>> raid with
>>> two disks of 250GB. For some reason that we do not know that until 
>>> today, the
>>> disc access was very slow, at the point of the machine go getting 
>>> increasingly
>>> slow until freeze. This happened in a short time, a matter of 
>>> minutes after
>>> start the nfs server. The only thing I could find is that, looking 
>>> at the top,
>>> we getting all processors increased the wa nearly 100% with us less 
>>> than 10%
>>> in all processors. We remove the raid controller and made the raid via
>>> software and the problem had apparently disappeared. Today, doing some
>>> searches through files, commands such as du and find took too long, 
>>> turning
>>> the wa to stay near 80% in almost all processors, with the 
>>> difference that
>>> when I concluded the program, the system returned to normal.
>>> Please send me any suggestion that I continue to research.
>>> Thank you now.
>>>
>>> Eduardo Bach
>>>
>
>

ATOM RSS1 RSS2