nextcloud jbd2/dm-0-8进程占用内存过高
- 该话题包含 2个回复，1 人参与，最后由
更新于 2年、 11月前 。
- 帖子
- Up1
在客户端同步文件时，发现传输速度慢，
初步分析：
进入后台使用iotop 查看，发现 nextcloud jbd2/dm-0-8进程占用内存过高，达到了98%。这样导致mysql数据库连接出现间歇性的中断。
- Up0
有关jbd2进程的详细分析文章：性能分析解决jbd2引起的高io问题
1> 进入mysql后台
# mysql -uroot -p
mysql> show variables like ‘%sync_binlog%’;
+—————+——-+
| Variable_name | Value |
+—————+——-+
| sync_binlog | 1 |
+—————+——-+
1 row in set (0.00 sec)
mysql>
sync_binlog 值为1，表示每次提交事务后，将binlog_cache中的数据强制写入磁盘。这是最安全但是性能损耗最大的设置，系统Crash的时候最多丢失binlog_cache中未完成的一个事务；
sync_binlog 值为 0 时，表示当事务提交之后，MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘，而让Filesystem自行决定什么时候来做同步，或者cache满了之后才同步到磁盘。默认设置为 0，这时性能是最好的，但风险也是最大的，一旦系统Crash，cache中的所有binlog信息都会丢失；
sync_binlog 值为 n 时，当每进行n次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。
所以sync_binlog=1，导致事务写入太频繁，从而出现 [jbd2/dm-0-8] 这个进程占用 IO 95%。
因此将sync_log设置为一个比较大的数，如 200。
mysql> set global sync_binlog=500;
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like ‘%sync_binlog%’;
+—————+——-+
| Variable_name | Value |
+—————+——-+
| sync_binlog | 500 |
+—————+——-+
1 row in set (0.00 sec)
mysql>
0x04 设置 innodb_flush_log_at_trx_commit 变量.
innodb_flush_log_at_trx_commit 是配置MySql日志何时写入硬盘的参数：
0：log buffer 将每秒一次地写入log file中，并且log file的flush(刷到磁盘)操作同时进行。该模式下在事务提交的时候，不会主动触发写入磁盘的操作。
1：每次事务提交时MySQL都会把log buffer的数据写入log file，并且flush(刷到磁盘)中去，该模式为系统默认。
2：每次事务提交时mysql都会把log buffer的数据写入log file，但是flush(刷到磁盘)操作并不会同时进行。该模式下，MySQL会每秒执行一次 flush(刷到磁盘)操作。
一般设置为2
mysql> show variables like ‘%innodb_flush_log_at_trx_commit%’;
+——————————–+——-+
| Variable_name | Value |
+——————————–+——-+
| innodb_flush_log_at_trx_commit | 1 |
+——————————–+——-+
1 row in set (0.01 sec)
mysql> set global innodb_flush_log_at_trx_commit=2;
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like ‘%innodb_flush_log_at_trx_commit%’;
+——————————–+——-+
| Variable_name | Value |
+——————————–+——-+
| innodb_flush_log_at_trx_commit | 2 |
+——————————–+——-+
1 row in set (0.01 sec)
再次查看 iotop ，[jbd2/dm-2-8]已明显降低。
- Up0
mysql> set global sync_binlog=500;
mysql> set global innodb_flush_log_at_trx_commit=0;
1、参数查看
方法一：mysql> show variables like ‘innodb_flush_log_at_trx_commit’;
方法二：直接查看my.cnf文件innodb_flush_log_at_trx_commit参数值2、参数配置
方法一：mysql> set global innodb_flush_log_at_trx_commit=1; 重启后会丢失使用my.cnf参数
方法二：直接修改my.cnf文件innodb_flush_log_at_trx_commit参数值，但需要重启实例生效#sudo vim /etc/mysql/mysql.conf.d/mysqld.cnf
新增两个参数:
sync_binlog=500
innodb_flush_log_at_trx_commit=0
重启数据库生效 ：# sudo service mysql restart
3、参数值意义
参数值可以是0，1，2
0 ：该模式速度最快，但不太安全，mysqld进程的崩溃会导致上一秒钟所有事务数据的丢失。
1 ：该模式是最安全的，但也是最慢的一种方式。在mysqld 服务崩溃或者服务器主机crash的情况下，binary log 只有可能丢失最多一个语句或者一个事务。
2 ：该模式速度较快，也比0安全，只有在操作系统崩溃或者系统断电的情况下，上一秒钟所有事务数据才可能丢失。
4、外料有文章说innodb_flush_log_at_trx_commit和sync_binlog 两个参数是控制MySQL 磁盘写入策略以及数据安全性的关键参数，当两个参数都设置为1的时候写入性能最差，推荐做法是innodb_flush_log_at_trx_commit=2，sync_binlog=500 或1000
- 哎呀，回复话题必需登录。
