64 Bit / Swap Issue?

64 Bit / Swap Issue?

am 05.12.2005 06:11:25 von James Dey

This is a multi-part message in MIME format.

------=_NextPart_000_0010_01C5F96B.1B5FFEA0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Guys,



We have been running our systems on high end Redhat ES 32 Bit servers
without any sort of glitch. We have now set up a 64 bit Athlon server
running Redhat ES, installed the Redhat PgSQL as well as the PHP5 RPM.



I have been experiencing incredible slow performance from my server, and am
at a loss for solution. Should I be moving back to a 32 bit system?



This is the reply I have from Rackspace:



"Secondly "sar" is showing that you are dipping quite a bit into your swap
space. When dealing with a database server, any time that you move from RAM
to swap you will see a massive performance drop, especially when dealing
with as much swap as this machine has. At its peak you were hitting
70%(700M) of swap. Since PostgreSQL is unsupported I don't have any
suggestions on query optimizations. However, at this point upgrading your
available RAM would be one of my best suggestions."



Does anyone have any experience on this? Most of the things I have read
suggest that I move back to 32 bit but I do think it's a step backward -
that's if this can be supported.



Regards and thanks,



James Dey

james@mygus.com



0861-11-44-03

Intl. : +27 (0) 11 704-1945

Fax : +27 (0) 11 3888-907

Mobile : +27 (0) 82-7855-102




------=_NextPart_000_0010_01C5F96B.1B5FFEA0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">


charset=3Dus-ascii">

namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
name=3D"City"/>
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
name=3D"place"/>









style=3D'font-size:9.0pt;font-family:Arial;color:#333300'>Hi =
Guys,



style=3D'font-size:9.0pt;font-family:Arial;color:#333300'>  p>



style=3D'font-size:9.0pt;font-family:Arial;color:#333300'>We have been =
running
our systems on high end Redhat ES 32 Bit servers without any sort of =
glitch. We
have now set up a 64 bit Athlon server running Redhat ES, installed the =
Redhat
PgSQL as well as the PHP5 RPM.



style=3D'font-size:9.0pt;font-family:Arial;color:#333300'>  p>



style=3D'font-size:9.0pt;font-family:Arial;color:#333300'>I have been
experiencing incredible slow performance from my server, and am at a =
loss for
solution. Should I be moving back to a 32 bit =
system?



style=3D'font-size:9.0pt;font-family:Arial;color:#333300'>  p>



style=3D'font-size:9.0pt;font-family:Arial;color:#333300'>Th is is the =
reply I have
from Rackspace:



style=3D'font-size:9.0pt;font-family:Arial;color:#333300'>  p>



face=3DArial> style=3D'font-size:9.0pt;font-family:Arial;font-style:italic '> “Seco=
ndly
"sar" is showing that you are dipping quite a bit into your =
swap
space.  When dealing with a database server, any time that you move =
from RAM to
swap you will see a massive performance drop, especially when dealing =
with as
much swap as this machine has.  At its peak you were hitting =
70%(700M) of
swap.  Since PostgreSQL is unsupported I don't have any suggestions =
on query
optimizations.  However, at this point upgrading your available RAM =
would be
one of my best suggestions.”



face=3DArial> style=3D'font-size:9.0pt;font-family:Arial'>  t>



face=3DArial> style=3D'font-size:9.0pt;font-family:Arial'>Does anyone have any =
experience on
this? Most of the things I have read suggest that I move back to 32 bit =
but I do
think it’s a step backward – that’s if this can be =
supported.



face=3DArial> style=3D'font-size:9.0pt;font-family:Arial'>  t>



face=3DArial> style=3D'font-size:9.0pt;font-family:Arial'>Regards and thanks, color=3D"#333300"> style=3D'color:#333300'>



face=3DArial> style=3D'font-size:9.0pt;font-family:Arial;color:#333300'>  p>



face=3DArial> style=3D'font-size:9.0pt;font-family:Arial;color:#3366FF;fon t-weight:bold=
'>James
Dey
lang=3DFR
style=3D'font-size:9.0pt;font-family:Arial;color:#3366FF'> an>



face=3DArial> style=3D'font-size:9.0pt;font-family:Arial;color:#333300'>ja mes@mygus.com=



face=3DArial> style=3D'font-size:9.0pt;font-family:Arial;color:#333300'>  p>



face=3DArial> style=3D'font-size:9.0pt;font-family:Arial;color:#333300'>08 61-11-44-03 :p>



face=3DArial> style=3D'font-size:9.0pt;font-family:Arial;color:#333300'>In tl. : +27 =
(0) 11
704-1945



face=3DArial> style=3D'font-size:9.0pt;font-family:Arial;color:#333300'>Fa x : +27 (0) =
11
3888-907



size=3D1
color=3D"#333300" face=3DArial> style=3D'font-size:9.0pt;font-family:Arial;
color:#333300'>Mobile
size=3D1
color=3D"#333300" face=3DArial> style=3D'font-size:9.0pt;font-family:Arial;
color:#333300'> : +27 (0) 82-7855-102



style=3D'font-size:9.0pt;
font-family:Arial'> 









------=_NextPart_000_0010_01C5F96B.1B5FFEA0--

Re: 64 Bit / Swap Issue?

am 05.12.2005 17:14:30 von John DeSoi

Hi James,

On Dec 5, 2005, at 12:11 AM, James Dey wrote:

> =93Secondly "sar" is showing that you are dipping quite a bit into
> your swap space. When dealing with a database server, any time
> that you move from RAM to swap you will see a massive performance
> drop, especially when dealing with as much swap as this machine
> has. At its peak you were hitting 70%(700M) of swap. Since
> PostgreSQL is unsupported I don't have any suggestions on query
> optimizations. However, at this point upgrading your available RAM
> would be one of my best suggestions.=94
>
>
>
> Does anyone have any experience on this? Most of the things I have
> read suggest that I move back to 32 bit but I do think it=92s a step=20=
=20
> backward =96 that=92s if this can be supported.
Welcome to the list.

I don't have an answer for you but I'll suggest that you might have
better luck finding one on the performance list. Or even the general
list. Also there are archives for all lists which might also provide
some clues.





John DeSoi, Ph.D.
http://pgedit.com/
Power Tools for PostgreSQL


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Re: 64 Bit / Swap Issue?

am 05.12.2005 17:38:47 von Bruno Wolff III

On Mon, Dec 05, 2005 at 07:11:25 +0200,
James Dey wrote:
>
> I have been experiencing incredible slow performance from my server, and am
> at a loss for solution. Should I be moving back to a 32 bit system?

I think it is unlikely that the switch to 64bit architecture is what is causing
your problem.

You should ask again on the performance list.

You want to include some more details on hardware, such as the amount of memory
and your disk set up.

You should include your postgresql.conf settings as there might be
something there that is causing a problem.

You should state what version of postgres you are running and what OS you
are using.

You should include information about what else is running on that server.
It is possible that something other than Postgres is using the memory.
Have you looked at ps output to try to identify which processes are using
lots of memory?

If you have identified any slow queries, it would be helpful to see EXPLAIN
ANALYSE output for them. Your problem is probably not a bad plan, but there
could be an issue with a query taking up a lot of memory if you workmem
limit is very high.

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Re: 64 Bit / Swap Issue?

am 05.12.2005 18:04:35 von Joshua Drake

James Dey wrote:
> -->
>
> Hi Guys,
>
> We have been running our systems on high end Redhat ES 32 Bit servers=20
> without any sort of glitch. We have now set up a 64 bit Athlon server=20
> running Redhat ES, installed the Redhat PgSQL as well as the PHP5 RPM.
>
Do the machines have a different amount of RAM? There is no reason that=20
a 32 bit machine versus a 64bit machines should swap noticeably more=20
unless something has changed.

> /=93Secondly "sar" is showing that you are dipping quite a bit into you=
r=20
> swap space. When dealing with a database server, any time that you=20
> move from RAM to swap you will see a massive performance drop,=20
> especially when dealing with as much swap as this machine has. At its=20
> peak you were hitting 70%(700M) of swap. Since PostgreSQL is=20
> unsupported I don't have any suggestions on query optimizations.=20
> However, at this point upgrading your available RAM would be one of my=20
> best suggestions.=94/
>
Well there response is correct but the question is why are you hitting=20
swap. Please see my quseton above.
>
> Does anyone have any experience on this? Most of the things I have=20
> read suggest that I move back to 32 bit but I do think it=92s a step=20
> backward =96 that=92s if this can be supported.
>

There is no reason for you to move back to 32bit.

Joshua D. Drake


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org