KUDU响应时间长，IO调优

最近出现KUDU查询耗时一段时间非常长，差不多在3-5s左右。

1.问题排查

看到机器的以下监控数据，在出问题期间，IO量很大，IO占用CPU时间基本打满，明显是存在磁盘IO问题。

进一步发现内存占用已到90%以上。使用

pidstat -d 1

统计进程的磁盘读写情况，发现kudu-tserver均值可到100多M每秒，明显定位到IO问题出现kudu上。

2.第一阶段解决方案

由于内存占用过高，所以先释放一些机器内存（通过迁移其他进程）。

继续观察数据。

用户请求量趋势：

 IO操作趋势：

 读写速率趋势：

 可以看到不再出现IO很高的情况，但依然IO的量很大，在用户数达到一定量时，IO明显增多。

此时考虑Kudu本身确实存在IO问题，磁盘读写过于频繁，尤其是写操作。

3.kudu核心原理

kudu的数据存储这块原理，核心要素实际上与MySQL这类数据库类似，有两个重要概念：LSM和WAL。

LSM：存储形式是内存+磁盘，写入时先写内存，内存中以LSM组织数据，刷脏页的形式落盘。

WAL：写数据前先写log，log是顺序写所以IO效率高，再写data。

监控数据也看到是写入的IO操作量非常大。kudu的刷脏操作过于频繁，且量很大，接着尝试看能否优化。

4.第二阶段优化

查看kudu进程信息：

kudu 758 1 3 Sep29 ? 00:42:07 /usr/lib/kudu/sbin/kudu-tserver --server_dump_info_path=/var/run/kudu/kudu-tserver-kudu.json --flagfile=/etc/kudu/conf/tserver.gflagfile kudu 1824 1 0 2021 ? 14:56:07 /usr/lib/kudu/sbin/kudu-master --server_dump_info_path=/var/run/kudu/kudu-master-kudu.json --flagfile=/etc/kudu/conf/master.gflagfile

上文确认过IO来自进程kudu-tserver，看下配置/etc/kudu/conf/tserver.gflagfile：

# Do not modify these two lines. If you wish to change these variables,
# modify them in /etc/default/kudu-tserver.
--fromenv=rpc_bind_addresses
--fromenv=log_dir

--fs_wal_dir=/data/var/lib/kudu/tserver
--fs_data_dirs=/data/var/lib/kudu/tserver
--tserver_master_addrs=xxxx:3332
--unlock_unsafe_flags=true
--allow_unsafe_replication_factor=true
--default_num_replicas=1
--webserver_port=8894
--tablet_history_max_age_sec=900

没看到跟内存配置相关的，其他也没看出有带来IO压力很大的配置。

IO瓶颈可以考虑硬件和软件两个方面，因为使用的是云上机器，磁盘是也是通用的，不考虑优化这块，所以从软件出发，看看能否减轻kudu的刷盘压力。

查阅kudu的优化参数：Apache Kudu - Apache Kudu Troubleshooting

	默认值	优化值
–block_cache_capacity_mb	512	512	读缓存。不要超过memory_pressure_percentage，相当于memory_limit_hard_bytes的30%。机器只赋予4G给kudu使用，所以分配1G。
–-memory_limit_hard_bytes	4294967296	2048*1024*1024	硬限制，kudu只能占用这么多内存
–maintenance_manager_num_threads	1	3	维护管理器线程池的大小。对于旋转磁盘，线程数不应超过设备数。（官网建议的维护管理器线程数是数据目录的3倍）
–default_num_replicas	3	1
–log_dir	/tmp
–memory_pressure_percentage	60%		影响刷盘
–memory_limit_soft_percentage	80%		超出这个值后会拒绝写入

添加如下几个参数，重启kudu-tserver。

--block_cache_capacity_mb=512
–-memory_limit_hard_bytes=2147483648
--maintenance_manager_num_threads=3

调整后IO情况，可以看到有很明显的变化：