Greetings all!
I have built a new server with MySQL and have noticed that before even doing anything to it I found that the MySQL logins were much slower than the 4.0 server I used prior to it. After moving data over to it, the application, (JFFNMS) when it would login to it would take forever getting data from it. It would finally get to a point where MySQL would not respond to anything including MySQLAdministrator. So I removed the 4.1 version that came with CentOS 4, I downloaded and installed the latest 4.0 version from the MySQL website and installed it and it is very fast even after moving the data to it. The problem I have is that I need php-mysql and perl-DBD-MySQL and when I install these two rpms, it removes the MySQL-server and MySQL-client rpm's that I retrieved from the MySQL website. So I am at a loss of what to do. I would prefere to go with MySQL 4.1 just because that is what comes with CentOS 4, short of that I need php-mysql to work with 4.0. Databases and custome building of RPM's is beyond my capabilities.
Any assistance will be GREATLY appreciated.
Thanks Chris
Chris Hammond wrote:
Greetings all!
I have built a new server with MySQL and have noticed that before even doing anything to it I found that the MySQL logins were much slower than the 4.0 server I used prior to it.
Just as a note, I have not noticed this problem at all -- my logins are just as fast/fine/snappy as always. Not sure what's wrong with your stuff..
I am at a loss of what to do. I would prefere to go with MySQL 4.1 just because that is what comes with CentOS 4, short of that I need php-mysql to work with 4.0. Databases and custome building of RPM's is beyond my capabilities.
You can use the builtin 4.1 *client* binaries (which are what php and it's ilk are linked to), while using the 4.0 server binaries. All you need to do is uninstall "mysql-server" RPM, install your downloaded 4.0 binary package to /usr/local/mysql/ (eg), and run the server from there using it's custom initscript.
Make sure the /etc/my.cnf is all configured nicely before bootstrapping the downloaded 4.0 install, and everything should just click (within reason). Most importantly, make sure the socket path and database path is set.
-te
Thanks, makes perfect sense but due to my lack of DB knowledge, I would have never thought of it. :( I downloaded the binary package, removed all traces of mysql packages and brought up the binary version of 4.0 in /usr/local/mysql using the script in support-files. I then yum installed php-mysql which brought in all the dependencies. I can connect with the "mysql" client in /usr/bin which is the 4.1 versions. However, JFFNMS still says that php-mysql is not loaded and cannot talk to the DB. How would you go about testing the php-mysql piece?
Thanks!!! Chris
Troy Engel wrote:
Chris Hammond wrote:
Greetings all!
I have built a new server with MySQL and have noticed that before even doing anything to it I found that the MySQL logins were much slower than the 4.0 server I used prior to it.
Just as a note, I have not noticed this problem at all -- my logins are just as fast/fine/snappy as always. Not sure what's wrong with your stuff..
I am at a loss of what to do. I would prefere to go with MySQL 4.1 just because that is what comes with CentOS 4, short of that I need php-mysql to work with 4.0. Databases and custome building of RPM's is beyond my capabilities.
You can use the builtin 4.1 *client* binaries (which are what php and it's ilk are linked to), while using the 4.0 server binaries. All you need to do is uninstall "mysql-server" RPM, install your downloaded 4.0 binary package to /usr/local/mysql/ (eg), and run the server from there using it's custom initscript.
Make sure the /etc/my.cnf is all configured nicely before bootstrapping the downloaded 4.0 install, and everything should just click (within reason). Most importantly, make sure the socket path and database path is set.
-te
I should have mentioned that JFFNMS on another server CAN talk to the DB so it is running properly.
Thanks Chris
Chris Hammond wrote:
Thanks, makes perfect sense but due to my lack of DB knowledge, I would have never thought of it. :( I downloaded the binary package, removed all traces of mysql packages and brought up the binary version of 4.0 in /usr/local/mysql using the script in support-files. I then yum installed php-mysql which brought in all the dependencies. I can connect with the "mysql" client in /usr/bin which is the 4.1 versions. However, JFFNMS still says that php-mysql is not loaded and cannot talk to the DB. How would you go about testing the php-mysql piece?
Thanks!!! Chris
Troy Engel wrote:
Chris Hammond wrote:
Greetings all!
I have built a new server with MySQL and have noticed that before even doing anything to it I found that the MySQL logins were much slower than the 4.0 server I used prior to it.
Just as a note, I have not noticed this problem at all -- my logins are just as fast/fine/snappy as always. Not sure what's wrong with your stuff..
I am at a loss of what to do. I would prefere to go with MySQL 4.1 just because that is what comes with CentOS 4, short of that I need php-mysql to work with 4.0. Databases and custome building of RPM's is beyond my capabilities.
You can use the builtin 4.1 *client* binaries (which are what php and it's ilk are linked to), while using the 4.0 server binaries. All you need to do is uninstall "mysql-server" RPM, install your downloaded 4.0 binary package to /usr/local/mysql/ (eg), and run the server from there using it's custom initscript.
Make sure the /etc/my.cnf is all configured nicely before bootstrapping the downloaded 4.0 install, and everything should just click (within reason). Most importantly, make sure the socket path and database path is set.
-te
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Ideas:
1) restart Apache, test again 2) install phpMyAdmin, and use that to ensure php-mysql works
-te
Chris Hammond wrote:
I should have mentioned that JFFNMS on another server CAN talk to the DB so it is running properly.
Thanks Chris
Chris Hammond wrote:
Thanks, makes perfect sense but due to my lack of DB knowledge, I would have never thought of it. :( I downloaded the binary package, removed all traces of mysql packages and brought up the binary version of 4.0 in /usr/local/mysql using the script in support-files. I then yum installed php-mysql which brought in all the dependencies. I can connect with the "mysql" client in /usr/bin which is the 4.1 versions. However, JFFNMS still says that php-mysql is not loaded and cannot talk to the DB. How would you go about testing the php-mysql piece?
Thanks!!! Chris
Troy Engel wrote:
Chris Hammond wrote:
Greetings all!
I have built a new server with MySQL and have noticed that before even doing anything to it I found that the MySQL logins were much slower than the 4.0 server I used prior to it.
Just as a note, I have not noticed this problem at all -- my logins are just as fast/fine/snappy as always. Not sure what's wrong with your stuff..
I am at a loss of what to do. I would prefere to go with MySQL 4.1 just because that is what comes with CentOS 4, short of that I need php-mysql to work with 4.0. Databases and custome building of RPM's is beyond my capabilities.
You can use the builtin 4.1 *client* binaries (which are what php and it's ilk are linked to), while using the 4.0 server binaries. All you need to do is uninstall "mysql-server" RPM, install your downloaded 4.0 binary package to /usr/local/mysql/ (eg), and run the server from there using it's custom initscript.
Make sure the /etc/my.cnf is all configured nicely before bootstrapping the downloaded 4.0 install, and everything should just click (within reason). Most importantly, make sure the socket path and database path is set.
-te
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Sorry for taking so long to reply but was unable over the weekend.
It is working. I did forget to restart apache. All is now well!
Thanks for all the replies and the assistance.
Chris
Troy Engel wrote:
Ideas:
- restart Apache, test again
- install phpMyAdmin, and use that to ensure php-mysql works
-te
Chris Hammond wrote:
I should have mentioned that JFFNMS on another server CAN talk to the DB so it is running properly.
Thanks Chris
Chris Hammond wrote:
Thanks, makes perfect sense but due to my lack of DB knowledge, I would have never thought of it. :( I downloaded the binary package, removed all traces of mysql packages and brought up the binary version of 4.0 in /usr/local/mysql using the script in support-files. I then yum installed php-mysql which brought in all the dependencies. I can connect with the "mysql" client in /usr/bin which is the 4.1 versions. However, JFFNMS still says that php-mysql is not loaded and cannot talk to the DB. How would you go about testing the php-mysql piece?
Thanks!!! Chris
Troy Engel wrote:
Chris Hammond wrote:
Greetings all!
I have built a new server with MySQL and have noticed that before even doing anything to it I found that the MySQL logins were much slower than the 4.0 server I used prior to it.
Just as a note, I have not noticed this problem at all -- my logins are just as fast/fine/snappy as always. Not sure what's wrong with your stuff..
I am at a loss of what to do. I would prefere to go with MySQL 4.1 just because that is what comes with CentOS 4, short of that I need php-mysql to work with 4.0. Databases and custome building of RPM's is beyond my capabilities.
You can use the builtin 4.1 *client* binaries (which are what php and it's ilk are linked to), while using the 4.0 server binaries. All you need to do is uninstall "mysql-server" RPM, install your downloaded 4.0 binary package to /usr/local/mysql/ (eg), and run the server from there using it's custom initscript.
Make sure the /etc/my.cnf is all configured nicely before bootstrapping the downloaded 4.0 install, and everything should just click (within reason). Most importantly, make sure the socket path and database path is set.
-te
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Some more information would be very helpful.
My first questions are: have you looked at what else might be happening on the server? was this a remote access situation where the problem could be on the network connection? Were there any other processes that may have been eating up all your CPU?
I have mysql 4.1.7 running without a problem, with a very large database. I also have the perl-DBD-mySQL module, etc.
I'm happy to help any way I can.
michael.
It works just fine with 4.0.24 so I has something to do with 4.1.x. I am sure it is not a "problem" with MySQL but something in my setup. The thing is, a simple default install is quick with 4.0.x but with my machine, which is a Sun dual Opteron box running CentOS 4 x86_64, is just dog slow. Of course I will want to get 4.1.x running, but I may have to come back to it.
At the time, there was nothing but MySQL running on the server, all unused services were shut off. The cpu was barely being touched.
Thanks Chris
Michael Weisman wrote:
Some more information would be very helpful.
My first questions are: have you looked at what else might be happening on the server? was this a remote access situation where the problem could be on the network connection? Were there any other processes that may have been eating up all your CPU?
I have mysql 4.1.7 running without a problem, with a very large database. I also have the perl-DBD-mySQL module, etc.
I'm happy to help any way I can.
michael.
On Apr 4, 2005 5:59 AM, Chris Hammond chris@tac.esi.net wrote:
It works just fine with 4.0.24 so I has something to do with 4.1.x. I am sure it is not a "problem" with MySQL but something in my setup. The thing is, a simple default install is quick with 4.0.x but with my machine, which is a Sun dual Opteron box running CentOS 4 x86_64, is just dog slow. Of course I will want to get 4.1.x running, but I may have to come back to it.
At the time, there was nothing but MySQL running on the server, all unused services were shut off. The cpu was barely being touched.
As you said, it would be worthwhile to capture the output of top. I like to use
# date >> /tmp/topper.txt; top -b -n 1 >> /tmp/topper.txt
You will get the top output in that text file - it can be useful to tweak other things in root's toprc prior to doing this (like hiding zombie processes). If I'm having weird problems like this on a box I frequently put that top command into a cron that runs every 5 or 10 minutes and you can see what's going on with the box.
Greg
Greg Knaddison wrote:
As you said, it would be worthwhile to capture the output of top. I like to use
# date >> /tmp/topper.txt; top -b -n 1 >> /tmp/topper.txt
Also install 'sysstat' (comes prepackaged with all modern RedHat/CentOS), which is a rewrite of the venerable sa* tools from Solaris for linux - namely, 'sar', 'iostat', 'mpstat' and their collection agents. Reviewing historical sar output can find a lot of trends and help find the problem.
-te
On Mon, 4 Apr 2005, Troy Engel wrote:
Also install 'sysstat' (comes prepackaged with all modern RedHat/CentOS), which is a rewrite of the venerable sa* tools from Solaris for linux - namely, 'sar', 'iostat', 'mpstat' and their collection agents. Reviewing historical sar output can find a lot of trends and help find the problem.
Dag's dstat is a even later, and perhaps friendlier implementation.
-- Russ Herrold
R P Herrold wrote:
On Mon, 4 Apr 2005, Troy Engel wrote:
Also install 'sysstat' (comes prepackaged with all modern RedHat/CentOS), which is a rewrite of the venerable sa* tools from
Dag's dstat is a even later, and perhaps friendlier implementation.
While not it any way knocking dstat, it's not the same thing as sar; sar uses two collection agents (sa1, sa2) to record historic data over intervals to be later interpreted. dstat is a realtime oriented diagnostic tool, not historic. They are best used together, as they have two seperate concepts in mind - I think it's better to only compare dstat with the specific realtime functionality of sar.
-te
-
Chris Hammond -
Greg Knaddison -
Michael Weisman -
R P Herrold -
Troy Engel