On Dec 18, 2008, at 12:24 PM, "John" wrote:
>
>> -Original Message-
>> From: centos-boun...@centos.org
>> [mailto:centos-boun...@centos.org] On Behalf Of Matt
>> Sent: Thursday, December 18, 2008 10:37 AM
>> To: CentOS mailing list
>>
On Dec 18, 2008, at 12:59 PM, Matt wrote:
>> That's why I asked what kind of Controler the board had on it in a
>> previous
>> post to you and stated ram was not the suspect problem. IMO if you
>> keeped
>> the dual core proc and just switched to ICH7 Board you would have
>> saved
>> money
> That's why I asked what kind of Controler the board had on it in a previous
> post to you and stated ram was not the suspect problem. IMO if you keeped
> the dual core proc and just switched to ICH7 Board you would have saved
> money. Your utilization rate would probly stayed the same or no highe
> -Original Message-
> From: centos-boun...@centos.org
> [mailto:centos-boun...@centos.org] On Behalf Of Matt
> Sent: Thursday, December 18, 2008 10:37 AM
> To: CentOS mailing list
> Subject: Re: [CentOS] Adding RAM
>
> >> A bit of bottle neck.
> >&
>> A bit of bottle neck.
>>
>> Device:rrqm/s wrqm/s r/s w/s rsec/s wsec/srkB/swkB/s
>> avgrq-sz avgqu-sz await svctm %util
>> sda 0.38 176.63 70.32 78.26 813.46 2044.82 406.73 1022.41
>> 19.24 0.40 19.17 4.04 60.07
>> sda1 0.00 0.00 0.00 0.0
On Thu, 2008-12-11 at 10:40 +0100, Ralph Angenendt wrote:
> MHR wrote:
> > On Wed, Dec 10, 2008 at 9:25 AM, John <[EMAIL PROTECTED]> wrote:
> > >
> > > Like this:
> > >
> > > kernel /vmlinuz-2.6.9-78.0.8.ELsmp ro root=/dev/VolGroup00/LogVol00
> > > elevater=deadline
> > >
> >
> > The above should
MHR wrote:
> On Wed, Dec 10, 2008 at 9:25 AM, John <[EMAIL PROTECTED]> wrote:
> >
> > Like this:
> >
> > kernel /vmlinuz-2.6.9-78.0.8.ELsmp ro root=/dev/VolGroup00/LogVol00
> > elevater=deadline
> >
>
> The above should be all on one line.
And my dictionary tells me that it should be elevator.
R
On Wed, Dec 10, 2008 at 8:11 AM, Matt <[EMAIL PROTECTED]> wrote:
>
> echo 'deadline' > /sys/block/sda/queue/scheduler
> -bash: /sys/block/sda/queue/scheduler: No such file or directory
>
> ls -l /sys/block/sda/queue/
> total 0
> drwxr-xr-x 2 root root0 Dec 8 17:45 iosched
> -r--r--r-- 1 roo
On Wed, Dec 10, 2008 at 9:25 AM, John <[EMAIL PROTECTED]> wrote:
>
> Like this:
>
> kernel /vmlinuz-2.6.9-78.0.8.ELsmp ro root=/dev/VolGroup00/LogVol00
> elevater=deadline
>
The above should be all on one line.
mhr
___
CentOS mailing list
CentOS@centos.
On Wed, 2008-12-10 at 10:56 -0600, Matt wrote:
> > Yes follow up to previous mail. That would be correct for those two. My
> > opinions do not change however, I just saw the mail where it did not
> > work because he has V4.x and needs to use grub.conf.
>
> In grub.conf I have this:
>
> ---
> #bo
> Yes follow up to previous mail. That would be correct for those two. My
> opinions do not change however, I just saw the mail where it did not
> work because he has V4.x and needs to use grub.conf.
In grub.conf I have this:
---
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.
On Wed, 2008-12-10 at 17:02 +0100, Peter Kjellstrom wrote:
> On Wednesday 10 December 2008, John wrote:
> > On Tue, 2008-12-09 at 12:07 -0500, Ross Walker wrote:
> > > On Dec 9, 2008, at 10:59 AM, Matt <[EMAIL PROTECTED]> wrote:
> > > Setting scheduler is global in C4 it can be set as a kerne
On Wed, 2008-12-10 at 17:02 +0100, Peter Kjellstrom wrote:
> On Wednesday 10 December 2008, John wrote:
> > On Tue, 2008-12-09 at 12:07 -0500, Ross Walker wrote:
> > > On Dec 9, 2008, at 10:59 AM, Matt <[EMAIL PROTECTED]> wrote:
> > > Setting scheduler is global in C4 it can be set as a kerne
> The Schedular is CFQ and can be changed on the fly to whatever Block
> Device you want it. It does not matter what load the system is under.
> Changing to Deadline on his specific block device will improve the I/O
> of the system unless it really being hammered. Keep in mind these
> changes will
On Wednesday 10 December 2008, John wrote:
> On Tue, 2008-12-09 at 12:07 -0500, Ross Walker wrote:
> > On Dec 9, 2008, at 10:59 AM, Matt <[EMAIL PROTECTED]> wrote:
> > Setting scheduler is global in C4 it can be set as a kernel option
> > with a scheduler=deadline in grub.
> > >>>
> > >>>
On Tue, 2008-12-09 at 12:07 -0500, Ross Walker wrote:
> On Dec 9, 2008, at 10:59 AM, Matt <[EMAIL PROTECTED]> wrote:
>
> Setting scheduler is global in C4 it can be set as a kernel option
> with a scheduler=deadline in grub.
> >>>
> >>> Is that an alias for "elevator=deadline" (which I
On Dec 9, 2008, at 10:59 AM, Matt <[EMAIL PROTECTED]> wrote:
Setting scheduler is global in C4 it can be set as a kernel option
with a scheduler=deadline in grub.
>>>
>>> Is that an alias for "elevator=deadline" (which I know works)?
>>
>> No that was me forgetting the option name.
>>
>
Hi,
Tell me how much is the swap space you assigned and also you can
use below commands to trace out the cause of such huge I/O.Also are
using SAN or local storage?.I don't think so you need explanation for
below commands.Run all the commands and redirect it to some file and
send it to the
>>> Setting scheduler is global in C4 it can be set as a kernel option
>>> with a scheduler=deadline in grub.
>>
>> Is that an alias for "elevator=deadline" (which I know works)?
>
> No that was me forgetting the option name.
>
> Thanks Peter, it's elevator= not scheduler=
Does this mean I need to
On Dec 9, 2008, at 3:30 AM, Peter Kjellstrom <[EMAIL PROTECTED]> wrote:
> On Tuesday 09 December 2008, Ross Walker wrote:
>> On Dec 8, 2008, at 6:51 PM, Matt <[EMAIL PROTECTED]> wrote:
> ...
Try setting the scheduler to 'deadline' and see if the queue sizes
shrink.
>>>
>>> I have google
On Tuesday 09 December 2008, Ross Walker wrote:
> On Dec 8, 2008, at 6:51 PM, Matt <[EMAIL PROTECTED]> wrote:
...
> >> Try setting the scheduler to 'deadline' and see if the queue sizes
> >> shrink.
> >
> > I have googled this and having a bit of trouble figuring how to change
> > it under CentOS 4
On Dec 8, 2008, at 6:51 PM, Matt <[EMAIL PROTECTED]> wrote:
>>> Device:rrqm/s wrqm/s r/s w/s rsec/s wsec/srkB/s
>>> wkB/s
>>> avgrq-sz avgqu-sz await svctm %util
>>> sda 0.38 176.63 70.32 78.26 813.46 2044.82 406.73
>>> 1022.41
>>> 19.24 0.40 19.17 4
>> Device:rrqm/s wrqm/s r/s w/s rsec/s wsec/srkB/swkB/s
>> avgrq-sz avgqu-sz await svctm %util
>> sda 0.38 176.63 70.32 78.26 813.46 2044.82 406.73 1022.41
>> 19.24 0.40 19.17 4.04 60.07
>> sda1 0.00 0.00 0.00 0.000.000.00 0.00
On Dec 8, 2008, at 4:55 PM, Matt <[EMAIL PROTECTED]> wrote:
>>> Cpu0 : 5.3% us, 4.0% sy, 0.0% ni, 81.5% id, 9.3% wa, 0.0%
>>> hi, 0.0% si
>>> Cpu1 : 11.3% us, 8.3% sy, 0.0% ni, 1.7% id, 78.1% wa, 0.7%
>>> hi, 0.0% si
>>> Mem: 8309188k total, 4761352k used, 3547836k free, 45
>> Cpu0 : 5.3% us, 4.0% sy, 0.0% ni, 81.5% id, 9.3% wa, 0.0% hi, 0.0% si
>> Cpu1 : 11.3% us, 8.3% sy, 0.0% ni, 1.7% id, 78.1% wa, 0.7% hi, 0.0% si
>> Mem: 8309188k total, 4761352k used, 3547836k free, 451464k buffers
>> Swap: 2031608k total, 192k used, 2031416k free, 1564
Matt wrote:
> Cpu0 : 5.3% us, 4.0% sy, 0.0% ni, 81.5% id, 9.3% wa, 0.0% hi, 0.0% si
> Cpu1 : 11.3% us, 8.3% sy, 0.0% ni, 1.7% id, 78.1% wa, 0.7% hi, 0.0% si
> Mem: 8309188k total, 4761352k used, 3547836k free, 451464k buffers
> Swap: 2031608k total, 192k used, 2031416k fre
>> He should be able to replace the kernel via rpm -e and rpm -i
>>
>> That said, I doubt he'll actually see a benefit.
>> PAE is slow.
>> If you want to see a real performance-gain, install 5.2 x86-64.
>>
> You will only see a gain if the machine is swapping, otherwise more ram
> through PAE could
John R Pierce wrote:
> thats not at all an accurate description (other than the 64GB part)
It was a simplified description of how PAE works. The point was that PAE
work at the page table level and just remaps memory pages to fit within
the virtual 32-bit/4GB address space for a 32-bit process. T
On Dec 7, 2008, at 1:37 PM, Morten Torstensen wrote:
> Kevin Krieser wrote:
>
>> At least with regard to the upstream provider, on X86 the desktop
>> version has a limit of 4GB of RAM, regardless of how much more memory
>> you have. And they removed the hugemem version, so instead of up to
>> 64
Morten Torstensen wrote:
> With PAE you can access up to 64GB memory. It works much the same way as
> XMS memory in DOS, where "high mem" is mapped to a low mem window. It is
> just addresses that are mapped, there is no physical copying of memory
> that you had with EMS memory.
>
thats not
Kevin Krieser wrote:
> At least with regard to the upstream provider, on X86 the desktop
> version has a limit of 4GB of RAM, regardless of how much more memory
> you have. And they removed the hugemem version, so instead of up to
> 64GB of RAM on 32 bit, you can only get to 16GB for server
on 12-5-2008 4:18 PM Rainer Duffner spake the following:
> Am 06.12.2008 um 01:02 schrieb Ignacio Vazquez-Abrams:
>
>> On Fri, 2008-12-05 at 23:57 +, Michael Holmes wrote:
>>> 2008/12/5 Matt <[EMAIL PROTECTED]>:
I have a server running Centos 4.7 32bit. Will moving from 4Gig of
RAM
On Dec 6, 2008, at 10:44 AM, Ross Walker wrote:
>
> On Dec 5, 2008, at 7:18 PM, Rainer Duffner <[EMAIL PROTECTED]>
> wrote:
>
>>
>> Am 06.12.2008 um 01:02 schrieb Ignacio Vazquez-Abrams:
>>
>>> On Fri, 2008-12-05 at 23:57 +, Michael Holmes wrote:
2008/12/5 Matt <[EMAIL PROTECTED]>:
>
On Dec 5, 2008, at 7:18 PM, Rainer Duffner <[EMAIL PROTECTED]>
wrote:
>
> Am 06.12.2008 um 01:02 schrieb Ignacio Vazquez-Abrams:
>
>> On Fri, 2008-12-05 at 23:57 +, Michael Holmes wrote:
>>> 2008/12/5 Matt <[EMAIL PROTECTED]>:
I have a server running Centos 4.7 32bit. Will moving from
> >> 2008/12/5 Matt <[EMAIL PROTECTED]>:
> >>> I have a server running Centos 4.7 32bit. Will moving from 4Gig of
> >>> RAM to 8Gig do any good? Since its 32bit I assume it will only be
> >>> able to address the first 4Gig not?
> >> As long as you are using a SMP kernel you can use up to 64GB of
2008/12/6 Rainer Duffner <[EMAIL PROTECTED]>:
>
> Am 06.12.2008 um 01:02 schrieb Ignacio Vazquez-Abrams:
>> PAE, not SMP.
Gah, my mistake, sorry.
> He should be able to replace the kernel via rpm -e and rpm -i
> That said, I doubt he'll actually see a benefit.
> PAE is slow.
> If you want to see a
Am 06.12.2008 um 01:02 schrieb Ignacio Vazquez-Abrams:
> On Fri, 2008-12-05 at 23:57 +, Michael Holmes wrote:
>> 2008/12/5 Matt <[EMAIL PROTECTED]>:
>>> I have a server running Centos 4.7 32bit. Will moving from 4Gig of
>>> RAM to 8Gig do any good? Since its 32bit I assume it will only be
>
>> I have a server running Centos 4.7 32bit. Will moving from 4Gig of
>> RAM to 8Gig do any good? Since its 32bit I assume it will only be
>> able to address the first 4Gig not?
> As long as you are using a SMP kernel you can use up to 64GB of RAM
> (though each proccess can only address 4GB of
On Fri, 2008-12-05 at 23:57 +, Michael Holmes wrote:
> 2008/12/5 Matt <[EMAIL PROTECTED]>:
> > I have a server running Centos 4.7 32bit. Will moving from 4Gig of
> > RAM to 8Gig do any good? Since its 32bit I assume it will only be
> > able to address the first 4Gig not?
> As long as you are
2008/12/5 Matt <[EMAIL PROTECTED]>:
> I have a server running Centos 4.7 32bit. Will moving from 4Gig of
> RAM to 8Gig do any good? Since its 32bit I assume it will only be
> able to address the first 4Gig not?
As long as you are using a SMP kernel you can use up to 64GB of RAM
(though each procc
I have a server running Centos 4.7 32bit. Will moving from 4Gig of
RAM to 8Gig do any good? Since its 32bit I assume it will only be
able to address the first 4Gig not? When I installed CentOS I did not
do anything special to enable using more then 4Gig if thats required.
Exim, spamassassin and
41 matches
Mail list logo
