1、简介
my.cnf(my.ini) 文件是 MySQL 数据库的重要配置文件之一,它包含了 MySQL 服务器的启动参数和运行时配置。正确地配置 my.cnf (my.ini)文件可以显著提升数据库的性能、稳定性和安全性。
注:Linux服务器使用的是my.cnf,windows服务器使用的是my.ini
2、配置文件位置
在不同的操作系统上,my.cnf 文件的位置可能有所不同:
Linux: 通常位于 /etc/my.cnf 或 /etc/mysql/my.cnf,可以通过如下命令查看配置文件的查找路径
#mysql --help|grep 'my.cnf' |
---|
Windows: 通常位于 MySQL 安装目录下的 my.ini 文件
查看当前生效的my.cnf配置文件位置的SQL语句
SELECT |
---|
3、MySQL配置文件结构
my.cnf(my.ini)文件是一个文本文件,每个配置项都包含在一个特定的节(section)中,每个节由方括号 [ ] 包围,表示该节下的配置项适用于哪个组件或服务。常见的节包括:
- [mysqld]: 针对 MySQL 服务器的配置
- [client]: 针对所有客户端程序的配置
- [mysql]: 针对 mysql 命令行工具的配置
3.1 [mysqld]
3.1.1 基本设置
配置名称 | 配置说明 |
---|---|
basedir=/smartbi/mysql_8 | MySQL的安装目录 |
datadir=/smartbi/mysql_8/data | MySQL的数据存储目录 |
socket=/smartbi/mysql_8/mysql.sock | 为MySQL客户程序与服务器之间的本地通信指定一个套接字文件 |
character-set-server=gbk | 新数据库或数据表的默认字符集 |
port=6688 | MySQL指定的TCP/IP通信端口 |
3.1.2 性能优化
配置名称 | 配置说明 |
---|---|
innodb_buffer_pool_size = 1G | 缓冲池的大小(以字节为单位),即InnoDB缓存表和索引数据的内存区域。默认值为(128MB) |
interactive_timeout = 1800 | 交互超时时间,默认8小时 |
wait_timeout = 1800 | 等待超时时间,默认8小时 |
skip_name_resolve = 1 | 跳过反向解析过程 |
lower_case_table_names=1 | 大小写是否敏感配置 |
max_connections = 1024 | 最大连接数配置 |
max_connect_errors = 100000 | 最大连接错误数 |
max_allowed_packet=512M | 客户端和服务器之间可以传输的最大数据包大小 |
3.1.3 日志设置(非必需)
配置名称 | 配置说明 |
---|---|
slow_query_log=1 | 慢查询日志开关(1 开启,0 关闭),排查性能问题时开启,生产环境需要关闭 |
slow_query_log_file=/smartbi/mysql_8/data/mysql-slow.log | 慢查询日志文件路径 |
long_query_time=10 | 记录慢查询的时间阈值(秒),当前配置为10s |
4、实战
4.1 通过sysbench定位虚拟机多开导致的性能问题
4.1.1 背景说明
某项目上的2台Smartbi应用使用的是私有化腾讯云服务器,通过反向代理CLB对外提供服务,自上次扩容升级之后(服务器资源从8核32G升级到16核64G)整体TPS从200左右下降到100左右。
同时进行测试的其他业务系统都没有遇到类似情况,客户感觉不是硬件环境的问题,怀疑是因为产品自身问题导致的性能问题,让我们进行解决。
4.1.2 问题排查
常规能想到的软件问题都进行了一一排查和调优,但是整体TPS还是上不去,在公网购买相同配置的腾讯云服务器进行压测,单节点TPS非常容易就能达到200,怀疑是因为基础硬件导致的性能问题。
硬件的问题最难的是证明,项目组需要我们出具详细的问题说明材料证明是硬件问题才能够去协调腾讯的技术人员来进行处理,经过调研最终选择了使用sysbench这个基础测试工具进行验证反馈。
4.1.3 验证反馈
为排除Smartbi产品导致的性能差异,采用国际通用的sysbench测试工具进行对比测试,对比情况如下:
4.1.3.1 现场服务器和腾讯云服务器对比(性能相差约2倍)
在腾讯云购买和现场配置一样的云服务器(16核64G),使用sysbench 配置16个线程压测现场单节点Smartbi服务器VS腾讯云服务器60秒,发现现场的Smartbi服务器比腾讯云公有云服务器性能慢2倍左右。
#sysbench cpu --cpu-max-prime=20000 --threads=16 --time=60 run |
---|
1)客户现场16核服务器单节点测试情况 95%值为 3.8左右
2)腾讯云购买的16核服务器单节点 95%值为 1.3左右
4.1.3.2现场服务器16满核并发和单节点运行对比(性能相差约3倍)
使用sysbench 配置16个线程压测现场单节点Smartbi服务器VS现场双节点Smartbi服务器60秒,发现现场2台Smartbi服务器同时运行时会比单独1台Smartbi服务器运行性能差3倍左右。
#sysbench cpu --cpu-max-prime=20000 --threads=16 --time=60 run |
---|
1)现场2台Smartbi服务器同时运行 95%值为 17左右
2)现场单节点Smartbi服务器运行 95%值为 3.8左右
4.1.3.3 现场服务器10核并发和单节点10核运行对比(性能相差约3倍)
使用sysbench 配置10个线程压测现场单节点Smartbi服务器VS现场双节点Smartbi服务器60秒,发现现场2台Smartbi服务器同时运行时会比单独1台运行性能慢3倍左右。
#sysbench cpu --cpu-max-prime=20000 --threads=10 --time=60 run |
---|
1)现场2台Smartbi服务器同时运行 95%值为 15左右
2)现场单节点Smartbi服务器运行 95%值为 3.5左右
4.1.3.4 总结
1)现场使用的私有云服务器整体性能弱于公有云服务器,性能相差有2倍左右,这就证明为什么在公有云环境压测Smartbi时单节点很容易达到200TPS,而在用户现场环境单节点无论怎么调优也就100左右TPS。
2)2台Smartbi测试服务器在同时加压时会因为硬件资源争抢导致性能急剧下降,无论是否把CPU全部占满(10线程和16线程对比)单独压测任意一台Smartbi性能都比2台同时压测时性能相差3倍左右。
4.1.4 问题解决
把以上验证情况整理成文档后反馈给腾讯云后,经与腾讯云工程师沟通和了解到,客户现场的私有云是4倍超发(假如真实有4台裸金属服务器的话,通过虚拟化软件对外提的硬件资源池相当于16台裸金属服务器的资源),所以性能会对比公有云差距很大。
为什么出现升级配置后Smartbi的TPS下降的问题是因为在升配之前2台Smartbi是运行在不同的2台裸金属服务器上,压测时他们相互之间没有任何影响,升级扩容后把2台Smartbi服务器分配到了同一台裸金属服务器上了,就导致压测时会出现资源抢占导致的TPS下降问题。
后面腾讯云工程师手动把2台Smartbi服务器分配到不同的裸金属服务器后,再进行压测,TPS轻松就达到了200,满足了项目验收的要求。