日归档：2015 年 4 月 6 日

Exadata上CPU相关的设置（感觉已经很好了，除了irqbalance）

发表于 2015 年 4 月 6 日 由 Lunar

有些情况下，Exadata上我们发现有IO降级的情况，但是检查磁盘和flashcard都没有损坏。 这时候，可能需要检查一下APIC timer功能是否正常（APIC timer没有正确开启可能导致iostat报告的吞吐量有降级的现象） 当发生这类问题时，可以对比vmstat的bi/bo（读和写的平均吞吐量），因为vmstat命令不受APIC timer的影响。 . APIC Timer(Advanced Programmable Interrupt Controller)是一种时钟中断设备，即 高级可编程中断控制器 CPU通过彼此发送中断来完成它们之间的通信，APIC 就是通过编程触发lapic设备周期产生中断，然后注入到vcpu。 2000年以后的CPU都支持，这是Intel多处理规范的核心。 APIC Timer的模式APIC定时器包含3种定时器模式: 周期触发periodic 一次性触发one-shot TSC-Deadline模式(最新的CPU里面支持)。 . 老版本的Exadata可以检查 dmesg|grep “Using local APIC timer interrupts”，来确认APIC timer是否正确开启。 新版本的Exadata可以检查 dmesg|grep “Using IOAPIC for interrupt routing”，来确认APIC timer是否正确开启。 . 例如，下面显示在这个1/4配置的Exadata … 继续阅读 →

发表在 体系架构 | 标签为 , , , | 留下评论

一次数据库性能问题处理（11g自动维护任务，log file sync）

发表于 2015 年 4 月 6 日 由 Lunar

看到问题发生前30分钟的awr显示，系统负载超高： 查询数据库当前等待事件： 跟awr中的信息一致： 直觉是resmgr:cpu quantum引起了其他一系列问题，这个已经不是第一次遇到了。 等待事件 resmgr:cpu quantum 是11.2引入的oracle资源管理引起的，这个东西一般问题很多，大部分时候，我们装机时，都是直接禁用的。 11.2的oracle资源管理中有一项最坑的是周末的维护任务，这个遇到好几次了。 禁用方法： 1，关闭一些不需要的维护任务： 关闭数据库的空间Advisor，避免消耗过多的IO： 关闭数据库的SQL自动调整Advisor： 关闭数据库的weekday窗口的DEFAULT_MAINTENANCE_PLAN： 查看当前active的resource plan ，确认已经关闭： 此时awr可以看到系统负载已经下降一点点，但是依然很高： 上述修改后的数据库等待事件已经变味“log file sync”，具体如下： 相应的前台等待事件： 后台等待时间： 在LGWR的trace中，可能会出现类似如下的信息： 这是11.2的新特性，Adaptive Switching Between Log Write Methods（LGWR写模式自动切换），该功能bug一堆，经常导致commit缓慢而带来的“log file sync”。 通过设置如下隐含参数，禁用11.2这个LGWR写模式切换功能： 修改后，数据库等待事件已经变为正常的应用日常的等待事件了： 此时的AWR看到，系统负载已经降下来了： 该应用正常时间，数据库连接数如下： 故障暂时缓解了，应用反映已经正常，但是可以看到，上面的信息告诉我们，对于这个应用来说，需要调整的地方还很多： 1，系统参数全面检查 2，SQL优化（SQL语句的写法，index，统计信息检查等） … 继续阅读 →

发表在 Database | 标签为 , , | Comments Off on 一次数据库性能问题处理（11g自动维护任务，log file sync）