【多线程|munin监控数据分析】munin中的监控图功能 介绍:
1)filesystem usage:显示服务器 的硬盘空间使用情况,这里的数据是硬盘的百分比使用情况.而不是实际显示剩余多少空间
2)inode usage: 此处显示inode的使用百分比,如果inode使用完,将不能在对文件进行创建等操作
什么是inode: inode是索引节点.硬盘在格式化后,一部分是block,一部分是inode,inode存放文件的索引,其中包括文件的一些属性值,比如说:大小 ,用户 组,而block则存放文件数据
3)eth0 error: 根据其字面含义知道其是显示的是网卡的包丢失率
4)ethx traffic : 此图容易理解,就是网卡的流量
5)netstat:这个图是通过netstat -s命令来收集统计数据的,作用是统计一下目前的服务器网络连接状态
6)load average :这个数据是服务器的负载数据,一般来说只要每个CPU的当前活动进程数不大于3那么系统的性能就是良好的，如果每个CPU的任务数大于5，那么就表 示这台机器的性能有严重问题.这个值在运行top命令的时候也会看到.3个数值分别代表1分钟,5分钟,15分钟的负载值.
7) context switches.
我们知道,为了让所有的进程可以轮流使用系统资源,进程调度器在必要的时候挂起正在运行的进程,同时恢复以前挂起的某个进程,这种行为称为进程切换,也就是我们常说的“上下文切换”,这个名称在某种意义上非常形象,“上下文”正是表示进程运行到何种程度。我们知道,进程拥有自己独立的内存空间,但是每个进程都只能共享CPU寄存器。一个进程被挂起的本质就是将它在CPU寄存器中的数据拿出来暂存在内核态堆栈中,而一个进程恢复工作的本质就是将它的数据重新装入CPU寄存器,这段装入和移出的数据我们称为“硬件上下文”,它也是进程上下文的一部分,除此之外,进程上下文中还包含了进程运行时需要的一切状态信息。当硬件上下文频繁的装入和移出时,所消耗的时间是非常可观的。
如果我们希望服务器支持较大的并发数,那么就要尽量减少上下文切换次数,最简单的做法就是减少进程数,尽量使用线程并配合其它I/O模型来设计并发策略。
这里顺便提出一个有趣的话题,说说我们的大脑,当我们在思考很多事情的时候,我认为是并发的,而
不是并行的,也就是任何微观时刻我们不可能同时思考多件事情,而是大脑不断在多件事情之间进行
“上下文切换”,至少我发现我是这样的。
举个例子,假如你用一只手画图,画一个圆形,你也许可以很快的完成,但是假如让你两只手同时画图,左手画圆形,右手画矩形,你一定会觉得很费劲,脑子转不过来,画得很不流畅,这是因为画图是需要通过大脑计算的,什么时候画直线,什么时候拐弯,什么时候画弧线等等,当两只手同时画图时,为了保证两边都能流畅的进行,就得快速进行“上下文切换”,将圆形和矩形的规则不断的在大脑里装入和移出,除非你专门锻炼针对这种同时画图的切换速度,否则我们切换的速度非常慢。
还有时候,当我正在聚精会神的思考着一件事情,突然有人打断了我,我们聊完后,我努力的回忆之前在想什么,这也许就是那件事情被突然移出后没有及时的缓存在大脑的其它位置,以至于无法快速的切换回原来状态。
你也许发现,当我们走路的时候,大脑几乎可以不想着走路,而去思考其它事情,我就喜欢走路的时候思考问题。这有时候取决于道路情况,在平坦空旷的路上行走几乎不需要太多的大脑计算,但不是完全不需要,完全不考虑路况的结果就是撞电线杆,一般用它来歌颂过于专心思考的科学家。
推荐阅读
- 代码狂魔|实战证明java中的两把锁ReentrantLock与synchronized的系统调用
- 进程通信方式
- 解决方案|大文件拆分方案的java实践
- 多线程编程（1）（共享内存与锁）
- Java|多线程编程（二）——面试题，每个线程只打印一种字符，多个线程协同顺序打印n次字符串（求大神的其他实现方案）