RE: [Suspected Spam][Characteristics] RE: Slow Response -- What Does This Sound Like to You?
1. MyISAM locks _tables_. That can cause other connections
to be blocked. Solution: switch to InnoDB. Caution: There
are a few caveats when switching; see
https://kb.askmonty.org/en/converting-tables-from-myisam-to-innodb/
2. As mentioned by Shawn, the Query Cache can be more trouble
than it is worth. However 90 seconds cannot be blamed on the
QC. Still, shrink it or turn it off:
* If frequently writing to tables, turn it off (type=OFF _and_ size=0)
* If less frequently, then decide which queries will benefit,
add SQL_CACHE to them, set type=DEMAND and size=50M (no larger).
3. Meanwhile, try to make that long query more efficient.
Can you show it to us, together with SHOW CREATE TABLE, SHOW
TABLE STATUS, and EXPLAIN ?
Thanks for the feedback, Rick.
There are 1200+ tables in the database, so I don't think you want a SHOW CREATE
TABLE, SHOW TABLE STATUS, EXPLAIN for all of them. :-) The query in question is
always some variation of the following. From looking at this, which table(s)
would you like to see this information for?
# Time: 130507 18:14:26
# User@Host: site150_DbUser[site150_DbUser] @ cognos08.mycharts.md
[192.168.10.85]
# Query_time: 82 Lock_time: 0 Rows_sent: 1 Rows_examined: 914386
select (mod(dayofweek(`Query1`.`Appointment_Date`)+7-1,7)), {fn CONCAT({fn
CONCAT({fn CONCAT(cast(extract(hour from
`Time_Difference_Query`.`Created_Date`) as char(25)), ':')},
cast(extract(minute from `Time_Difference_Query`.`Created_Date`) as
char(25)))}, ':')}, `Time_Difference_Query`.`Created_Date`,
`Query1`.`Appointment_Provider_Name` from (select distinct
`EMR_ENCOUNTER`.`encType` as Encounter_Type , case when
`EMR_ENCOUNTER`.`encLock` = 0 then 'UnLocked' else 'Locked' end as
Chart_Lock_Status , `EMR_ENCOUNTER`.`notesDoneTime` as Notes_Done_Time ,
`EMR_ENCOUNTER`.`dateOut` as Notes_Done_Date , `EMR_ENCOUNTER`.`timeIn` as
Appointments_Checked_In , `EMR_ENCOUNTER`.`timeOut` as
Appointments_Checked_Out , `EMR_ENCOUNTER`.`depTime` as
Appointments_Departure_Time , `EMR_ENCOUNTER`.`arrivedTime` as
Appointments_Arrived_Time , `EMR_ENCOUNTER`.`endTime` as
Appointment_End_Time , `EMR_ENCOUNTER`.`startTime` as
Appointment_Start_Time , `EMR_ENCOUNTER`.`date` as Appointment_Date ,
`EMR_ENCOUNTER`.`encounterID` as Encounter_ID , `EDI_FACILITIES`.`Name` as
Facility_Name , `APPOINTMENT_PROVIDER`.`uid` as Appointment_Provider_ID ,
{fn CONCAT({fn CONCAT({fn CONCAT({fn CONCAT(`APPOINTMENT_PROVIDER`.`ulname`, ',
')}, `APPOINTMENT_PROVIDER`.`ufname`)}, ' ')},
`APPOINTMENT_PROVIDER`.`uminitial`)} as Appointment_Provider_Name from
(`enc` `EMR_ENCOUNTER` LEFT OUTER JOIN `edi_facilities` `EDI_FACILITIES` on
`EMR_ENCOUNTER`.`facilityId` = `EDI_FACILITIES`.`Id`) LEFT OUTER JOIN
(`doctors` `APPOINTMENT_DOCTOR` INNER JOIN `users` `APPOINTMENT_PROVIDER` on
`APPOINTMENT_DOCTOR`.`doctorID` = `APPOINTMENT_PROVIDER`.`uid`) on
`EMR_ENCOUNTER`.`doctorID` = `APPOINTMENT_DOCTOR`.`doctorID` where
`EMR_ENCOUNTER`.`encType` = 2 and `EMR_ENCOUNTER`.`date` between
cast('2011-01-01' as date) and cast('2013-05-07' as date) and
`EMR_ENCOUNTER`.`patientID` 8663 and `EMR_ENCOUNTER`.`VisitType` 'PTDASH'
and `EMR_ENCOUNTER`.`deleteFlag` = 0 and `APPOINTMENT_PROVIDER`.`UserType` = 1
and `APPOINTMENT_PROVIDER`.`delFlag` = 0 and `EDI_FACILITIES`.`DeleteFlag` = 0)
`Query1` LEFT OUTER JOIN (select distinct `Addressed_Query`.`moddate` as
Locked_Date , `Created_Query`.`moddate` as Created_Date ,
`Created_Query`.`encounterid` as encounterid , `Created_Query`.`reason` as
reason , `Created_Query`.`Patient_Name` as Patient_Name from (select
distinct `SQL1`.`moddate` as moddate , `SQL1`.`encounterid` as encounterid
, `SQL1`.`actionflag` as actionflag , `SQL1`.`ufname` as ufname ,
`SQL1`.`ulname` as ulname , `SQL1`.`reason` as reason , {fn CONCAT({fn
CONCAT(`SQL1`.`ulname`, ', ')}, `SQL1`.`ufname`)} as Patient_Name from
(select users.ufname,users.ulname,cast(reason as char(30)) as reason,
telenc_loghist.actionflag,telenc_loghist.encounterid,telenc_loghist.moddate
from telenc_loghist
inner join enc on
enc.encounterid=telenc_loghist.encounterid
inner join users on users.uid=enc.patientid where
actionflag in(0) and enc.date between '2011-01-01' and '2013-05-07') `SQL1`)
`Created_Query` LEFT OUTER JOIN (select distinct `Q2`.`moddate` as moddate ,
`Q2`.`encounterid` as encounterid , `Q2`.`actionflag` as actionflag from
(select
telenc_loghist.actionflag,telenc_loghist.encounterid,telenc_loghist.moddate
from telenc_loghist
inner join enc on
enc.encounterid=telenc_loghist.encounterid where actionflag in(4) and enc.date
between '2011-01-01' and '2013-05-07') `Q2`) `Addressed_Query` on
`Created_Query`.`encounterid` = `Addressed_Query`.`encounterid` where NOT
`Addressed_Query`.`moddate` is null) `Time_Difference_Query` on
`Query1`.`Encounter_ID` = `Time_Difference_Query`.`encounterid` where
RE: Slow Response -- What Does This Sound Like to You?
`.`Facility_Name` in ('Fremont Family Care')
and `Query1`.`Appointment_Date` between cast(cast('2011-01-01' as date)
as date)
and cast(cast('2013-05-07' as date)
as date)
and `Query1`.`Appointment_Provider_ID` = 60922;
---
The big problem is
FROM ( SELECT ... ) JOIN ( SELECT ... ) ON ...
Neither of those subqueries has an index, so there will be table scans. The
solution is to CREATE TEMPORARY TABLE ... SELECT for each one, then add an
index.
You SELECT a bunch of rows as Query1, then filter?? Can't you move the
filtering into the subquery??
There is no need for either CAST in cast(cast('2013-05-07' as date) as date);
simply use '2013-05-07'.
What does the {} syntax do??
Contradictory:
where `Query1`.`Appointment_Provider_ID` in (9118, 9119, 60922, 9116,
47495)
and `Query1`.`Appointment_Provider_ID` = 60922;
The IN filter does nothing useful.
I think those changes will make the query run _much_ faster. If not, provide
the SHOW CREATE TABLE for the tables being used here, plus EXPLAIN SELECT.
-Original Message-
From: Robinson, Eric [mailto:eric.robin...@psmnv.com]
Sent: Friday, May 10, 2013 11:36 AM
To: Rick James; Bruce Ferrell; mysql@lists.mysql.com
Subject: RE: [Suspected Spam][Characteristics] RE: Slow Response --
What Does This Sound Like to You?
1. MyISAM locks _tables_. That can cause other connections to be
blocked. Solution: switch to InnoDB. Caution: There are a few
caveats when switching; see
https://kb.askmonty.org/en/converting-tables-from-myisam-to-innodb/
2. As mentioned by Shawn, the Query Cache can be more trouble than it
is worth. However 90 seconds cannot be blamed on the QC. Still,
shrink it or turn it off:
* If frequently writing to tables, turn it off (type=OFF _and_
size=0)
* If less frequently, then decide which queries will benefit, add
SQL_CACHE to them, set type=DEMAND and size=50M (no larger).
3. Meanwhile, try to make that long query more efficient.
Can you show it to us, together with SHOW CREATE TABLE, SHOW TABLE
STATUS, and EXPLAIN ?
Thanks for the feedback, Rick.
There are 1200+ tables in the database, so I don't think you want a
SHOW CREATE TABLE, SHOW TABLE STATUS, EXPLAIN for all of them. :-) The
query in question is always some variation of the following. From
looking at this, which table(s) would you like to see this information
for?
# Time: 130507 18:14:26
# User@Host: site150_DbUser[site150_DbUser] @ cognos08.mycharts.md
[192.168.10.85] # Query_time: 82 Lock_time: 0 Rows_sent: 1
Rows_examined: 914386 select
(mod(dayofweek(`Query1`.`Appointment_Date`)+7-1,7)), {fn CONCAT({fn
CONCAT({fn CONCAT(cast(extract(hour from
`Time_Difference_Query`.`Created_Date`) as char(25)), ':')},
cast(extract(minute from `Time_Difference_Query`.`Created_Date`) as
char(25)))}, ':')}, `Time_Difference_Query`.`Created_Date`,
`Query1`.`Appointment_Provider_Name` from (select distinct
`EMR_ENCOUNTER`.`encType` as Encounter_Type , case when
`EMR_ENCOUNTER`.`encLock` = 0 then 'UnLocked' else 'Locked' end as
Chart_Lock_Status , `EMR_ENCOUNTER`.`notesDoneTime` as
Notes_Done_Time , `EMR_ENCOUNTER`.`dateOut` as Notes_Done_Date ,
`EMR_ENCOUNTER`.`timeIn` as Appointments_Checked_In ,
`EMR_ENCOUNTER`.`timeOut` as Appointments_Checked_Out ,
`EMR_ENCOUNTER`.`depTime` as Appointments_Departure_Time ,
`EMR_ENCOUNTER`.`arrivedTime` as Appointments_Arrived_Time ,
`EMR_ENCOUNTER`.`endTime` as Appointment_End_Time ,
`EMR_ENCOUNTER`.`startTime` as Appointment_Start_Time ,
`EMR_ENCOUNTER`.`date` as Appointment_Date ,
`EMR_ENCOUNTER`.`encounterID` as Encounter_ID ,
`EDI_FACILITIES`.`Name` as Facility_Name ,
`APPOINTMENT_PROVIDER`.`uid` as Appointment_Provider_ID , {fn
CONCAT({fn CONCAT({fn CONCAT({fn
CONCAT(`APPOINTMENT_PROVIDER`.`ulname`, ', ')},
`APPOINTMENT_PROVIDER`.`ufname`)}, ' ')},
`APPOINTMENT_PROVIDER`.`uminitial`)} as Appointment_Provider_Name
from (`enc` `EMR_ENCOUNTER` LEFT OUTER JOIN `edi_facilities`
`EDI_FACILITIES` on `EMR_ENCOUNTER`.`facilityId` =
`EDI_FACILITIES`.`Id`) LEFT OUTER JOIN (`doctors` `APPOINTMENT_DOCTOR`
INNER JOIN `users` `APPOINTMENT_PROVIDER` on
`APPOINTMENT_DOCTOR`.`doctorID` = `APPOINTMENT_PROVIDER`.`uid`) on
`EMR_ENCOUNTER`.`doctorID` = `APPOINTMENT_DOCTOR`.`doctorID` where
`EMR_ENCOUNTER`.`encType` = 2 and `EMR_ENCOUNTER`.`date` between
cast('2011-01-01' as date) and cast('2013-05-07' as date) and
`EMR_ENCOUNTER`.`patientID` 8663 and `EMR_ENCOUNTER`.`VisitType`
'PTDASH' and `EMR_ENCOUNTER`.`deleteFlag` = 0 and
`APPOINTMENT_PROVIDER`.`UserType` = 1 and
`APPOINTMENT_PROVIDER`.`delFlag` = 0 and `EDI_FACILITIES`.`DeleteFlag`
= 0) `Query1` LEFT OUTER JOIN (select distinct
`Addressed_Query`.`moddate` as Locked_Date ,
`Created_Query`.`moddate` as Created_Date ,
`Created_Query`.`encounterid` as encounterid ,
`Created_Query`.`reason` as reason
RE: Slow Response -- What Does This Sound Like to You?
MyISAM? Or InnoDB? Lock_time perhaps applies only to table locks on MyISAM. SHOW ENGINE InnoDB STATUS; You may find some deadlocks. Is Replication involved? Anyone doing an ALTER? -Original Message- From: Robinson, Eric [mailto:eric.robin...@psmnv.com] Sent: Thursday, May 09, 2013 1:58 PM To: mysql@lists.mysql.com Subject: Slow Response -- What Does This Sound Like to You? We have a situation where users complain that the system periodically freezes for 30-90 seconds. We check the slow query logs and find that one user issued a complex query that did indeed take 30-90 seconds to complete. However, NO slow queries are recorded for the other 50 users, before, during, or after the freeze. Note that the complex query in question always shows: Lock_time: 0. Q: What conditions could cause single query to lock up a database for a while for all users (even though it shows lock time: 0) but no other slow queries would show in the logs for any other users who are hitting the database at the same time? OS: RHEL3 x64 CPU: 8 x 2.9GHz Xeon RAM: 32GB Disk: RAID 5 (6 x 512GB SSD) MySQL: 5.0.95 x64 Engine: MyISAM -- Eric Robinson Disclaimer - May 9, 2013 This email and any files transmitted with it are confidential and intended solely for mysql@lists.mysql.com. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Physicians' Managed Care or Physician Select Management. Warning: Although Physicians' Managed Care or Physician Select Management has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. This disclaimer was added by Policy Patrol: http://www.policypatrol.com/ -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
RE: Slow Response -- What Does This Sound Like to You?
-Original Message- From: Robinson, Eric [mailto:eric.robin...@psmnv.com] Sent: Thursday, May 09, 2013 1:58 PM To: mysql@lists.mysql.com Subject: Slow Response -- What Does This Sound Like to You? We have a situation where users complain that the system periodically freezes for 30-90 seconds. We check the slow query logs and find that one user issued a complex query that did indeed take 30-90 seconds to complete. However, NO slow queries are recorded for the other 50 users, before, during, or after the freeze. Note that the complex query in question always shows: Lock_time: 0. Q: What conditions could cause single query to lock up a database for a while for all users (even though it shows lock time: 0) but no other slow queries would show in the logs for any other users who are hitting the database at the same time? OS: RHEL3 x64 CPU: 8 x 2.9GHz Xeon RAM: 32GB Disk: RAID 5 (6 x 512GB SSD) MySQL: 5.0.95 x64 Engine: MyISAM MyISAM? Or InnoDB? Lock_time perhaps applies only to table locks on MyISAM. SHOW ENGINE InnoDB STATUS; You may find some deadlocks. Is Replication involved? Anyone doing an ALTER? MyISAM, no replication involved, and nobody is altering the database. This happens whenever people run certain reports. --Eric Disclaimer - May 9, 2013 This email and any files transmitted with it are confidential and intended solely for Rick James,mysql@lists.mysql.com. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Physicians' Managed Care or Physician Select Management. Warning: Although Physicians' Managed Care or Physician Select Management has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. This disclaimer was added by Policy Patrol: http://www.policypatrol.com/ -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: Slow Response -- What Does This Sound Like to You?
I delt with a similar situation where users complained the system would freeze up for 30-60 seconds at random intervals. After days of looking at queries, logs, error logs, etc.. We were no closer to finding a solution. We do have a service that runs every 15 minutes to cache some data in our system, in one app it creates some temporary tables. In this app the tables were not being created as memory tables. Since we also use connection pooling, the temporary tables created evey 15 minutes were not dropped when the task completed. When the connection was finally closed there were a lot of temporary tables to drop and the MySQL server would hang while this process was completed. Changing to memory tables solved the problem. Might not be your issue but it reminded me of this. On Thursday, May 9, 2013, Robinson, Eric wrote: We have a situation where users complain that the system periodically freezes for 30-90 seconds. We check the slow query logs and find that one user issued a complex query that did indeed take 30-90 seconds to complete. However, NO slow queries are recorded for the other 50 users, before, during, or after the freeze. Note that the complex query in question always shows: Lock_time: 0. Q: What conditions could cause single query to lock up a database for a while for all users (even though it shows lock time: 0) but no other slow queries would show in the logs for any other users who are hitting the database at the same time? OS: RHEL3 x64 CPU: 8 x 2.9GHz Xeon RAM: 32GB Disk: RAID 5 (6 x 512GB SSD) MySQL: 5.0.95 x64 Engine: MyISAM -- Eric Robinson Disclaimer - May 9, 2013 This email and any files transmitted with it are confidential and intended solely for mysql@lists.mysql.com javascript:;. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Physicians' Managed Care or Physician Select Management. Warning: Although Physicians' Managed Care or Physician Select Management has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. This disclaimer was added by Policy Patrol: http://www.policypatrol.com/ -- - Johnny Withers 601.209.4985 joh...@pixelated.net
Re: Slow Response -- What Does This Sound Like to You?
Am 09.05.2013 22:58, schrieb Robinson, Eric: Q: What conditions could cause single query to lock up a database for a while for all users From http://docs.oracle.com/cd/E17952_01/refman-5.5-en/table-locking.html : A SELECT statement that takes a long time to run prevents other sessions from updating the table in the meantime, making the other sessions appear slow or unresponsive. While a session is waiting to get exclusive access to the table for updates, other sessions that issue SELECT statements will queue up behind it, reducing concurrency even for read-only sessions. You might try using low_priority_updates to mitigate this. Regards, -- Denis Jedig syneticon networks gmbh -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
RE: Slow Response -- What Does This Sound Like to You?
On Thu, May 9, 2013 15:25, Robinson, Eric wrote: -Original Message- From: Robinson, Eric [mailto:eric.robin...@psmnv.com] Sent: Thursday, May 09, 2013 1:58 PM To: mysql@lists.mysql.com Subject: Slow Response -- What Does This Sound Like to You? We have a situation where users complain that the system periodically freezes for 30-90 seconds. We check the slow query logs and find that one user issued a complex query that did indeed take 30-90 seconds to complete. However, NO slow queries are recorded for the other 50 users, before, during, or after the freeze. Note that the complex query in question always shows: Lock_time: 0. Q: What conditions could cause single query to lock up a database for a while for all users (even though it shows lock time: 0) but no other slow queries would show in the logs for any other users who are hitting the database at the same time? OS: RHEL3 x64 CPU: 8 x 2.9GHz Xeon RAM: 32GB Disk: RAID 5 (6 x 512GB SSD) MySQL: 5.0.95 x64 Engine: MyISAM MyISAM? Or InnoDB? Lock_time perhaps applies only to table locks on MyISAM. SHOW ENGINE InnoDB STATUS; You may find some deadlocks. Is Replication involved? Anyone doing an ALTER? MyISAM, no replication involved, and nobody is altering the database. This happens whenever people run certain reports. --Eric This may be a dumb question, but have you verified that the applications do not issue a Lock TABLES ...? Either the big one or one of the others. -- William R. Mussatto Systems Engineer http://www.csz.com 909-920-9154 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
RE: Slow Response -- What Does This Sound Like to You?
-Original Message- From: Wm Mussatto [mailto:mussa...@csz.com] Sent: Thursday, May 09, 2013 3:50 PM To: Robinson, Eric Cc: Rick James; mysql@lists.mysql.com Subject: RE: Slow Response -- What Does This Sound Like to You? On Thu, May 9, 2013 15:25, Robinson, Eric wrote: -Original Message- From: Robinson, Eric [mailto:eric.robin...@psmnv.com] Sent: Thursday, May 09, 2013 1:58 PM To: mysql@lists.mysql.com Subject: Slow Response -- What Does This Sound Like to You? We have a situation where users complain that the system periodically freezes for 30-90 seconds. We check the slow query logs and find that one user issued a complex query that did indeed take 30-90 seconds to complete. However, NO slow queries are recorded for the other 50 users, before, during, or after the freeze. Note that the complex query in question always shows: Lock_time: 0. Q: What conditions could cause single query to lock up a database for a while for all users (even though it shows lock time: 0) but no other slow queries would show in the logs for any other users who are hitting the database at the same time? OS: RHEL3 x64 CPU: 8 x 2.9GHz Xeon RAM: 32GB Disk: RAID 5 (6 x 512GB SSD) MySQL: 5.0.95 x64 Engine: MyISAM MyISAM? Or InnoDB? Lock_time perhaps applies only to table locks on MyISAM. SHOW ENGINE InnoDB STATUS; You may find some deadlocks. Is Replication involved? Anyone doing an ALTER? MyISAM, no replication involved, and nobody is altering the database. This happens whenever people run certain reports. --Eric This may be a dumb question, but have you verified that the applications do not issue a Lock TABLES ...? Either the big one or one of the others. I have not verified this, but it should be easy to find out. Hopefully that is not the case as it is a canned application and we don't have access to the code. --Eric Disclaimer - May 9, 2013 This email and any files transmitted with it are confidential and intended solely for Wm Mussatto,Rick James,mysql@lists.mysql.com. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Physicians' Managed Care or Physician Select Management. Warning: Although Physicians' Managed Care or Physician Select Management has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. This disclaimer was added by Policy Patrol: http://www.policypatrol.com/ -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: Slow Response -- What Does This Sound Like to You?
Hello Eric, On 5/9/2013 7:13 PM, Robinson, Eric wrote: -Original Message- From: Wm Mussatto [mailto:mussa...@csz.com] Sent: Thursday, May 09, 2013 3:50 PM To: Robinson, Eric Cc: Rick James; mysql@lists.mysql.com Subject: RE: Slow Response -- What Does This Sound Like to You? On Thu, May 9, 2013 15:25, Robinson, Eric wrote: -Original Message- From: Robinson, Eric [mailto:eric.robin...@psmnv.com] Sent: Thursday, May 09, 2013 1:58 PM To: mysql@lists.mysql.com Subject: Slow Response -- What Does This Sound Like to You? We have a situation where users complain that the system periodically freezes for 30-90 seconds. We check the slow query logs and find that one user issued a complex query that did indeed take 30-90 seconds to complete. However, NO slow queries are recorded for the other 50 users, before, during, or after the freeze. Note that the complex query in question always shows: Lock_time: 0. Q: What conditions could cause single query to lock up a database for a while for all users (even though it shows lock time: 0) but no other slow queries would show in the logs for any other users who are hitting the database at the same time? OS: RHEL3 x64 CPU: 8 x 2.9GHz Xeon RAM: 32GB Disk: RAID 5 (6 x 512GB SSD) MySQL: 5.0.95 x64 Engine: MyISAM MyISAM? Or InnoDB? Lock_time perhaps applies only to table locks on MyISAM. SHOW ENGINE InnoDB STATUS; You may find some deadlocks. Is Replication involved? Anyone doing an ALTER? MyISAM, no replication involved, and nobody is altering the database. This happens whenever people run certain reports. --Eric This may be a dumb question, but have you verified that the applications do not issue a Lock TABLES ...? Either the big one or one of the others. I have not verified this, but it should be easy to find out. Hopefully that is not the case as it is a canned application and we don't have access to the code. --Eric Another option to keep in mind is the effect of a very large Query Cache. Each change to a table must invalidate every query (and their results) that derived from that table. For large caches, that can bring the server to a cold halt until the purge complete. Try disabling it entirely and see how that affects performance or make it much smaller. -- Shawn Green MySQL Principal Technical Support Engineer Oracle USA, Inc. - Hardware and Software, Engineered to Work Together. Office: Blountville, TN -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: Slow Response -- What Does This Sound Like to You?
On 05/09/2013 03:25 PM, Robinson, Eric wrote: -Original Message- From: Robinson, Eric [mailto:eric.robin...@psmnv.com] Sent: Thursday, May 09, 2013 1:58 PM To: mysql@lists.mysql.com Subject: Slow Response -- What Does This Sound Like to You? We have a situation where users complain that the system periodically freezes for 30-90 seconds. We check the slow query logs and find that one user issued a complex query that did indeed take 30-90 seconds to complete. However, NO slow queries are recorded for the other 50 users, before, during, or after the freeze. Note that the complex query in question always shows: Lock_time: 0. Q: What conditions could cause single query to lock up a database for a while for all users (even though it shows lock time: 0) but no other slow queries would show in the logs for any other users who are hitting the database at the same time? OS: RHEL3 x64 CPU: 8 x 2.9GHz Xeon RAM: 32GB Disk: RAID 5 (6 x 512GB SSD) MySQL: 5.0.95 x64 Engine: MyISAM MyISAM? Or InnoDBm to have been finished Lock_time perhaps applies only to table locks on MyISAM. SHOW ENGINE InnoDB STATUS; You may find some deadlocks. Is Replication involved? Anyone doing an ALTER? MyISAM, no replication involved, and nobody is altering the database. This happens whenever people run certain reports. --Eric One thing I'd look at to start is the error log, if enabled. After that, I'd look at running mysqltuner to get a look at statistics before and after one of these events. I know there are those who prefer the Percona toolkit, but those pull lots raw stats and offers little in terms of suggestions... Unless you wish to engage Percona. Be aware, there are two versions of mysqltuner. The one I use is found at http://mysqltuner.pl. I know, it's old, but it at least runs. The newer one doesn't seem to have been brought to completion. You might want to enable the slow query option that logs queries that execute without indexes. They can be real killers. Reports that use views often cause this as views become complex joins under the hood that can easily miss your indexes resulting in full table scans. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
RE: Slow Response -- What Does This Sound Like to You?
1. MyISAM locks _tables_. That can cause other connections to be blocked. Solution: switch to InnoDB. Caution: There are a few caveats when switching; see https://kb.askmonty.org/en/converting-tables-from-myisam-to-innodb/ 2. As mentioned by Shawn, the Query Cache can be more trouble than it is worth. However 90 seconds cannot be blamed on the QC. Still, shrink it or turn it off: * If frequently writing to tables, turn it off (type=OFF _and_ size=0) * If less frequently, then decide which queries will benefit, add SQL_CACHE to them, set type=DEMAND and size=50M (no larger). 3. Meanwhile, try to make that long query more efficient. Can you show it to us, together with SHOW CREATE TABLE, SHOW TABLE STATUS, and EXPLAIN ? -Original Message- From: Bruce Ferrell [mailto:bferr...@baywinds.org] Sent: Thursday, May 09, 2013 6:05 PM To: mysql@lists.mysql.com Subject: Re: Slow Response -- What Does This Sound Like to You? On 05/09/2013 03:25 PM, Robinson, Eric wrote: -Original Message- From: Robinson, Eric [mailto:eric.robin...@psmnv.com] Sent: Thursday, May 09, 2013 1:58 PM To: mysql@lists.mysql.com Subject: Slow Response -- What Does This Sound Like to You? We have a situation where users complain that the system periodically freezes for 30-90 seconds. We check the slow query logs and find that one user issued a complex query that did indeed take 30-90 seconds to complete. However, NO slow queries are recorded for the other 50 users, before, during, or after the freeze. Note that the complex query in question always shows: Lock_time: 0. Q: What conditions could cause single query to lock up a database for a while for all users (even though it shows lock time: 0) but no other slow queries would show in the logs for any other users who are hitting the database at the same time? OS: RHEL3 x64 CPU: 8 x 2.9GHz Xeon RAM: 32GB Disk: RAID 5 (6 x 512GB SSD) MySQL: 5.0.95 x64 Engine: MyISAM MyISAM? Or InnoDBm to have been finished Lock_time perhaps applies only to table locks on MyISAM. SHOW ENGINE InnoDB STATUS; You may find some deadlocks. Is Replication involved? Anyone doing an ALTER? MyISAM, no replication involved, and nobody is altering the database. This happens whenever people run certain reports. --Eric One thing I'd look at to start is the error log, if enabled. After that, I'd look at running mysqltuner to get a look at statistics before and after one of these events. I know there are those who prefer the Percona toolkit, but those pull lots raw stats and offers little in terms of suggestions... Unless you wish to engage Percona. Be aware, there are two versions of mysqltuner. The one I use is found at http://mysqltuner.pl. I know, it's old, but it at least runs. The newer one doesn't seem to have been brought to completion. You might want to enable the slow query option that logs queries that execute without indexes. They can be real killers. Reports that use views often cause this as views become complex joins under the hood that can easily miss your indexes resulting in full table scans. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
RE: Slow Response -- What Does This Sound Like to You?
Hi everybody, I think we need to focus on three things:- A) temp tables created on disk B) table cache size C) buffer sizes If you find the number of temp tables created on disk is very large, please increase the temp_table_size. Enable the slow query log And check if sort buffer size and join buffer size needss to be increased if multiple joins are used. Also check whether the tables used in the slow queries do have index build on them or not. This heavily impacts the performance. If not create index on frequently used tables. Please try the above and let us know if resolved. Regards Vikas shukla -Original Message- From: Rick James rja...@yahoo-inc.com Sent: 10-05-2013 07:24 To: Bruce Ferrell bferr...@baywinds.org; mysql@lists.mysql.com mysql@lists.mysql.com Subject: RE: Slow Response -- What Does This Sound Like to You? 1. MyISAM locks _tables_. That can cause other connections to be blocked. Solution: switch to InnoDB. Caution: There are a few caveats when switching; see https://kb.askmonty.org/en/converting-tables-from-myisam-to-innodb/ 2. As mentioned by Shawn, the Query Cache can be more trouble than it is worth. However 90 seconds cannot be blamed on the QC. Still, shrink it or turn it off: * If frequently writing to tables, turn it off (type=OFF _and_ size=0) * If less frequently, then decide which queries will benefit, add SQL_CACHE to them, set type=DEMAND and size=50M (no larger). 3. Meanwhile, try to make that long query more efficient. Can you show it to us, together with SHOW CREATE TABLE, SHOW TABLE STATUS, and EXPLAIN ? -Original Message- From: Bruce Ferrell [mailto:bferr...@baywinds.org] Sent: Thursday, May 09, 2013 6:05 PM To: mysql@lists.mysql.com Subject: Re: Slow Response -- What Does This Sound Like to You? On 05/09/2013 03:25 PM, Robinson, Eric wrote: -Original Message- From: Robinson, Eric [mailto:eric.robin...@psmnv.com] Sent: Thursday, May 09, 2013 1:58 PM To: mysql@lists.mysql.com Subject: Slow Response -- What Does This Sound Like to You? We have a situation where users complain that the system periodically freezes for 30-90 seconds. We check the slow query logs and find that one user issued a complex query that did indeed take 30-90 seconds to complete. However, NO slow queries are recorded for the other 50 users, before, during, or after the freeze. Note that the complex query in question always shows: Lock_time: 0. Q: What conditions could cause single query to lock up a database for a while for all users (even though it shows lock time: 0) but no other slow queries would show in the logs for any other users who are hitting the database at the same time? OS: RHEL3 x64 CPU: 8 x 2.9GHz Xeon RAM: 32GB Disk: RAID 5 (6 x 512GB SSD) MySQL: 5.0.95 x64 Engine: MyISAM MyISAM? Or InnoDBm to have been finished Lock_time perhaps applies only to table locks on MyISAM. SHOW ENGINE InnoDB STATUS; You may find some deadlocks. Is Replication involved? Anyone doing an ALTER? MyISAM, no replication involved, and nobody is altering the database. This happens whenever people run certain reports. --Eric One thing I'd look at to start is the error log, if enabled. After that, I'd look at running mysqltuner to get a look at statistics before and after one of these events. I know there are those who prefer the Percona toolkit, but those pull lots raw stats and offers little in terms of suggestions... Unless you wish to engage Percona. Be aware, there are two versions of mysqltuner. The one I use is found at http://mysqltuner.pl. I know, it's old, but it at least runs. The newer one doesn't seem to have been brought to completion. You might want to enable the slow query option that logs queries that execute without indexes. They can be real killers. Reports that use views often cause this as views become complex joins under the hood that can easily miss your indexes resulting in full table scans. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
