http://wqtn22.iteye.com/blog/1900803
mnesia在运行时提供了大量的统计量,对这些统计量进行监控,有助于正确使用mnesia,以及对mnesia进行调优,这些统计量包括:
代码版本R15B03
1.启动与运行时参数:
运行相关参数:
mnesia是否在运行中:mnesia:system_info (is_running)
信息输出级别:mnesia:system_info (debug)
是否使用数据存储目录:mnesia:system_info (use_dir)
数据存储目录位置:mnesia:system_info (directory)
初始schema位置:mnesia:system_info (schema_location)
自动修复:mnesia:system_info (auto_repair)
是否激活fallback:mnesia:system_info (fallback_activated)
包含master的表的列表:mnesia:system_info (master_node_tables)
mnesia可等待unclear事务的未决期限,默认为infinity:mnesia:system_info (max_wait_for_decision)
mnesia的coredump文件产生的位置:mnesia:system_info (core_dir)
启动时的并行表加载器的数量:mnesia:system_info (no_table_loaders)
向远程节点发送表数据时的压缩级别:mnesia:system_info (send_compressed)
访问模块相关参数:
事务操作模块:mnesia:system_info (access_module)
备份操作模块:mnesia:system_info (backup_module)
事件模块:mnesia:system_info (event_module)
节点相关参数:
集群所有节点,包括非在线的节点:mnesia:system_info (db_nodes)
本节点可从哪些节点处同步数据:mnesia:system_info (extra_db_nodes)
集群在线节点:mnesia:system_info (running_db_nodes)
日志刷写相关参数:
定时刷写日志间隔,默认3分钟:mnesia:system_info (dump_log_time_threshold)
定量刷写日志间隔,默认1000:mnesia:system_info (dump_log_write_threshold)
是否使用原数据文件进行数据dump,true为使用原数据文件,false为新建一个临时文件:mnesia:system_info (dump_log_update_in_place)
表dump频繁程度,值越大dump表越频繁:mnesia:system_info (dc_dump_limit)
版本相关:
版本:mnesia:system_info (version)
日志版本:mnesia:system_info (log_version)
协议版本:mnesia:system_info (protocol_version)
schema版本:mnesia:system_info (schema_version)
2.表相关:
所有表(包括schema):TableList = mnesia:system_info (tables)
表定义:PropList = mnesia:table_info(Table, all)
PropList包含了表的所有相关信息,每个Prop为{Key, Value}形式,重点包括:
active_replicas:当前活动副本节点,可求其长度
disc_copies:磁盘副本节点,可求其长度
ram_copies:内存副本节点,可求其长度
index:索引
majority:是否使用majority事务
master_nodes:是否有master副本节点
memory:占用内存
type:表类型
storage_type:表在本节点的副本类型
where_to_commit:事务需向哪些副本节点提交,可求其长度
where_to_read:可从哪个副本节点读取数据
where_to_wlock:为{NodeList, Majority},NodeList表明事务需向哪些副本节点申请写锁,可求其长度,Majority表明是否为majority写
where_to_write:事务需向哪些副本节点写,可求其长度
对表定义监控时,可列出表定义所有信息,并对重点信息突出显示或聚合
3.锁相关:
锁被哪个事务持有:mnesia:system_info (held_locks)
排队等待的锁:mnesia:system_info (lock_queue)
一个事务持有的锁:没有直接函数,但可以通过以下方法获取:
TidLock = fun() ->
mnesia_locker ! {get_table, self(), mnesia_tid_locks},
receive {mnesia_tid_locks, Ls} -> Ls after 5000 -> [] end
end,
TidLock().
注意:上述锁信息的获取均需要干扰mnesia_locker进程的执行,其工作原理为向mnesia_locker发送请求消息,mnesia_locker读出相关ets表的所有内容,这些ets表均为private,将这些内容通过消息返回给请求进程,负载大时尽量避免使用
4.事务相关:
活动事务:{info, Participants, Coordinators} = mnesia_tm:get_info(10000)
节点参与的事务:活动事务中,Participants包含的事务,可求其长度
节点协调的事务:活动事务中,Coordinator包含的事务,可求其长度
其中节点协调的事务为本地事务,节点参与的事务为远程事务
注意:上述事务信息的获取均需要干扰mnesia_tm进程的执行,其工作原理为向mnesia_tm发送请求消息,mnesia_tm取出进程本地变量,将这些内容通过消息返回给请求进程,负载大时尽量避免使用
未决事务:这些事务处于提交阶段的中途(而非事务执行中途),可以通过mnesia:system_info()或mnesia:info()的输出得到,但不能直接取得其返回结果,可以通过如下方法获取:
ets:match_object(mnesia_decision, {'_', unclear, '_', '_'}).
注意:
mnesia在获取该项信息时,使用的匹配模式为{'_', unclear, '_'},但经对比mnesia.hrl中对decision的定义,以及mnesia_tm中写入decision的位置,发现应该为{'_', unclear, '_', '_'}
上述事务信息的获取需要扫描整个mnesia_decision表,可能会花费较多时间,负载大时尽量避免使用
事务计数器:
总成功事务数:mnesia:system_info(transaction_commits)
总失败事务数:mnesia:system_info(transaction_failures)
总重启事务数:mnesia:system_info(transaction_restarts)
事务可能因节点down/mnesia down/无法立即获取锁而执行失败,此时mnesia_tm可以将事务进行重启,通常的mnesia:transaction(Fun)会无限重启事务。
成功事务tps:可计算一段时间间隔内的成功事务数,这将成为成功事务tps,该tps为有效tps
失败事务tps:可计算一段时间间隔内的失败事务数,这将成为失败事务tps,该tps为
重启事务tps:可计算一段时间间隔内的重启事务数,这将成为重启事务tps,当事务申请锁失败时,将进行重启执行,观察该tps的频繁程度也可以得到当前
5.事件订阅相关:
mnesia事件订阅者进程:mnesia:system_info(subscribers)
订阅系统事件:mnesia:subscribe(system)
出现系统事件后,mnesia将向订阅进程发出消息
需要关注的系统事件:
过载事件:{mnesia_overload, Detail},其中Detail为产生过载的上下文,上下文见下段所述
数据库不一致事件:{inconsistent_database, Context, Node},其中Context为产生不一致的上下文,上下文见
6.过载事件相关:
进行过载检查的上下文及条件:
{mnesia_tm, message_queue_len, [Prev, Len]}:
mnesia_recover每隔10s检查mnesia_tm的消息队列长度,若10s的首尾均发现消息队列长度超过100,则报告该过载事件
schema_prepare:
schema操作为同步下刷日志,下刷日志上下文为schema_prepare
time_threshold:
每隔dump_log_time_threshold个ms,将异步下刷日志,下刷日志上下文为time_threshold
write_threshold:
每产生dump_log_write_threshold个写操作,将异步下刷日志,下刷日志上下文为write_threshold
user:
用户可以通过mnesia:dump_log()进行同步下述日志,下刷日志上下文为user
对于同步/异步下刷日志,若连续两次遭遇相同上下文的下刷日志,mnesia_controller将报告该上下文的过载事件。
当有大量的日志写请求产生,而日志不能及时下刷时,通常会有write_threshold上下文的过载事件,此时通常为并发事务提交太快,而日志下刷过慢或过于频繁导致,可以适当调高dump_log_write_threshold参数
7.数据库不一致事件相关:
数据库不一致事件的上下文:
bad_decision:启动时从对端同步数据,发现事务决议不一致
starting_partitioned_network:启动时从对端同步数据,发现对端节点曾经down过
running_partitioned_network:运行时对端节点up或启动完成同步数据后,发现对端节点曾经down过
不一致事件通常发生在脑裂时,但当前有majority保护,可以仅仅监控该事件
8.日志相关:
日志计数器:
已记入日志的写操作数:mnesia:system_info(transaction_log_writes)
该值为启动以来,已记入日志的写操作数,包括dirty写
计算日志写操作qps:可计算一段时间间隔内的日志写操作数,这将成为日志写操作数qps
日志进程信息:
{info, State} = mnesia_controller:get_info(10000)
State包含的内容包括:
{
supervisor,
schema_is_merged,
early_msgs,
loader_pid,%进行远程/本地加载的进程列表,可求长度,可监控
loader_queue,%进行远程/本地加载的任务列表,可求长度,可监控
sender_pid,%向远程节点发送数据的进程列表,可求长度,可监控
sender_queue,%向远程节点发送数据的任务列表,可求长度,可监控
late_loader_queue,
dumper_pid,%进行本地日志下刷的进程,可为undefined,可监控
dumper_queue,%进行本地日志下刷的任务列表,可求长度,可重点监控
others,
dump_log_timer_ref,
is_stopping
}
具体结构需参照mnesia_controller.erl的定义,不同版本可能变动,可监控项目如上注释
注意:上述日志下刷进程信息的获取均需要干扰mnesia_controller进程的执行,其工作原理为向mnesia_controller发送请求消息,mnesia_tm取出本地状态,将这些内容通过消息返回给请求进程,负载大时尽量避免使用
日志进程工作队列信息:
{workers, Loaders, Senders, Dumper } = mnesia_controller:get_workers(10000)
Loaders为从远程/本地加载数据的worker进程的列表
Senders为向远程节点发送数据的worker进程的列表
Dumper为进行本地日志下刷的worker进程,也可以为undefined
其包含的信息较少,要获得全面的信息,可通过日志进程信息获取
注意:上述日志下刷进程信息的获取均需要干扰mnesia_controller进程的执行,其工作原理为向mnesia_controller发送请求消息,mnesia_tm取出本地状态,将这些内容通过消息返回给请求进程,负载大时尽量避免使用
9.检查点相关:
当前活动检查点:mnesia:system_info(checkpoints)
活动检查点是指通过mnesia_checkpoint:activate激活且未被mnesia_checkpoint:deactivate失活的检查点
10.其它:
待补充