MySQL插入性能优化

对于默认安装的mysql，进行insert插入测试，发现QPS很低
通过iostat -x 1发现磁盘的IO很高

SHOW VARIABLES LIKE 'sync_binlog';
SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit';
SHOW VARIABLES LIKE 'innodb_flush_method';
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
SHOW VARIABLES LIKE 'innodb_io_capacity';

sync_binlog：二进制日志文件binlog的刷新写入方式

sync_binlog=0（默认值为0）
表示binlog不控制binlog的刷新，由文件系统自己控制它的缓存的刷新。这时候的性能是最好的（？？？），但是风险也是最大的。因为一旦系统Crash，在binlog_cache中的所有binlog信息都会被丢失。
sync_binlog=n（大于0的其他值）
表示每进行n次事务提交，mysql主动调用文件系统，将缓存刷新到磁盘中

innodb_flush_log_at_trx_commit：指定了 InnoDB 在事务提交后的日志写入方式

innodb_flush_log_at_trx_commit=0（性能最高，安全性最差）
log buffer 会每秒写入到日志文件并刷写（flush）到磁盘，不受每次事务提交的影响，也就是 log buffer 的刷写操作和事务提交操作没有关系。
在这种情况下，MySQL性能最好，但如果 mysqld 进程崩溃，通常会导致最后 1s 的日志丢失。
innodb_flush_log_at_trx_commit=1（默认值，性能最差，安全性最高）
每次事务提交时，log buffer 会被写入到日志文件并刷写到磁盘。
这是最安全的配置，但由于每次事务都需要进行磁盘I/O，所以也最慢。
innodb_flush_log_at_trx_commit=2（一般应该设置为2，折中方案）
每次事务提交会写入日志文件，但并不会立即刷写到磁盘，日志文件会每秒刷写一次到磁盘。
这时如果 mysqld 进程崩溃，由于日志已经写入到系统缓存，所以并不会丢失数据；在操作系统崩溃的情况下，通常会导致最后 1s 的日志丢失。

innodb_flush_method：这个参数控制着innodb数据文件及redo og的打开、刷写模式，有以下几种设置：

默认是fdatasync，调用fsync()去刷数据文件与redo log的buffer
为O_DSYNC时，innodb会使用O_SYNC方式打开和刷写redo log,使用fsync()刷写数据文件，通常比较慢。
为O_DIRECT时，innodb使用O_DIRECT打开数据文件，使用fsync()刷写数据文件跟redo log，在Linux上使用Direct IO，可以显著提高速度，特别是在RAID系统上，避免额外的数据复制和double buffering（mysql buffering 和OS buffering）。

innodb_buffer_pool_size：这是Innodb最重要的一个配置参数，这个参数控制Innodb本身的缓大小，也影响到，多少数据能在缓存中。建议该参数的配置在物理内存的70％－80％之间。

innodb_io_capacity：动态调整刷新脏页的数量。默认是200，单位是页。
该参数设置的大小取决于硬盘的IOPS，即每秒的输入输出量（或读写次数）。
至于什么样的磁盘配置应该设置innodb_io_capacity参数的值是多少，可参考：

动态设置（也可以在配置文件中设置）

SET GLOBAL sync_binlog = 100;
SET GLOBAL innodb_flush_log_at_trx_commit = 2;
SET GLOBAL innodb_io_capacity = 2000;

[mysqld]
# 配置性能优化
sync_binlog = 100
innodb_flush_log_at_trx_commit = 2
# O_DIRECT (避免双缓冲技术)
innodb_flush_method = O_DIRECT
# 设置为 RAM 大小的 50%-70%，不需要大于数据库的大小
innodb_buffer_pool_size = 6G
# 128M – 2G (不需要大于 buffer pool)
innodb_log_file_size = 2G
innodb_io_capacity = 2000

MongoDB聚合查询性能

TODO

使用kafka生产者，内存增长过快，频繁full gc

当kafka性能较差的时候，生产者可以设置批量发送，提高性能，同时可以解决内存占用过大的问题

大数据量入库方案的优化

场景：业务需要将大量的请求&响应消息写入mongo
方案一：直接写入（缺点：受mongo写入限制，速度慢）
方案二：使用队列，多线程写入（缺点：多线程并发写入容易导致mongo的资源占用忽高忽低，不稳定，表现为QPS忽高忽低）
方案三：由于kafka写入速度更快，先将数据写入kafka，然后起一个消费者慢慢入库

客户端网络状况较差对服务器的影响

待测试

springboot应用压力上不去的原因分析

？？？

服务器的QPS不稳定，波动很大

有可能是磁盘IO方面的问题，先从磁盘IO入手排查
有可能是GC导致（Java应用）
排查定时任务的影响

优质内容筛选与推荐>>
1、Django---MTV模型、基本命令、简单配置
2、Frambuff设备驱动框架
3、PowerDesigner设计建造MySQL数据库（mysql 导入sql文件）
4、微信小程序 - ios不能播放背景音乐
5、Ansible应用总结【第四篇】： Ansible之Window主机管理

0 │ 收藏 │ 举报