I've just installed MySQL 5.5 CE on a Windows Server 2008 R2 (SP1) with IIS 7.5.
Running a simple Joomla! 2.5.14 website, without extension, I've a response time of 2.8 seconds. Running a simple PHP file, the response time is in milliseconds, so I have excluded PHP/IIS problems.
Now, what I can do to optimize MySQL and reduce this response time?
I've already enabled "skip-name-resolve", set "key_buffer_size" as 512M and "query_cache_size" as 128M. My server has 2 CPU and 4GB of RAM.
Thanks!
I recommend enabling the MySQL slow query log in order to confirm that the problem in fact lies with MySQL. Based on the results that appear (or don't appear) in the slow query log file, you can pinpoint the problem(s) and, if necessary, optimize your MySQL server configuration or SQL queries.
Related
We've just moved to a new server, both run ubuntu 14.04LTS, the only difference is basically that the old server ran mysql5.5, the new one has mysql5.6. Both servers are cloud machines hosted by digitalocean. Both operate on default my.cnf settings, not much has been tweaked.
An other important difference is, that the new server has double the RAM, and CPU power.
Still - while old server ran with an avg of 0.6 second response time for an api call we monitor server health with, the new one is 1.6-1.8 slower. Yes, they contain heavy joins, but that's not my point - the codebase is exactly the same, and the machine itself is supposed to be stronger. New server also shows peaks of CPU usage few times every hour, which never happened with mysql 5.5.
Does this make any sense? For me, not so much, but I'm no MySQL guru.
Ran MySQL Tuner, but unsure if there's anything relevant within:
mysqltuner output for OLD server:
http://pastebin.com/cqSSssW0
mysqltuner output for NEW server:
http://pastebin.com/uk3g1KZa
The only thing that has been tweaked in my.cnf is that it should log slow queries.
Any idea, why this could happen? MySQL5.6 clearly runs faster on benchmarks I saw online. Any help is very much appreciated.
I have a a query which only takes 0.004s on my development machine (Windows 7 running WampServer on an HDD) but takes 0.057s on my production server (CENTOS 6.5 running on an SSD) -- a difference of 14x. Both MySQL versions are the same.
The explain results are identical on both servers, as are the databases (I exported the database from my production server and imported it into my development machine). I also ran optimize table on both servers, and tried putting in SQL_NO_CACHE, but that didn't make a difference on either one.
Navicat shows this under the Profile tab:
Production
Development
The execution times for the queries are consistent on both servers.
The database versions are the same, the content is the same, and the explain results are the same. Is there any way to determine why the query is taking 14x longer on my production server?
EDIT: In an attempt to determine if the MySQL server is under load, I found the Process List area in Navicat and can see that there are only a few processes, all of which are for "Sleep" commands. So I don't think the production server is under any load.
The production server seems to be slower in every parameter listed. There could be many factors involved, so you should check each one:
First of all, check if there is any other load on the production server. Is the server doing something else in the meanwhile? Use Linux command top to see running process and check if any of them is using a lot of computing power. Use the MySQL command SHOW STATUS to get info about the MySQL server status (memory, open tables, current connections, etc.)
Check the hardware: nowadays some desktop PCs are more powerful than cheap virtual servers (CPU, RAM frequency and access times, ...)
MySQL could use different settings in the two environments
Make sure you have the same indexes on both databases.
I am deploying a MVC2 application under IIS7 on a Windows Server 2008 R2 server with plenty of horsepower. It's connecting to a SQL Server 2008 DB and the applications performance is dramatically slower than when running in the debugger on a developer workstation (connecting to the same SQL Server DB). I've already checked network connections and nothing in the eventlogs indicate an issue with Windows. I've also run the Profiler on the DB server and the queries are firing off fast.
Any help with diagnosing this performance issue would be appreciated. I've even built a new 2008 R2 server to test it on in hopes that it was the server itself but the performance was the same.
Thanks
Edit 1:
IIS is running on a Dell R710 server running Windows Server 2008 R2 Standard, 32GB ram. SQL Server 2008 is hosted on a separate R710 running Server 2008 R2 Standard, 12GB ram. Initially I had IIS running on a VM but I moved it to the physical machine to see if performance degradation was due to the VM. I'm experiencing the same performance on both so it looks like it wasn't a factor.
Edit 2:
It appears that opening the connection to the database is part of the bottleneck with the subsequent firing of stored procedures also taking a considerable amount of time:
-Open db connection: 5 sec (subsequent connections are cached so they don’t require 5 seconds)
-First sproc : < 1 sec
-Second sproc: 5 sec
-Third sproc: < 1 sec
-Fourth sproc: < 1 sec
-Fifth sproc: 6 sec
First, Windows Server 2008 R2 has IIS 7.5, not IIS7. Probably doesn't matter. However, it is a different version.
Second, you need to find out where the bottleneck is. Try removing the queries and just using dummy data. Is it still slow? If not, then it has nothing to do with the data access.. if so, then you know it's a data access issue.
Here are slides from a presentation about optimizing ASP.NET MVC applications. They were able to improve their app's performance from 8 req/sec to 400 req/sec.
They mention in the slides how they profiled it and identified bottlenecks (query compilation, many calls to RenderPartial, url generation etc.) and give some tips at the end of the presentation.
I have a very odd performance issue with an SSIS package in Sql Server 2008 R2.
Here the facts:
Recently we migrated from a Sql Server 2005 (on Windows Server 2003 R2 32bit) to Sql Server 2008 R2 (on Windows Server 2008 R2 64bit).
Everything seems to be fine except some performance issue on one SSIS package.
If i run it from my PC it runs fine in some minutes (around 4/5) and the same seems to happen if i connect to Integrations Services through SqlServer Management Studio and start the package from there.
However when i run it from Sql Server Agent i have execution time that goes from 5 minutes to more than one hour... I had no such problems with the old server! I also tried to run the package in 32bit mode, on some run it seems to be faster, but it's pretty random... However it never reach the good performance it had on Sql Server 2005.
I have no clue... initially i think it was a memory problem because i did not give maximum memory limit to Sql Server and some other package had problems to run at the same time, so I expanded the RAM used by the server (it runs on VMWare) and now the machine has 8GB of RAM and maximum server memory for Sql Server is 4GB. The other package has no crash now, but this is still giving random execution time...
Any guess?
Following a table of execution time through days
Start Time Execution Time
12/17/2010 06:15 00:49:43
12/16/2010 17:54 01:12:26
12/16/2010 17:18 00:06:29
12/16/2010 16:53 00:05:23
12/16/2010 16:10 00:24:23
12/16/2010 06:15 00:19:26
12/15/2010 06:15 00:07:19
12/14/2010 06:15 00:11:26
12/13/2010 06:15 00:17:30
12/12/2010 06:15 00:44:59
12/11/2010 06:15 00:11:59
12/10/2010 06:15 00:34:19
What else is running? Do you have users running queries (who may lock tables) or other packages touching related tables when this package is scheduled to run? When you run it, do you see blocking locks or anything else like that?
It's more likely to me that the production batch execution environment isn't as nice and quiet and controlled as your development environment.
A user or related package holding data locks might explain the random distribution of execution times.
I found a solution to this.
The problem was a memory issue with the buffer creation on the server.
I partially solved it increasing the default buffer size (both in MB and rows number) and completely solved it removing all the Sort and Merge component i used replacing them with Lookup on custom Cache built with Transform Cache component.
I still do not understand why the allocation in Sql Server 2005 with Windows Server 2003 and in development works fine, however now the package is fixed!
We use MySQL server 5.1.43 64-bit edition. InnoDB is used as engine.
We have a sql script which we execute every time we build the application.
On ubuntu machine with MySQL server and InnoDB engine it takes about 55 seconds to complete the execution.
If I run the same script on OSX, it takes close to 3 minutes!
Any ideas why OSX is so slow while executing this script?
You may want to try starting the server with my.ini changed
innodb_flush_log_at_trx_commit=2
and change back to
innodb_flush_log_at_trx_commit=1
for production usage.
I suspected that the fsync api in osx is slower than linux?
my crystal balls need more information.
its not the same executing a script against a db on the same machine , consider the network overhead. especially if the inserts are data intensive