Oracle统计内存实际占用的问题 0x1 背景 在服务器上，一般我们要查询进程占用了多少内存，使用 top 查看其 res 即可，对于大多数的服务都比较适用，但是 Oracle 却不能使用这个办法。 0x2 原因 如何统计oracle使用的内存一直是一个复杂的问题，通过操作系统top命令观察oracle进程，在低版本或者低负载的情况我们可能觉得没问题，使用率不高，但如果在高负载的情况我们就会看到一个奇怪的事情，那就是不管是 RES 相加还是 %MEM 相加，数值远超过系统内存或者 100%，所以结论是直接通过 top 命令计算 Oracle 内存使用时行不通的。 0x3 为什么 因为Oracle有一个SGA的概念，改内存在Oracle所有进程之间共享数据，如果某些Oracle进程使用到了SGA中的一些数据，那么内存就会重复统计 Oracle关于不能正确获取内存使用的解释 # https://docs.oracle.com/en-us/iaas/os-management/doc/known-issues.html Display of Memory Utilization data for DB Instance resource types is not supported in this release. Memory Utilization(%) metric is not supported for Oracle Database Instance. Oracle Database processes have shared memory, and using a non-root user, it is not possible to accurately calculate memory across all processes without overcounting. This will be addressed in future releases with support for full monitoring of the Oracle Database. 0x4 how 那么该怎么统计Oracle实际使用的内存呢？ 可以通过统计 SGA 和 PGA 使用的大小来确定

根据操作系统进程查询Oracle会话 0x1 场景 很多时候我们可以看到 top 中有些 Oracle进程持续占用很高的 CPU 或者内存，但是无奈会话太多，不能确定是哪个导致，那么应该如何定位呢？ 0x2 查询sql 直接执行此SQL，根据提示输入系统进程号即可 Enter the os pid and find the sql id select sid, sql_id from v$session s, v$process p where s.paddr = p.addr and p.spid = &OS_PID; 根据上面的SQL返回内容，替换下面的 sql_id Enter the sql_id to find the sql_text set long 1000 set pages 1000 lines 1000 col sql_text for a100 select sql_text from v$sql where sql_id = '&sql_id'; 0x3 其他 仍然会存在不准确的现象，因为有些事务很大，包含很多SQL，可能当前查询出来的sql是整个事务中性能影响较小的，已经错过了最佳的执行时间。

hbuilder调试 0x0 调试方法 有时候app运行出现异常，但是无法判断是哪里问题，可以通过调试来进行排查。在hbuilder中选择运行、运行到手机或模拟器、选择android，然后接入安卓手机即可。手机上选择授权 如果做了这些还是无法模拟调试，则进入开发者模式中勾选USB安装，因为hbuilder调试会自动在手机上安装应用

gitlab日志分析工具fast-stats 0x1 问题 gitlab日志目录下 /var/log/gitlab 内容还是比较多的，在出现一些性能问题、故障去分析日志很麻烦，内容量大、多 这时我们可以借助 fast-stats 工具，来快速的分析 gitlab 日志，以下大概几个用法： ./fast-stats top /var/log/gitlab/sidekiq/current ./fast-stats top /var/log/gitlab/gitlab-rails/production_json.log ./fast-stats top /var/log/gitlab/gitlab-shell/gitlab-shell.log 0x0 参考文档 https://forum.gitlab.com/t/git-bundle-high-cpu-usage/81443/1 下载地址: https://gitlab.com/gitlab-com/support/toolbox/fast-stats

gitlab高负载高cpu使用率 0x1 问题 gitlab某个时刻非常卡，网页打开都很慢。登录后可以看到负载较高、cpu使用率较高，可以确定是cpu使用过高引起的。 继续 在 top 中排序 发现 bundle 进程使用率非常高，根据进程号查询明细，可以看到是 sidekiq 进程 0x2 分析解决 sidekiq在gitlab服务中是作为任务调度使用的，相关的内容在管理员后台 -> 监控 -> 后台任务 中。所以调整的思路是控制任务的并发以及减小任务量 办法一：减少并发 # gitlab的优化 # Reduce the number of running workers to the minimum in order to reduce memory usage puma['worker_processes'] = 2 sidekiq['max_concurrency'] = 9 # Turn off monitoring to reduce idle cpu and disk usage prometheus_monitoring['enable'] = false 通过修改 gitlab.rb 配置文件，减少最大并发数以及关闭性能监控等节省性能 方法二：关闭无效任务 本来在原图中，是可以看到有相当多的已停滞任务，查看明细会继续调度时间重试，这些任务基本上都是 email_on_push ，详情就是推送合并触发邮件，并且目的邮箱已经不存在了，所以是可以取消的，那么 email_on_push　是在哪里开启呢，通过查看gitlab页面后，发现在： 设置->集成 存在 '推送时发送电子邮件' '流水线状态电子邮件' # 进入设置关闭即可 不过这里出现了个最大的问题，此功能看起来是在某个中央仓库中早就启用，很多仓库都是从这个仓库fork过去的，所以非常多的仓库都存在这个设置，如今只能慢慢手动关闭了，发现一个处理一个。这样的话我们继续观察后台停滞任务，基本上不会再有新增和重试了