从 Mysql 5.5 升级后 Percona 5.7 慢 "Sending data"
Percona 5.7 slow "Sending data" after upgrade from Mysql 5.5
升级 Mysql 5.5 到 Percona 5.7 后,应用程序运行非常缓慢。
我无法优化查询,因为是用应用程序编译的
我唯一能做的就是优化 MySQL 服务器(或服务器配置)
我需要提一下,我看到一些查询 returns 大量数据(70M 的结果)
数据目录在 SSD 上。我有 32G RAM,但我分配了 20 给 Mysql(60% 因为我们还有其他小服务)
如果我激活缓存(将被弃用),我会注意到一个小改进
SHOW GLOBAL STATUS result is here
有人知道如何改进 MySQL 配置/或服务器以提高性能吗?
我以 SQL 和 explain 为例。它 returns 672 行数据但需要 30 秒(29 留在 "Sending data")。
explain select l.idCodeLocation as idLocation, l.txLocation as name, l.radius as radius, l.amLat as lat, l.amLong as lng, g.isin as isin, g.isout as isout, g.onval as onval, m.isGeofenceIn as isGeofenceIn, m.geofenceInTime as geofenceInTime, m.isGeofenceOn as isGeofenceOn, v.idVeh as idveh, v.idPlateVeh as plate, v.idClient as client from sat_geofence g left join sat_clientLocation as l on (g.idLocation=l.idCodeLocation) join sat_geofence_vehicle_mtm as m on (g.idLocation=m.idLocation) join sat_vehicle as v on (m.idVeh=v.idVeh);
+----+-------------+-------+------------+--------+---------------+---------+---------+-------------------+--------+----------+----------------------------------------------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+--------+---------------+---------+---------+-------------------+--------+----------+----------------------------------------------------+
| 1 | SIMPLE | g | NULL | ALL | idx | NULL | NULL | NULL | 38 | 100.00 | NULL |
| 1 | SIMPLE | m | NULL | ref | idx | idx | 768 | Stdb.g.idLocation | 5 | 100.00 | Using index condition |
| 1 | SIMPLE | v | NULL | eq_ref | PRIMARY | PRIMARY | 3 | Stdb.m.idVeh | 1 | 100.00 | Using where |
| 1 | SIMPLE | l | NULL | ALL | NULL | NULL | NULL | NULL | 116952 | 100.00 | Using where; Using join buffer (Block Nested Loop) |
+----+-------------+-------+------------+--------+---------------+---------+---------+-------------------+--------+----------+----------------------------------------------------+
我放在这里的表格结构:https://gist.github.com/costyoancea/deee560f9c94aa2463162d7ce0556392
谢谢,
科斯蒂
group_concat_max_len = 18446744073709565 -- dangerously large.
请提供SHOW GLOBAL STATUS
以帮助进行调优分析。你有多少内存?
即使您无法更改查询,也请向我们展示查询。我们或许可以建议一个有用的索引。
您缺少 m.idVeh 上的索引。 m 参考 sat_geofence_vehicle_mtm。请在第一个位置制作额外的简单索引。如需调整帮助,请查看我的个人资料、网络个人资料以获取联系信息。并在商店页面查看我的评论。
给你的建议 Linux ulimit -a limits
ulimit -n 65536 to increase Open File limit from 1024
要允许此值持续 Linux shutdown/restart,请查看此内容,
https://glassonionblog.wordpress.com/2013/01/27/increase-ulimit-and-file-descriptors-limit/
您的详细信息可能因 OS 版本而略有不同。
每秒速率=RPS
my.cnf [mysqld] 部分
的建议
join_buffer_size=128K # from 128M for a more reasonable RAM request per connection
sort_buffer_size=2M # from ~256M for a more reasonable RAM request per connection
innodb_lru_scan_depth=100 # from 1024 to reduce CPU cycles used every SECOND
innodb_flushing_avg_loops=5 # from 30 to reduce innodb_buffer_pool_pages_dirty 5,692
table_open_cache=10000 # from 4096 to reduce opened_tables RPHr 40,456
open_table_definitions=10000 # from 400 to reduce opened_table_definitions RPHr 21,459
thread_cache_size=100 # from 14 to reduce threads_created from 64
期待您的反馈和 7 天后在我的网站上发布的评论。
升级 Mysql 5.5 到 Percona 5.7 后,应用程序运行非常缓慢。 我无法优化查询,因为是用应用程序编译的 我唯一能做的就是优化 MySQL 服务器(或服务器配置)
我需要提一下,我看到一些查询 returns 大量数据(70M 的结果) 数据目录在 SSD 上。我有 32G RAM,但我分配了 20 给 Mysql(60% 因为我们还有其他小服务)
如果我激活缓存(将被弃用),我会注意到一个小改进
SHOW GLOBAL STATUS result is here
有人知道如何改进 MySQL 配置/或服务器以提高性能吗? 我以 SQL 和 explain 为例。它 returns 672 行数据但需要 30 秒(29 留在 "Sending data")。
explain select l.idCodeLocation as idLocation, l.txLocation as name, l.radius as radius, l.amLat as lat, l.amLong as lng, g.isin as isin, g.isout as isout, g.onval as onval, m.isGeofenceIn as isGeofenceIn, m.geofenceInTime as geofenceInTime, m.isGeofenceOn as isGeofenceOn, v.idVeh as idveh, v.idPlateVeh as plate, v.idClient as client from sat_geofence g left join sat_clientLocation as l on (g.idLocation=l.idCodeLocation) join sat_geofence_vehicle_mtm as m on (g.idLocation=m.idLocation) join sat_vehicle as v on (m.idVeh=v.idVeh);
+----+-------------+-------+------------+--------+---------------+---------+---------+-------------------+--------+----------+----------------------------------------------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+--------+---------------+---------+---------+-------------------+--------+----------+----------------------------------------------------+
| 1 | SIMPLE | g | NULL | ALL | idx | NULL | NULL | NULL | 38 | 100.00 | NULL |
| 1 | SIMPLE | m | NULL | ref | idx | idx | 768 | Stdb.g.idLocation | 5 | 100.00 | Using index condition |
| 1 | SIMPLE | v | NULL | eq_ref | PRIMARY | PRIMARY | 3 | Stdb.m.idVeh | 1 | 100.00 | Using where |
| 1 | SIMPLE | l | NULL | ALL | NULL | NULL | NULL | NULL | 116952 | 100.00 | Using where; Using join buffer (Block Nested Loop) |
+----+-------------+-------+------------+--------+---------------+---------+---------+-------------------+--------+----------+----------------------------------------------------+
我放在这里的表格结构:https://gist.github.com/costyoancea/deee560f9c94aa2463162d7ce0556392
谢谢, 科斯蒂
group_concat_max_len = 18446744073709565 -- dangerously large.
请提供SHOW GLOBAL STATUS
以帮助进行调优分析。你有多少内存?
即使您无法更改查询,也请向我们展示查询。我们或许可以建议一个有用的索引。
您缺少 m.idVeh 上的索引。 m 参考 sat_geofence_vehicle_mtm。请在第一个位置制作额外的简单索引。如需调整帮助,请查看我的个人资料、网络个人资料以获取联系信息。并在商店页面查看我的评论。
给你的建议 Linux ulimit -a limits
ulimit -n 65536 to increase Open File limit from 1024
要允许此值持续 Linux shutdown/restart,请查看此内容,
https://glassonionblog.wordpress.com/2013/01/27/increase-ulimit-and-file-descriptors-limit/
您的详细信息可能因 OS 版本而略有不同。
每秒速率=RPS my.cnf [mysqld] 部分
的建议join_buffer_size=128K # from 128M for a more reasonable RAM request per connection
sort_buffer_size=2M # from ~256M for a more reasonable RAM request per connection
innodb_lru_scan_depth=100 # from 1024 to reduce CPU cycles used every SECOND
innodb_flushing_avg_loops=5 # from 30 to reduce innodb_buffer_pool_pages_dirty 5,692
table_open_cache=10000 # from 4096 to reduce opened_tables RPHr 40,456
open_table_definitions=10000 # from 400 to reduce opened_table_definitions RPHr 21,459
thread_cache_size=100 # from 14 to reduce threads_created from 64
期待您的反馈和 7 天后在我的网站上发布的评论。