CentOS 4.8 no-install of MySQL 5.1.4X???

--0-6933899-1280431837=:33361
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hello Gurus, I am trying to see if there is a no install version of MySQL 5=
..1.4X =0Afor Cent OS 4.8?=A0 We got a copy for Solaris x86 and it works AWE=
SOME, I cant =0Aseem to find one for Cent OS?=A0 We wanted to install sever=
al flavors and test a =0A200 MB query script file against it to see how the=
performance changes between =0Athe iterations of the software.=A0 Any help=
/ advice is much appreciated. P.S.=A0 I know there are RPM's but the =
last time I tried using RPM's it started to =0Arip other components out of =
of prod boxes and I was in backup mode restoring =0Afrom the AM snapshot.=
=A0 Besides RPM's dont like to go up a version then down a =0Aversion like =
in a sandbox ;-) Thanks... Nunzio =0A
--0-6933899-1280431837=:33361--

Re: CentOS 4.8 no-install of MySQL 5.1.4X???

Yes, I do it all the time.

download TAR archive at the bottom of the download list.

untar in a custom dir.
use dedicated user
watch the my.cnf location, its kind of css style, if you have side
effects its cause your mysql installation is picking it up also from the
wrong location
remove /etc/my.cnf, put custom my.cnf into the basedir

good luck

Claudio
You have Intel
On 7/29/2010 9:30 PM, Nunzio Daveri wrote:
> Hello Gurus, I am trying to see if there is a no install version of MySQL 5.1.4X
> for Cent OS 4.8? We got a copy for Solaris x86 and it works AWESOME, I cant
> seem to find one for Cent OS? We wanted to install several flavors and test a
> 200 MB query script file against it to see how the performance changes between
> the iterations of the software. Any help / advice is much appreciated.
>
> P.S. I know there are RPM's but the last time I tried using RPM's it started to
> rip other components out of of prod boxes and I was in backup mode restoring
> from the AM snapshot. Besides RPM's dont like to go up a version then down a
> version like in a sandbox ;-)
>
> Thanks...
>
> Nunzio
>
>
>
>


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

Re: CentOS 4.8 no-install of MySQL 5.1.4X???

--0-1586449343-1280498011=:63248
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks Claudio but I do that all the time.=A0 The question is where is the =
file?=A0 =0AYou said to go to the download area, there are hundreads of fil=
es and not one =0Atar file says rhel or cent os. What is the URL / fil=
e name to download and untar please? Thanks for responding :-) Nu=
nzio =0A
--0-1586449343-1280498011=:63248--

Re: CentOS 4.8 no-install of MySQL 5.1.4X???

Nunzio, all,

Nunzio Daveri schrieb:
> Thanks Claudio but I do that all the time. The question is where is th=
e file? =20
> You said to go to the download area, there are hundreads of files and n=
ot one=20
> tar file says rhel or cent os.

"tar.gz" packages are not specific to the Linux distribution, they are
generic. Their sole dependency is on the glibc version, and that is 2.3
(or up) with all reasonably current Linuxes (kernel 2.4 and up).

(With RPMs, it is different: They contain requirement specifications
which list package and version, and so there are specific ones for
current RHEL and SLES versions.)

>=20
> What is the URL / file name to download and untar please?

It depends on your CPU:
Go to "http://dev.mysql.com/downloads/mysql/5.1.html",
scroll down to the bottom of the list,
you will find 5 "generic" tar.gz packages:
x86, x86-icc, x86_64, x86_64-icc, ia64.

Those which do not bear "icc" in the name were built using gcc, and if
you are not specifically preferring binearies created by ICC you should
take a gcc-built one.

Pick the one that matches your CPU.


HTH,
Jörg

--=20
Joerg Bruehe, MySQL Build Team, Joerg.Bruehe@Sun.COM
ORACLE Deutschland B.V. & Co. KG, Komturstrasse 18a, D-12099 Berlin
Geschaeftsfuehrer: Juergen Kunz, Marcel v.d. Molen, Alexander v.d. Ven
Amtsgericht Muenchen: HRA 95603


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=3Dgcdmg-mysql-2@m.gmane.o rg

Re: CentOS 4.8 no-install of MySQL 5.1.4X???

Hi Nunzio, all (cc' to the list)!


Nunzio Daveri schrieb:
> Hello Joerg, thanks for replying. I am at:
>=20
> http://mysql.llarian.net/Downloads/MySQL-5.1/

I cannot comment on that server, do neither know it nor the origin of
the packages they provide (own builds or mirrored ones from the MySQL
Build Team).

>=20
> I am looking for what you described but cannot find a 5.1.44 for CentOS=
4.8 on=20
> Intel Quad Core CPU??? Any help is most appreciated. I have no proble=
ms with=20
> Solaris but need it for CentOS 4.8 specificially on intel dual cpu quad=
core=20
> x5000 seriec chipset running 64 bit with 16GB Ram.

That's ok, the packages built by MySQL (-> Sun -> Oracle) do not differ
between single- and multi-CPU machines.

>=20
> Based on what you have said, I should be looking for a:
>=20
> mysql-5.1.44-linux-x86_64.tar.gz

Right.

>=20
> but all I find is a:
>=20
> mysql-5.1.44.tar.gz

That's the plain sources.

>=20
> What am I doing wrong please?

You might try the MySQL download site I mentioned:
http://dev.mysql.com/downloads/mysql/5.1.html

If you are looking for 5.1.44, you will not find it directly on that
page, because the current version is 5.1.49.
But at the very bottom of the page, in the second column, there is a
link "Archives" that will get you to
http://downloads.mysql.com/archives.php

Click "MySQL Database Server 5.1" (4th entry from the top),
on the next page select "5.1.44",
on the next page the first five entries are generic Linux tar.gz packages=



HTH,
Jörg


> ________________________________
> From: Joerg Bruehe
> To: Nunzio Daveri
> Cc: mysql@lists.mysql.com
> Sent: Fri, July 30, 2010 9:19:29 AM
> Subject: Re: CentOS 4.8 no-install of MySQL 5.1.4X???
>=20
> Nunzio, all,
>=20
> Nunzio Daveri schrieb:
>> [[...]]
>=20
>> What is the URL / file name to download and untar please?
>=20
> It depends on your CPU:
> Go to "http://dev.mysql.com/downloads/mysql/5.1.html",
> [[...]]


--=20
Joerg Bruehe, MySQL Build Team, Joerg.Bruehe@Sun.COM
ORACLE Deutschland B.V. & Co. KG, Komturstrasse 18a, D-12099 Berlin
Geschaeftsfuehrer: Juergen Kunz, Marcel v.d. Molen, Alexander v.d. Ven
Amtsgericht Muenchen: HRA 95603


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=3Dgcdmg-mysql-2@m.gmane.o rg

Re: CentOS 4.8 no-install of MySQL 5.1.4X???

--0-1338458310-1280506122=:1640
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Awesome, thanks for helping that's just what I needed :-) Nunzio =
=0A________________________________=0AFrom: Joerg Bruehe e@oracle.com>=0ATo: Nunzio Daveri =0ACc: MySQL Gene=
ral List =0ASent: Fri, July 30, 2010 10:49:14 AM=0AS=
ubject: Re: CentOS 4.8 no-install of MySQL 5.1.4X??? Hi Nunzio, all (c=
c' to the list)! =0ANunzio Daveri schrieb:=0A> Hello Joerg, thanks for=
replying.=A0 I am at:=0A> =0A> http://mysql.llarian.net/Downloads/MySQL-5.=
1/ I cannot comment on that server, do neither know it nor the origin =
of=0Athe packages they provide (own builds or mirrored ones from the MySQL=
=0ABuild Team). > =0A> I am looking for what you described but cannot =
find a 5.1.44 for CentOS 4.8 on > Intel Quad Core CPU???=A0 Any help =
is most appreciated.=A0 I have no problems with > Solaris but need it=
for CentOS 4.8 specificially on intel dual cpu quad core =0A> x5000 seriec=
chipset running 64 bit with 16GB Ram. That's ok, the packages built b=
y MySQL (-> Sun -> Oracle) do not differ=0Abetween single- and multi-CPU ma=
chines. > =0A> Based on what you have said, I should be looking for a:=
=0A> =0A> mysql-5.1.44-linux-x86_64.tar.gz Right. > =0A> but all =
I find is a:=0A> =0A> mysql-5.1.44.tar.gz That's the plain sources.=0A=
=0A> =0A> What am I doing wrong please? You might try the MySQL downlo=
ad site I mentioned:   http://dev.mysql.com/downloads/mysql/5.1.html=0A=
=0AIf you are looking for 5.1.44, you will not find it directly on that=0Ap=
age, because the current version is 5.1.49.=0ABut at the very bottom of the=
page, in the second column, there is a=0Alink "Archives" that will get you=
to   http://downloads.mysql.com/archives.php Click "MySQL Databas=
e Server 5.1" (4th entry from the top),=0Aon the next page select "5.1.44",=
=0Aon the next page the first five entries are generic Linux tar.gz package=
s. =0AHTH,=0AJörg =0A> ________________________________=0A> Fro=
m: Joerg Bruehe =0A> To: Nunzio Daveri ri@yahoo.com>=0A> Cc: mysql@lists.mysql.com=0A> Sent: Fri, July 30, 2010 9:=
19:29 AM=0A> Subject: Re: CentOS 4.8 no-install of MySQL 5.1.4X???=0A> =0A>=
Nunzio, all,=0A> =0A> Nunzio Daveri schrieb:=0A>> [[...]]=0A> =0A>> What i=
s the URL / file name to download and untar please?=0A> =0A> It depends on =
your CPU:=0A> Go to "http://dev.mysql.com/downloads/mysql/5.1.html",=0A> [[=
....]] =0A-- =0AJoerg Bruehe,=A0 MySQL Build Team,=A0 Joerg.Bruehe@Sun.=
COM=0AORACLE Deutschland B.V. & Co. KG,=A0 Komturstrasse 18a,=A0 D-12099 Be=
rlin=0AGeschaeftsfuehrer: Juergen Kunz, Marcel v.d. Molen, Alexander v.d. V=
en=0AAmtsgericht Muenchen: HRA 95603 =0A
--0-1338458310-1280506122=:1640--

Re: Indexes larger than RAM (was: Do you know who can answer thisquestion I posted yesterday please?

Hi!


I am no InnoDB and tuning expert, so I had intended to stay away from
this question. Ok, I'll give some general remarks:


Nunzio Daveri schrieb:
> [[...]]
>=20
> All, I was running slamdb against one of our QA boxes and noticed that =
the=20
> innodb database is 190Gb in size BUT the worrying issue is that the ind=
exes are=20
> 30GB in size!!! When I hit this server hard, it tanks on memory but st=
ill=20
> performs, slower of course ;-)

Having indexes which are larger than RAM is (in itself) not critical.
IMO, it becomes bad only when accesses to these indexes are spread so
wide that even the index pages become subject to frequent IO.

> Any suggestions on what I should do? I=
am=20
> thinking of doing one of these:

Whether any action is needed, and which, depends on the problem you
experience:

- If the system as a whole (both CPU and disk) has a significant idle
percentage, it isn't yet maxed out, and I don't expect that adding
resources would improve performance significantly.

- If your CPUs have significant "waiting for IO" percentage, then data
accesses need speedup. This could be done by faster disks, but I would
expect more results from adding RAM for larger caches.
This holds especially if your disk throughput is close to the possible
maximum.
(Assuming your bulk work is read/select. If it is insert/update, then
*removing* indexes might reduce the workload, as there are fewer
indexes to maintain.)

- If your CPUs are "busy", then I don't expect any increase of caching
would help.

>=20
> 1. Remove all queries, run for a few days, look at the slow query logs =
and then=20
> find those queries that really need them and index those specificially =
for=20
> performance.

Makes sense (only) if you have indexes which aren't really helpful for
accesses, so they just add maintenance load. If you do few
inserts/updates, an unused index should be paged out and not do much harm=

Comes with the cost of reduced performance during that test time, and
the need to rebuild the essential indexes afterwards. Has the benefit of
getting rid of unused indexes (which just cause maintenance load).

> 2. Split the single server into two servers both with 16 gb and 2 quad =
core=20
> cpu's. One master the other a slave.

Makes sense if your CPUs are busy, *and* you can distribute the read
accesses to the two servers (=3D most accesses are select). If most load
is insert/update, I don't expect a real improvement.
Biggest cost in hardware and admin effort, so I would do this only after
a decent analysis. OTOH, it gives you some (hardware) fault tolerance,
this could be an important argument depending on your requirements.

> 3. Just add another 16gb (32GB total) and that should take care of the =
indexing=20
> issue.

Makes sense if the disks are the bottleneck (CPUs are in "waiting for
IO"), so that larger caches will avoid disk accesses.
Assumes your machine supports that amount of RAM (many mainboards have a
limit at 16 GB, AIUI).

>=20
> Anyone had this problem before???
>=20
> Oh this is a single box, 100% mysql only and it talks to 3 front end iP=
lanet web=20
>=20
> servers that hit it with a few hundread queries per second.

For a specific answer, the distribution of accesses between read and
write is needed, as well as information which resource is close to the
limit.


HTH,
Jörg

--=20
Joerg Bruehe, MySQL Build Team, joerg.bruehe@oracle.com
(+49 30) 417 01 487
ORACLE Deutschland B.V. & Co. KG, Komturstrasse 18a, D-12099 Berlin
Geschaeftsfuehrer: Juergen Kunz, Marcel v.d. Molen, Alexander v.d. Ven
Amtsgericht Muenchen: HRA 95603


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=3Dgcdmg-mysql-2@m.gmane.o rg

Re: Indexes larger than RAM (was: Do you know who can answer this question I posted yesterday please

--0-1022056100-1280516110=:67883
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks again :-) Nunzio =0A______________________________ __=
=0AFrom: Joerg Bruehe =0ATo: Nunzio Daveri daveri@yahoo.com>; mysQL General List =0A=0ASent: Fr=
i, July 30, 2010 1:31:54 PM=0ASubject: Re: Indexes larger than RAM (was: Do=
you know who can answer this =0Aquestion I posted yesterday please?) =
Hi! =0AI am no InnoDB and tuning expert, so I had intended to stay awa=
y from=0Athis question. Ok, I'll give some general remarks: =0ANunzio =
Daveri schrieb:=0A> [[...]]=0A> =0A> All, I was running slamdb against one =
of our QA boxes and noticed that the =0A> innodb database is 190Gb in size =
BUT the worrying issue is that the indexes are =0A>=0A> 30GB in size!!!=A0 =
When I hit this server hard, it tanks on memory but still =0A> performs, sl=
ower of course ;-) Having indexes which are larger than RAM is (in its=
elf) not critical.=0AIMO, it becomes bad only when accesses to these indexe=
s are spread so=0Awide that even the index pages become subject to frequent=
IO. >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
Any suggestions on what I should do?=A0 I am =0A> thinking of doing one of =
these: Whether any action is needed, and which, depends on the problem=
you=0Aexperience: - If the system as a whole (both CPU and disk) has =
a significant idle   percentage, it isn't yet maxed out, and I don't ex=
pect that adding   resources would improve performance significantly.=
- If your CPUs have significant "waiting for IO" percentage, then dat=
a   accesses need speedup. This could be done by faster disks, but I wo=
uld   expect more results from adding RAM for larger caches.   This=
holds especially if your disk throughput is close to the possible   ma=
ximum.   (Assuming your bulk work is read/select. If it is insert/updat=
e, then   *removing* indexes might reduce the workload, as there are fe=
wer   indexes to maintain.) - If your CPUs are "busy", then I don'=
t expect any increase of caching   would help. > =0A> 1. Remove al=
l queries, run for a few days, look at the slow query logs and then =0A>=0A=
> find those queries that really need them and index those specificially fo=
r =0A> performance. Makes sense (only) if you have indexes which aren'=
t really helpful for=0Aaccesses, so they just add maintenance load. If you =
do few=0Ainserts/updates, an unused index should be paged out and not do mu=
ch harm.=0AComes with the cost of reduced performance during that test time=
, and=0Athe need to rebuild the essential indexes afterwards. Has the benef=
it of=0Agetting rid of unused indexes (which just cause maintenance load).=
> 2. Split the single server into two servers both with 16 gb and 2 q=
uad core =0A> cpu's. One master the other a slave. Makes sense if your=
CPUs are busy, *and* you can distribute the read=0Aaccesses to the two ser=
vers (=3D most accesses are select). If most load=0Ais insert/update, I don=
't expect a real improvement.=0ABiggest cost in hardware and admin effort, =
so I would do this only after=0Aa decent analysis. OTOH, it gives you some =
(hardware) fault tolerance,=0Athis could be an important argument depending=
on your requirements. > 3. Just add another 16gb (32GB total) and tha=
t should take care of the indexing =0A>=0A> issue. Makes sense if the =
disks are the bottleneck (CPUs are in "waiting for=0AIO"), so that larger c=
aches will avoid disk accesses.=0AAssumes your machine supports that amount=
of RAM (many mainboards have a=0Alimit at 16 GB, AIUI). > =0A> Anyone=
had this problem before???=0A> =0A> Oh this is a single box, 100% mysql on=
ly and it talks to 3 front end iPlanet =0A>web =0A>=0A> =0A> servers that h=
it it with a few hundread queries per second. For a specific answer, t=
he distribution of accesses between read and=0Awrite is needed, as well as =
information which resource is close to the=0Alimit. =0AHTH,=0AJörg=
-- =0AJoerg Bruehe,=A0 MySQL Build Team,=A0 joerg.bruehe@oracle.com=
  =A0 =A0 =A0 =A0 =A0 =A0 (+49 30) 417 01 487=0AORACLE Deutschland B.V=
.. & Co. KG,=A0 Komturstrasse 18a,=A0 D-12099 Berlin=0AGeschaeftsfuehrer: Ju=
ergen Kunz, Marcel v.d. Molen, Alexander v.d. Ven=0AAmtsgericht Muenchen: H=
RA 95603 =0A
--0-1022056100-1280516110=:67883--

Re: Indexes larger than RAM (was: Do you know who can answer this question I posted yesterday please

Nunzio Daveri,
Joerg Bruehe gave you a lot of good tips to try and speed things up.=
=20
A few hundred queries per second seem to be a relatively small number to=20
cause the server to crawl. I don't have the rest of your thread, but can=20
you publish some of the slow queries (see Slow Query Log) and the table=20
structure?

Mike


At 01:31 PM 7/30/2010, you wrote:
>Hi!
>
>
>I am no InnoDB and tuning expert, so I had intended to stay away from
>this question. Ok, I'll give some general remarks:
>
>
>Nunzio Daveri schrieb:
> > [[...]]
> >
> > All, I was running slamdb against one of our QA boxes and noticed that=
the
> > innodb database is 190Gb in size BUT the worrying issue is that the=20
> indexes are
> > 30GB in size!!! When I hit this server hard, it tanks on memory but=
still
> > performs, slower of course ;-)
>
>Having indexes which are larger than RAM is (in itself) not critical.
>IMO, it becomes bad only when accesses to these indexes are spread so
>wide that even the index pages become subject to frequent IO.
>
> > Any suggestions on what I should do? I=
am
> > thinking of doing one of these:
>
>Whether any action is needed, and which, depends on the problem you
>experience:
>
>- If the system as a whole (both CPU and disk) has a significant idle
> percentage, it isn't yet maxed out, and I don't expect that adding
> resources would improve performance significantly.
>
>- If your CPUs have significant "waiting for IO" percentage, then data
> accesses need speedup. This could be done by faster disks, but I would
> expect more results from adding RAM for larger caches.
> This holds especially if your disk throughput is close to the possible
> maximum.
> (Assuming your bulk work is read/select. If it is insert/update, then
> *removing* indexes might reduce the workload, as there are fewer
> indexes to maintain.)
>
>- If your CPUs are "busy", then I don't expect any increase of caching
> would help.
>
> >
> > 1. Remove all queries, run for a few days, look at the slow query logs=
=20
> and then
> > find those queries that really need them and index those specificially=
for
> > performance.
>
>Makes sense (only) if you have indexes which aren't really helpful for
>accesses, so they just add maintenance load. If you do few
>inserts/updates, an unused index should be paged out and not do much harm.
>Comes with the cost of reduced performance during that test time, and
>the need to rebuild the essential indexes afterwards. Has the benefit of
>getting rid of unused indexes (which just cause maintenance load).
>
> > 2. Split the single server into two servers both with 16 gb and 2 quad=
=20
> core
> > cpu's. One master the other a slave.
>
>Makes sense if your CPUs are busy, *and* you can distribute the read
>accesses to the two servers (=3D most accesses are select). If most load
>is insert/update, I don't expect a real improvement.
>Biggest cost in hardware and admin effort, so I would do this only after
>a decent analysis. OTOH, it gives you some (hardware) fault tolerance,
>this could be an important argument depending on your requirements.
>
> > 3. Just add another 16gb (32GB total) and that should take care of the=
=20
> indexing
> > issue.
>
>Makes sense if the disks are the bottleneck (CPUs are in "waiting for
>IO"), so that larger caches will avoid disk accesses.
>Assumes your machine supports that amount of RAM (many mainboards have a
>limit at 16 GB, AIUI).
>
> >
> > Anyone had this problem before???
> >
> > Oh this is a single box, 100% mysql only and it talks to 3 front end=20
> iPlanet web
> >
> > servers that hit it with a few hundread queries per second.
>
>For a specific answer, the distribution of accesses between read and
>write is needed, as well as information which resource is close to the
>limit.
>
>
>HTH,
>Jörg
>
>--
>Joerg Bruehe, MySQL Build Team, joerg.bruehe@oracle.com
> (+49 30) 417 01 487
>ORACLE Deutschland B.V. & Co. KG, Komturstrasse 18a, D-12099 Berlin
>Geschaeftsfuehrer: Juergen Kunz, Marcel v.d. Molen, Alexander v.d. Ven
>Amtsgericht Muenchen: HRA 95603
>
>
>--
>MySQL General Mailing List
>For list archives: http://lists.mysql.com/mysql
>To unsubscribe: http://lists.mysql.com/mysql?unsub=3Dmos99@fastmail.fm


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=3Dgcdmg-mysql-2@m.gmane.o rg