-
Notifications
You must be signed in to change notification settings - Fork 0
统计与监控
采样时刻 ======有专门的采样程序连接 dispatcher 取得当前时间点的累积统计数据， 通过 pid+startTime 判断统计数据是否来自同一个 dispatcher 生命周期。
每个 oSlot/client/total 的 对每个 oSlot 进行统计有没有意义呢？ 因为每个 oSlot 都可以用于任何请求， 因此认为 oSlot 上面的统计信息没有意义。 对每个 client 进行统计有没有意义呢？有意义。 对每个 client cSlot 进行统计和对 oSlot 统一一样，也没有意义。
- 请求量
- 请求和响应产生的数据流量，仅仅是通过 dispatcher 的
- 请求处理总计时间(从收到请求第一个frame到收到响应结束frame)
- 请求在db侧的总计时间
- 在dispatcher等待oSlot的时间
- get/post 请求数量
- 只读请求/写请求的分别数量 上述内容可能需要在 handlerHTTP 中统计 间接通过 dispatcher 获得 比较复杂
- db 侧的结束包增加包体，包含统计信息
- db time
- cpu time
- idle time
- responde time 然后 dispatcher 将上述信息进行汇总
- in db pipe wait
- in db call out response wait
- repeated call-out wait
特别的
- 执行时间超过时限(通常是3s)的请求的数量
当前的 queue length， 等待 cSlot，开始等待时间，等待时长， 获取所有非空闲的 cSlot，看看他们的时间， 包括占用cSlot的时间，发送请求结束frame的时间，等待响应的时间。 用于发现一些长期没有响应回复的情况。 可能发现的问题：
- 占用 cSlot 后，长期没有向dispatcher发送请求结束，导致 cSlot 被长期占用
- 占用 cSlot 后，也发送了请求给 dispatcher，但是长期没有响应
- 如果是 OSP 异常退出，导致永远不能响应，那么应该由 dispatcher 识别发现并通知 client 释放资源
- 如果仅仅是 servlet 执行时间长，那么可以等
- 占用 cSlot 后，也有了响应，但是响应结束总不到达 处理规则同上(第2条)
要看 OSP 进程被 kill 是否会发送 socket end/fin 包， 或者 kill session 是否会发送 socket end/fin 包。
active socket 上如果 OSP 服务端异常， 那么
每个 oSlot 当前处于 free 还是 busy，busy 的话， 正在执行什么？ 这个完全可以在 oracle 侧通过设置 v$session 中的 module/action 来实现， 这样可以方便的通过 v$session 查看状态。 这样就不必在 dispatcher 中拆包查看当前目的程序。
可以考虑对每个来自客户端的head frame现在dispatcher中保存， 这样如果有监控需求的话， 就可以轻易的将入参全部显示出来。 但是这样会增加 dispatcher的内存开销。 特别是对于大表单提交大量数据的情况。
比如如果头部有 1000 字节，共有 100 个并发，就要占用 100K 空间， 其实也不是特别大。 另外大表单的占比也不会特别大。
这样对于实时状态监控就有的放矢了。 但是当oSlot比较多的时候， 监控程序一揽子
这样 dispatcher cache 可以判断是否直接返回 cache 中的信息。包括：
- 资源 ID
- vary 每个资源ID和vary组合构成一个唯一的可缓存资源
包括 db-time cpu-time wait-time idle-time 等等信息
系统必须能够识别出是否调用的是 repeated NDBC call。 同时，servlet 中进行同步call-out等待外部回复的时间应该从计量中排除， 不作为 db 压力的一部分。
- 一方面利用 hprof
- 一方面利用 snapshot
- 利用 v$session_long_ops