QEMU CORE分析之死锁

main线程8003

QEMU出CORE,死在pthread_mutex_lock里:

查看一下,是在等待qemu_global_mutex锁:

通过__owner看出,qemu_global_mutex 已经被人加锁了,线程ID为8417。 继续阅读

利用日志做监控

利用日志做监控,适用于不便修改源码或不便破坏现有环境时,可以通过日志内容采取不同动作,通过对日志本身的实时监控并分析,提取有效信息并采取对应行动。

应用场景可随意想象:例如,之前发现aSV的ssh密码被暴力破解,我们可以通过日志监控暴力破解行为,然后做出阻止。

这并不是一个新技术,也不困难,fail2ban http://www.fail2ban.org/ 做的挺不错,使用起来效果如图: 继续阅读

大页内存在虚拟化中的应用

原理

虚拟内存

简单说,没有虚拟内存的概念,那么COPY ON WRITE,SWAP等技术都不是必要的,但是系统的弹性和容量会大打折扣。
对比物理内存,我们可以认为虚拟内存比物理内存多许多,这个优点依赖于一个重要实现手段叫做page fault,我们将进程“分配内存”和“访问内存”概念分开,分配了内存不访问,是可以不占物理内存的(未初始化未置零等),分配了内存访问,也不一定占用更多的物理内存(COPY ON WRITE)。假设某一虚拟内存已经分配给进程A,当进程A去访问所在内存页时,可能出现:
1. 内存页已经存在于CPU Cache或物理内存,并且进程A有访问权限。这是正常情况。
2. 内存页已经存在于CPU Cache或物理内存,但是进程A还没有访问权限或者第一次访问前并没有实际载入,例如,进程A要访问libc.so的代码段,这段虚拟内存其实已经被其他进程加载到物理内存了,但是还没有赋给进程A访问权限,此时发生page fault,我们称之为minor page fault.
3. 内存页不存在于CPU Cache和物理内存。可能原因是内存已经被交换到交换分区,此时我们需要通过IO将内存页读入物理内存再给进程A访问,此过程我们称之为major page fault.

想要证明min_flt和maj_flt的发生,我们可以使用 /usr/bin/time -v CMD 来执行命令,例如,我们运行一个记事本,第一次运行的时候,会从磁盘载入共享库,所以会有Major (requiring I/O) page faults,第二次,我们先运行一个记事本程序,再使用/usr/bin/time –v运行记事本,由于使用到的共享库已经加载到内存了,我们会看到Major (requiring I/O) page faults会减少甚至为0。
继续阅读