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
>>


-- 
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/LCSI/CSI DSS Group
__________________________________________________