Yet Another SA's Blog

• Blog
• Special Topic
• 订阅
• Archives
• 听听音乐
• 首页

Linux System and Performance Monitoring(总结篇) (阅读全文)

非原创.转自:http://www.ourlinux.net/operating-system/linux-system-and-performance-monitoring-end/

附录 A: 案例学习 - 性能监控之循序渐进
某一天,一个客户打电话来需要技术帮助,并抱怨平常15秒就可以打开的网页现在需要20分钟才可以打开.

具体系统配置如下:

RedHat Enterprise Linux 3 update 7
Dell 1850 Dual Core Xenon Processors, 2 GB RAM, 75GB 15K Drives
Custom LAMP software stack(译注:Llinux+apache+mysql+php 环境)

性能分析之步骤

1. 首先使用vmstat 查看大致的系统性能情况:

# vmstat 1 10
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy id wa
1 0 249844 19144 18532 1221212 0 0 7 3 22 17 25 8 17 18
0 1 249844 17828 18528 1222696 0 0 40448 8 1384 1138 13 7 65 14
0 1 249844 18004 18528 1222756 0 0 13568 4 623 534 3 4 56 37
2 0 249844 17840 18528 1223200 0 0 35200 0 1285 1017 17 7 56 20
1 0 249844 22488 18528 1218608 0 0 38656 0 1294 1034 17 7 58 18
0 1 249844 21228 18544 1219908 0 0 13696 484 609 559 5 3 54 38
0 1 249844 17752 18544 1223376 0 0 36224 4 1469 1035 10 6 67 17
1 1 249844 17856 18544 1208520 0 0 28724 0 950 941 33 12 49 7
1 0 249844 17748 18544 1222468 0 0 40968 8 1266 1164 17 9 59 16
1 0 249844 17912 18544 1222572 0 0 41344 12 1237 1080 13 8 65 13

分析:
1,不会是内存不足导致,因为swapping 始终没变化(si 和 so).尽管空闲内存不多(free),但swpd 也没有变化.
2,CPU 方面也没有太大问题,尽管有一些运行队列(procs r),但处理器还始终有50% 多的idle(CPU id).
3,有太多的上下文切换(cs)以及disk block从RAM中被读入(bo).
4,CPU 还有平均20% 的I/O 等待情况.

结论:
从以上总结出,这是一个I/O 瓶颈.

2. 然后使用iostat 检查是谁在发出IO 请求:

# iostat -x 1
Linux 2.4.21-40.ELsmp (mail.example.com) 03/26/2007

avg-cpu: %user %nice %sys %idle
30.00 0.00 9.33 60.67

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/sda 7929.01 30.34 1180.91 14.23 7929.01 357.84 3964.50 178.92 6.93 0.39 0.03 0.06 6.69
/dev/sda1 2.67 5.46 0.40 1.76 24.62 57.77 12.31 28.88 38.11 0.06 2.78 1.77 0.38
/dev/sda2 0.00 0.30 0.07 0.02 0.57 2.57 0.29 1.28 32.86 0.00 3.81 2.64 0.03
/dev/sda3 7929.01 24.58 1180.44 12.45 7929.01 297.50 3964.50 148.75 6.90 0.32 0.03 0.06 6.68

avg-cpu: %user %nice %sys %idle
9.50 0.00 10.68 79.82

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/sda 0.00 0.00 1195.24 0.00 0.00 0.00 0.00 0.00 0.00 43.69 3.60 0.99 117.86
/dev/sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
/dev/sda2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
/dev/sda3 0.00 0.00 1195.24 0.00 0.00 0.00 0.00 0.00 0.00 43.69 3.60 0.99 117.86

avg-cpu: %user %nice %sys %idle
9.23 0.00 10.55 79.22

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/sda 0.00 0.00 1200.37 0.00 0.00 0.00 0.00 0.00 0.00 41.65 2.12 0.99 112.51
/dev/sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
/dev/sda2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
/dev/sda3 0.00 0.00 1200.37 0.00 0.00 0.00 0.00 0.00 0.00 41.65 2.12 0.99 112.51

分析:
1,看上去只有/dev/sda3 分区很活跃,其他分区都很空闲.
2,差不多有1200 读IOPS,磁盘本身是支持200 IOPS左右(译注:参考之前的IOPS 计算公式).
3,有超过2秒,实际上没有一个读磁盘(rkb/s).这和在vmstat 看到有大量I/O wait是有关系的.
4,大量的read IOPS(r/s)和在vmstat 中大量的上下文是匹配的.这说明很多读操作都是失败的.

结论:
从以上总结出,部分应用程序带来的读请求,已经超出了I/O 子系统可处理的范围.

3. 使用top 来查找系统最活跃的应用程序

# top -d 1
11:46:11 up 3 days, 19:13, 1 user, load average: 1.72, 1.87, 1.80
176 processes: 174 sleeping, 2 running, 0 zombie, 0 stopped
CPU states: cpu user nice system irq softirq iowait idle
total 12.8% 0.0% 4.6% 0.2% 0.2% 18.7% 63.2%
cpu00 23.3% 0.0% 7.7% 0.0% 0.0% 36.8% 32.0%
cpu01 28.4% 0.0% 10.7% 0.0% 0.0% 38.2% 22.5%
cpu02 0.0% 0.0% 0.0% 0.9% 0.9% 0.0% 98.0%
cpu03 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 100.0%
Mem: 2055244k av, 2032692k used, 22552k free, 0k shrd, 18256k buff
1216212k actv, 513216k in_d, 25520k in_c
Swap: 4192956k av, 249844k used, 3943112k free 1218304k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14939 mysql 25 0 379M 224M 1117 R 38.2 25.7% 15:17.78 mysqld
4023 root 15 0 2120 972 784 R 2.0 0.3 0:00.06 top
1 root 15 0 2008 688 592 S 0.0 0.2 0:01.30 init
2 root 34 19 0 0 0 S 0.0 0.0 0:22.59 ksoftirqd/0
3 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
4 root 10 -5 0 0 0 S 0.0 0.0 0:00.05 events/0

分析:
1,占用资源最多的好像就是mysql 进程,其他都处于完全idle 状态.
2,在top(wa) 看到的数值,和在vmstat 看到的wio 数值是有关联的.

结论:
从以上总结出,似乎就只有mysql 进程在请求资源,因此可以推论它就是导致问题的关键.

4. 现在已经确定是mysql 在发出读请求,使用strace 来检查它在读请求什么.

# strace -p 14939

Process 14939 attached - interrupt to quit
read(29, “\3\1\237\1\366\337\1\222%\4\2\0\0\0\0\0012P/d”, 20) = 20
read(29, “ata1/strongmail/log/strongmail-d”…, 399) = 399
_llseek(29, 2877621036, [2877621036], SEEK_SET) = 0
read(29, “\1\1\241\366\337\1\223%\4\2\0\0\0\0\0012P/da”, 20) = 20
read(29, “ta1/strongmail/log/strongmail-de”…, 400) = 400
_llseek(29, 2877621456, [2877621456], SEEK_SET) = 0
read(29, “\1\1\235\366\337\1\224%\4\2\0\0\0\0\0012P/da”, 20) = 20
read(29, “ta1/strongmail/log/strongmail-de”…, 396) = 396
_llseek(29, 2877621872, [2877621872], SEEK_SET) = 0
read(29, “\1\1\245\366\337\1\225%\4\2\0\0\0\0\0012P/da”, 20) = 20
read(29, “ta1/strongmail/log/strongmail-de”…, 404) = 404
_llseek(29, 2877622296, [2877622296], SEEK_SET) = 0
read(29, “\3\1\236\2\366\337\1\226%\4\2\0\0\0\0\0012P/d”, 20) = 20

分析:
1,大量的读操作都在不断寻道中,说明mysql 进程产生的是随机IO.
2,看上去似乎是,某一sql 查询导致读操作.

结论:
从以上总结出,所有的读IOPS 都是mysql 进程在执行某些读查询时产生的.

5. 使用mysqladmin 命令,来查找是哪个慢查询导致的.

# ./mysqladmin -pstrongmail processlist

+—-+——+———–+————+———+——+———-+—————————————-
| Id | User | Host | db | Command | Time | State | Info
+—-+——+———–+————+———+——+———-+—————————————-
| 1 | root | localhost | strongmail | Sleep | 10 | |
| 2 | root | localhost | strongmail | Sleep | 8 | |
| 3 | root | localhost | root | Query | 94 | Updating | update `failures` set
`update_datasource`=’Y’ where database_id=’32′ and update_datasource=’N’ and |
| 14 | root | localhost | | Query | 0 | | show processlist

分析:
1,MySQL 数据库里,似乎在不断的运行table update查询.
2,基于这个update 查询,数据库是对所有的table 进行索引.

结论:
从以上总结出,MySQL里这些update 查询问题,都是在尝试对所有table 进行索引.这些产生的读请求正是导致系统性能下降的原因.

后续

把以上这些性能信息移交给了相关开发人员,用于分析他们的PHP 代码.一个开发人员对代码进行了临时性优化.某个查询如果出错了,也最多到100K记录.数据库本身考虑最多存在4百万记录.最后,这个查询不会再给数据库带来负担了.

References
• Ezlot, Phillip – Optimizing Linux Performance, Prentice Hall, Princeton NJ 2005 ISBN – 0131486829
• Johnson, Sandra K., Huizenga, Gerrit – Performance Tuning for Linux Servers, IBM Press, Upper Saddle River NJ 2005 ISBN 013144753X
• Bovet, Daniel Cesati, Marco – Understanding the Linux Kernel, O’Reilly Media, Sebastoppl CA 2006, ISBN 0596005652
• Blum, Richard – Network Performance Open Source Toolkit, Wiley, Indianapolis IN 2003, ISBN 0-471-43301-2
• Understanding Virtual Memory in RedHat 4, Neil Horman, 12/05 http://people.redhat.com/nhorman/papers/rhel4_vm.pdf
• IBM, Inside the Linux Scheduler, http://www.ibm.com/developerworks/linux/library/l-scheduler/
• Aas, Josh, Understanding the Linux 2.6.8.1 CPU Scheduler, http://josh.trancesoftware.com/linux/linux_cpu_scheduler.pdf
• Wieers, Dag, Dstat: Versatile Resource Statistics Tool, http://dag.wieers.com/home-made/dstat/

Tags: monitor
Posted in 技术相关 | No Comments »

Linux System and Performance Monitoring(Network篇) (阅读全文)

此文非原创.转载自:http://www.ourlinux.net/page/operating-system/linux-system-and-performance-monitoring-network/

6.0 I/O 监控介绍
8.0 Network 监控介绍

在所有的子系统监控中,网络是最困难的.这主要是由于网络概念很抽象.当监控系统上的网络性能,这有太多因素.这些因素包括了延迟,冲突,拥挤和数据包丢失.

这个章节讨论怎么样检查Ethernet(译注:网卡),IP,TCP的性能.

8.1 Ethernet Configuration Settings(译注:网卡配置的设置)

除非很明确的指定,几乎所有的网卡都是自适应网络速度.当一个网络中有很多不同的网络设备时,会各自采用不同的速率和工作模式.

多数商业网络都运行在100 或 1000BaseTX.使用ethtool 可以确定这个系统是处于那种速率.

以下的例子中,是一个有100BaseTX 网卡的系统,自动协商适应至10BaseTX 的情况.

# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 10Mb/s
Duplex: Half
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0×00000007 (7)
Link detected: yes

以下示范例子中,如何强制网卡速率调整至100BaseTX:

# ethtool -s eth0 speed 100 duplex full autoneg off

# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: No
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: off
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0×00000007 (7)
Link detected: yes

8.2 Monitoring Network Throughput(译注:网络吞吐量监控)

接口之间的同步并不意味着仅仅有带宽问题.重要的是,如何管理并优化,这2台主机之间的交换机,网线,或者路由器.测试网络吞吐量最好的方式就是,在这2个系统之间互相发送数据传输并统计下来,比如延迟和速度.

8.2.0 使用iptraf 查看本地吞吐量

iptraf 工具(http://iptraf.seul.org),提供了每个网卡吞吐量的

Tags: monitor, network
Posted in 技术相关 | No Comments »

Linux System and Performance Monitoring(I/O篇) (阅读全文)

此文非原创.转载自:http://www.ourlinux.net/life/linux-system-and-performance-monitoring-io/  

6.0 I/O 监控介绍

磁盘I/O 子系统是Linux 系统中最慢的部分.这个主要是归于CPU到物理操作磁盘之间距离(译注:盘片旋转以及寻道).如果拿读取磁盘和内存的时间作比较就是分钟级到秒级,这就像7天和7分钟的区别.因此本质上,Linux 内核就是要最低程度的降低I/O 数.本章将诉述内核在磁盘和内存之间处理数据的这个过程中,哪些地方会产生I/O.
6.1 读和写数据 - 内存页

Linux 内核将硬盘I/O 进行分页,多数Linux 系统的默认页大小为4K.读和写磁盘块进出到内存都为4K 页大小.你可以使用time 这个命令加-v 参数,来检查你系统中设置的页大小:

# /usr/bin/time -v date
<snip>
Page size (bytes): 4096
<snip>

6.2 Major and Minor Page Faults(译注:主要页错误和次要页错误)

Linux,类似多数的UNIX 系统,使用一个虚拟内存层来映射硬件地址空间.当一个进程被启动,内核先扫描CPU caches和物理内存.如果进程需要的数据在这2个地方都没找到,就需要从磁盘上读取,此时内核过程就是major page fault(MPF).MPF 要求磁盘子系统检索页并缓存进RAM.

一旦内存页被映射进内存的buffer cache(buff)中,内核将尝试从内存中读取或写入,此时内核过程就是minor page fault(MnPF).与在磁盘上操作相比,MnPF 通过反复使用内存中的内存页就大大的缩短了内核时间.

以下的例子,使用time 命令验证了,当进程启动后,MPF 和 MnPF 的变化情况.第一次运行进程,MPF 会更多:

# /usr/bin/time -v evolution
<snip>
Major (requiring I/O) page faults: 163
Minor (reclaiming a frame) page faults: 5918
<snip>

第二次再运行时,内核已经不需要进行MPF了,因为进程所需的数据已经在内存中:

# /usr/bin/time -v evolution
<snip>
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 5581
<snip>

6.3 The File Buffer Cache(译注:文件缓存区)

文件缓存区就是指,内核将MPF 过程最小化,MnPF 过程最大化.随着系统不断的产生I/O,buffer cache也将不断的增加.直到内存不够,以及系统需要释放老的内存页去给其他用户进程使用时,系统就会丢弃这些内存页.结果是,很多sa(译注:系统管理员)对系统中过少的free memory(译注:空闲内存)表示担心,实际上这是系统更高效的在使用caches.

以下例子,是查看/proc/meminfo 文件:

# cat /proc/meminfo
MemTotal: 2075672 kB
MemFree: 52528 kB
Buffers: 24596 kB
Cached: 1766844 kB
<snip>

可以看出,这个系统总计有2GB (Memtotal)的可用内存.当前的空闲内存为52MB (MemFree),有24 MB内存被分配磁盘写操作(Buffers),还有1.7 GB页用于读磁盘(Cached).

内核这样是通过MnPF机制,而不代表所有的页都是来自磁盘.通过以上部分,我们不可能确认系统是否处于瓶颈中.

6.4 Type of Memory Pages

在Linux 内核中,memory pages有3种,分别是:

1,Read Pages - 这些页通过MPF 从磁盘中读入,而且是只读.这些页存在于Buffer Cache中以及包括不能够修改的静态文件,二进制文件,还有库文件.当内核需要它们时,将读取到内存中.如果内存不足,内核将释放它们回空闲列表中.程序再次请求时,则通过MPF 再次读回内存.

2,Dirty Pages - 这些页是内核在内存中已经被修改过的数据页.当这些页需要同步回磁盘上,由pdflush 负责写回磁盘.如果内存不足,kswapd (与pdflush 一起)将这些页写回到磁盘上并释放更多的内存.

3,Anonymous Pages - 这些页属于某个进程,但是没有任何磁盘文件和它们有关.他们不能和同步回磁盘.如果内存不足,kswapd 将他们写入swap 分区上并释放更多的内存(”swapping” pages).

6.5 Writing Data Pages Back to Disk

应用程序有很多选择可以写脏页回磁盘上,可通过I/O 调度器使用 fsync() 或 sync() 这样的系统函数来实现立即写回.如果应用程序没有调用以上函数,pdflush 进程会定期与磁盘进行同步.

# ps -ef | grep pdflush
root 186 6 0 18:04 ? 00:00:00 [pdflush]

7.0 监控 I/O

当觉得系统中出现了I/O 瓶颈时,可以使用标准的监控软件来查找原因.这些工具包括了top,vmstat,iostat,sar.它们的输出结果一小部分是很相似,不过每个也都提供了各自对于性能不同方面的解释.以下章节就将讨论哪些情况会导致I/O 瓶颈的出现.

7.1 Calculating IO’s Per Second(译注:IOPS 的计算)

每个I/O 请求到磁盘都需要若干时间.主要是因为磁盘的盘边必须旋转,机头必须寻道.磁盘的旋转常常被称为”rotational delay”(RD),机头的移动称为”disk seek”(DS).一个I/O 请求所需的时间计算就是DS加上RD.磁盘的RD 基于设备自身RPM 单位值(译注:RPM 是Revolutions Perminute的缩写,是转/每分钟,代表了硬盘的转速).一个RD 就是一个盘片旋转的

半圆.如何计算一个10K RPM设备的RD 值呢:

1, 10000 RPM / 60 seconds (10000/60 = 166 RPS)
2, 转换为 166分之1 的值(1/166 = 0.006 seconds/Rotation)
3, 单位转换为毫秒(6 MS/Rotation)
4, 旋转半圆的时间(6/2 = 3MS) 也就是 RD
5, 加上平均3 MS 的寻道时间 (3MS + 3MS = 6MS)
6, 加上2MS 的延迟(6MS + 2MS = 8MS)
7, 1000 MS / 8 MS (1000/8 = 125 IOPS)

每次应用程序产生一个I/O,在10K RPM磁盘上都要花费平均 8MS.在这个固定时间里,磁盘将尽可能且有效率在进行读写磁盘.IOPS 可以计算出大致的I/O 请求数,10K RPM 磁盘有能力提供120-150 次IOPS.评估IOPS 的效能,可用每秒读写I/O 字节数除以每秒读写IOPS 数得出.

7.2 Random vs Sequential I/O(译注:随机/顺序 I/O)

per I/O产生的KB 字节数是与系统本身workload相关的,有2种不同workload的类型,它们是sequential和random.

7.2.1 Sequential I/O(译注:顺序IO)

iostat 命令提供信息包括IOPS 和每个I/O 数据处理的总额.可使用iostat -x 查看.顺序的workload是同时读顺序请求大量的数据.这包括的应用,比如有商业数据库(database)在执行大量的查询和流媒体服务.在这个workload 中,KB per I/O 的比率应该是很高的.Sequential workload 是可以同时很快的移动大量数据.如果每个I/O 都节省了时间,那就意味了能带来更多的数据处理.

# iostat -x 1

avg-cpu: %user   %nice   %sys    %idle
0.00      0.00    57.1 4  42.86

Device:  rrqm/s wrqm/s   r/s  w/s    rsec/s  wsec/s    rkB/s  wkB/s    avgrq-sz avgqu-sz await   svctm  %util
/dev/sda  0.00  12891.43 0.00 105.71 0.00 1  06080.00  0.00   53040.00 1003.46  1099.43  3442.43 26.49  280.00
/dev/sda1 0.00  0.00     0.00 0.00   0.00    0.00      0.00   0.00     0.00     0.00     0.00    0.00   0.00
/dev/sda2 0.00  12857.14 0.00 5.71   0.00    105782.86 0.00   52891.43 18512.00 559.14   780.00  490.00 280.00
/dev/sda3 0.00  34.29    0.00 100.00 0.00    297.14    0.00   148.57   2.97     540.29   594.57  24.00  240.00

avg-cpu: %user %nice %sys %idle
0.00 0.00 23.53 76.47

Device:  rrqm/s wrqm/s   r/s  w/s    rsec/s  wsec/s    rkB/s  wkB/s    avgrq-sz avgqu-sz await   svctm  %util
/dev/sda  0.00  17320.59 0.00 102.94 0.00    142305.88 0.00   71152.94 1382.40  6975.29  952.29  28.57  294.12
/dev/sda1 0.00  0.00     0.00 0.00   0.00    0.00      0.00   0.00     0.00     0.00     0.00    0.00   0.00
/dev/sda2 0.00  16844.12 0.00 102.94 0.00    138352.94 0.00   69176.47 1344.00  6809.71  952.29  28.57  294.12
/dev/sda3 0.00  476.47   0.00 0.00   0.00    952.94    0.00   1976.47  0.00     165.59   0.00    0.00   276.47

评估IOPS 的效能,可用每秒读写I/O 字节数除以每秒读写IOPS 数得出,比如
rkB/s  除以 r/s
wkB/s  除以 w/s

53040/105 = 505KB per I/O
71152/102 = 697KB per I/O
在上面例子可看出,每次循环下,/dev/sda 的per I/O 都在增加.

7.2.2 Random I/O(译注:随机IO)

Random的worklaod环境下,不依赖于数据大小的多少,更多依赖的是磁盘的IOPS 数.Web和Mail 服务就是典型的Random workload.I/O 请求内容都很小.Random workload是同时每秒会有更多的请求数产生.所以,磁盘的IOPS 数是关键.

# iostat -x 1

avg-cpu: %user %nice %sys %idle
2.04 0.00 97.96 0.00

Device:  rrqm/s  wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/sda 0.00  633.67 3.06 102.31 24.49 5281.63 12.24 2640.82 288.89 73.67 113.89 27.22 50.00
/dev/sda1 0.00   5.10  0.00 2.04  0.00  57.14   0.00   28.57   28.00  1.12  55.00 55.00 11.22
/dev/sda2 0.00 628.57 3.06 100.27 24.49 5224.49 12.24 2612.24 321.50 72.55 121.25 30.63 50.00
/dev/sda3 0.00   0.00  0.00  0.00 0.00   0.00  0.00  0.00       0.00  0.00   0.00  0.00  0.00

avg-cpu: %user %nice %sys %idle
2.15 0.00 97.85 0.00

Device: rrqm/s wrqm/s r/s w/s  rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/sda 0.00  41.94  6.45 130.98 51.61 352.69 25.81 3176.34 19.79  2.90    286.32 7.37 15.05
/dev/sda1 0.00 0.00   0.00   0.00  0.00   0.00  0.00    0.00  0.00  0.00      0.00 0.00  0.00
/dev/sda2 0.00 41.94  4.30 130.98 34.41 352.69 17.20 3176.34 21.18  2.90    320.00 8.24 15.05
/dev/sda3 0.00 0.00   2.15   0.00 17.20   0.00  8.60    0.00  8.00  0.00      0.00 0.00  0.00

计算方式和之前的公式一致:

2640/102 = 23KB per I/O
3176/130 = 24KB per I/O

(译注:对于顺序I/O来说,主要是考虑读取大量数据的能力即KB per request.对于随机I/O系统,更需要考虑的是IOPS值)

7.3 When Virtual Memory Kills I/O

如果系统没有足够的RAM 响应所有的请求,就会使用到SWAP device.就像使用文件系统I/O,使用SWAP device 代价也很大.如果系统已经没有物理内存可用,那就都在SWAP disk上创建很多很多的内存分页,如果同一文件系统的数据都在尝试访问SWAP device,那系统将遇到I/O 瓶颈.最终导致系统性能的全面崩溃.如果内存页不能够及时读或写磁盘,它们就一直保留在RAM中.如果保留时间太久,内核又必须释放内存空间.问题来了,I/O 操作都被阻塞住了,什么都没做就被结束了,不可避免地就出现kernel panic和system crash.

下面的vmstat 示范了一个内存不足情况下的系统:

procs ———–memory———- —swap– —–io—- –system– —-cpu—-
r  b    swpd   free  buff  cache   si   so    bi    bo   in cs   us sy id wa
17  0     1250  3248 45820 1488472    30 132   992    0 2437 7657 23 50  0 23
11  0     1376  3256 45820 1488888    57 245   416    0 2391 7173 10 90  0 0
12  0     1582  1688 45828 1490228    63 131  1348   76 2432 7315 10 90  0 10
12  2     3981  1848 45468 1489824   185 56   2300   68 2478 9149 15 12  0 73
14  2     10385 2400 44484 1489732     0 87   1112   20 2515 11620 0 12  0 88
14  2     12671 2280 43644 1488816    76 51   1812  204 2546 11407 20 45 0 35

这个结果可看出,大量的读请求回内存(bi),导致了空闲内存在不断的减少(free).这就使得系统写入swap device的块数目(so)和swap 空间(swpd)在不断增加.同时看到CPU WIO time(wa)百分比很大.这表明I/O 请求已经导致CPU 开始效率低下.

要看swaping 对磁盘的影响,可使用iostat 检查swap 分区

# iostat -x 1

avg-cpu: %user %nice %sys %idle
0.00  0.00 100.00 0.00

Device:   rrqm/s wrqm/s  r/s     w/s     rsec/s   wsec/s   rkB/s    wkB/s    avgrq-sz avgqu-sz await   svctm %util
/dev/sda  0.00   1766.67 4866.67 1700.00 38933.33 31200.00 19466.67 15600.00 10.68    6526.67  100.56  5.08  3333.33
/dev/sda1 0.00   933.33  0.00    0.00    0.00     7733.33  0.00     3866.67  0.00     20.00    2145.07 7.37  200.00
/dev/sda2 0.00   0.00    4833.33 0.00    38666.67 533.33   19333.33 266.67   8.11     373.33   8.07    6.90  87.00
/dev/sda3 0.00   833.33  33.33   1700.00 266.67   22933.33 133.33   11466.67 13.38    6133.33  358.46  11.35 1966.67

在这个例子中,swap device(/dev/sda1) 和 file system device(/dev/sda3)在互相作用于I/O. 其中任一个会有很高写请求(w/s),也会有很高wait time(await),或者较低的服务时间比率(svctm).这表明2个分区之间互有联系,互有影响.

7.4 结论

I/O 性能监控包含了以下几点:

1,当CPU 有等待I/O 情况时,那说明磁盘处于超负荷状态.
2,计算你的磁盘能够承受多大的IOPS 数.
3,确定你的应用是属于随机或者顺序读取磁盘.
4,监控磁盘慢需要比较wait time(await) 和 service time(svctm).
5,监控swap 和系统分区,要确保virtual memory不是文件系统I/O 的瓶颈.

Tags: io, monitor
Posted in 技术相关 | No Comments »

Linux System and Performance Monitoring(Memory篇) (阅读全文)

此文非原创.转载自:http://www.ourlinux.net/operating-system/linux-system-and-performance-monitoring-memory/ 

5.0 Virtual Memory介绍

虚拟内存就是采用硬盘对物理内存进行扩展,所以对可用内存的增加是要相对在一个有效范围内的.内核会写当前未使用内存块的内容到硬盘上,此时这部分内存被用于其它用途.当再一次需要原始内容时,此时再读回到内存中.这对于用户来说,是完全透明的;在Linux 下运行的程序能够看到,也仅仅是大量的可用内存,同时也不会留意到,偶尔还有部分是驻留在磁盘上的.当然,在硬盘上进行读和写,都是很慢的(大约会慢上千倍),相对于使用真实内存的话,因此程序无法运行的更快.用硬盘的一部分作为Virtual Memory,这就被称为”swap space”(译注:交换空间).

5.1 Virtual Memory Pages

虚拟内存被分为很多 pages(译注:页),在X86架构中,每个虚拟内存页为 4KB.当内核写内存到磁盘或者读磁盘到内存,这就是一次写内存到页的过程.内核通常是在swap 分区和文件系统之间进行这样的操作.

5.2 Kernel Memory Paging

内存分页在正常情况下总是活跃的,与memory swapping(译注:内存交换)之间不要搞错了.内存分页是指内核会定期将内存中的数据同步到硬盘,这个过程就是Memory Paging.日复一日,应用最终将会消耗掉所有的内存空间.考虑到这点,内核就必须经常扫描内存空间并且收回其中未被使用的内存页,然后再重新分配内存空间给其他应用使用.

5.3 The Page Frame Reclaim Algorithm(PFRA)(译注:页框回收算法)

PFRA 就是OS 内核用来回收并释放内存空间的算法.PFRA 选择哪个内存页被释放是基于内存页类型的.页类型有以下几种:

Unreclaimable –锁定的，内核保留的页面
Swappable –匿名的内存页
Syncable –通过硬盘文件备份的内存页
Discardable –静态页和被丢弃的页

除了第一种（Unreclaimable）之外其余的都可以被PFRA进行回收.

与PFRA 相关的,还包括kswapd 内核线程以及Low On Memory Reclaiming(LMR算法) 这2种进程和实现.

5.4 kswapd

kswapd 进程负责确保内存空间总是在被释放中.它监控内核中的pages_high和pages_low阀值.如果空闲内存的数值低于 pages_low,则每次 kswapd 进程启动扫描并尝试释放32个free pages.并一直重复这个过程,直到空闲内存的数值高于 pages_high.

kswapd 进程完成以下几个操作:

1,如果该页处于未修改状态,则将该页放置回空闲列表中.
2,如果该页处于已修改状态并可备份回文件系统,则将页内容写入到磁盘.
3,如果该页处于已修改状态但没有任何磁盘备份,则将页内容写入到swap device.

# ps -ef | grep kswapd
root 30 1 0 23:01 ? 00:00:00 [kswapd0]

5.5 Kernel Paging with pdflush

pdflush 进程负责将内存中的内容和文件系统进行同步操作.也就是说,当一个文件在内存中进行修改后, pdflush 将负责写回到磁盘上.

# ps -ef | grep pdflush
root 28 3 0 23:01 ? 00:00:00 [pdflush]
root 29 3 0 23:01 ? 00:00:00 [pdflush]

当内存中存在10% 的脏页,pdflush 将被启动同步脏页回文件系统里.这个参数值可以通过 vm.dirty_background_ratio 来进行调整.

(译注:
Q:什么是脏页?
A:由于内存中页缓存的缓存作用,写操作实际上都是延迟的.当页缓存中的数据比磁盘存储的数据还要更新时,那么该数据就被称做脏页.)

# sysctl -n vm.dirty_background_ratio
10

在多数环境下,Pdflush与PFRA是独立运行的,当内核调用LMR时,LMR 就触发pdflush将脏页写入到磁盘里.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
在2.4 内核下,一个高负荷的内存环境中,系统将遇到交换过程中不断的崩溃.这是因为PFRA 从一个运行进程中,偷取其中一个内存页并尝试使用.导致结果就是,这个进程如果要回收那个页时,要是没有就会尝试再去偷取这个页,这样一来,就越来越糟糕了.在2.6 内核下,使用”Swap token”修复了这个BUG,用来防止PFRA 不断从一个进程获取同一个页.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

5.6 案例学习:大量的入口I/O

vmstat 工具报告里除了CPU 使用情况,还包括了虚拟内存.以下就是vmstat 输出中关于虚拟内存的部分:

Table 2: The vmstat Memory Statistics
Field Description
Swapd The amount of virtual memory in KB currently in use. As free memory reaches low thresholds, more data is paged to the swap device.
当前虚拟内存使用的总额(单位:KB).空闲内存达到最低的阀值时,更多的数据被转换成页到交换设备中.
Free The amount of physical RAM in kilobytes currently available to running applications.
当前内存中可用空间字节数.
Buff The amount of physical memory in kilobytes in the buffer cache as a result of read() and write() operations.
当前内存中用于read()和write()操作的缓冲区中缓存字节数
Cache The amount of physical memory in kilobytes mapped into process address space.
当前内存中映射到进程地址空间字节数
So The amount of data in kilobytes written to the swap disk.
写入交换空间的字节数总额
Si The amount of data in kilobytes written from the swap disk back into RAM.
从交换空间写回内存的字节数总额
Bo The amount of disk blocks paged out from the RAM to the filesystem or swap device.
磁盘块页面从内存到文件或交换设备的总额
Bi The amount of disk blocks paged into RAM from the filesystem or swap device.
磁盘块页面从文件或交换设备到内存的总额

以下 vmstat 的输出结果,就是演示一个在I/O 应用中,虚拟内存在高负荷情况下的环境

# vmstat 3
procs                               memory                swap       io          system cpu
r  b  swpd       free       buff      cache       si     so  bi      bo   in    cs  us  sy id wa
3 2 809192 261556 79760 886880 416 0 8244 751 426 863 17 3 6 75
0 3 809188 194916 79820 952900 307 0 21745 1005 1189 2590 34 6 12 48
0 3 809188 162212 79840 988920 95 0 12107 0 1801 2633 2 2 3 94
1 3 809268 88756 79924 1061424 260 28 18377 113 1142 1694 3 5 3 88
1 2 826284 17608 71240 1144180 100 6140 25839 16380 1528 1179 19 9 12 61
2 1 854780 17688 34140 1208980 1 9535 25557 30967 1764 2238 43 13 16 28
0 8 867528 17588 32332 1226392 31 4384 16524 27808 1490 1634 41 10 7 43
4 2 877372 17596 32372 1227532 213 3281 10912 3337 678 932 33 7 3 57
1 2 885980 17800 32408 1239160 204 2892 12347 12681 1033 982 40 12 2 46
5 2 900472 17980 32440 1253884 24 4851 17521 4856 934 1730 48 12 13 26
1 1 904404 17620 32492 1258928 15 1316 7647 15804 919 978 49 9 17 25
4 1 911192 17944 32540 1266724 37 2263 12907 3547 834 1421 47 14 20 20
1 1 919292 17876 31824 1275832 1 2745 16327 2747 617 1421 52 11 23 14
5 0 925216 17812 25008 1289320 12 1975 12760 3181 772 1254 50 10 21 19
0 5 932860 17736 21760 1300280 8 2556 15469 3873 825 1258 49 13 24 15

根据观察值,我们可以得到以下结论:

1,大量的disk pages(bi)被写入内存,很明显在进程地址空间里,数据缓存(cache)也在不断的增长.

2,在这个时间点上,空闲内存(free) 始终保持在17MB,即使数据从硬盘读入而在消耗RAM.

3,为了维护空闲列表, kswapd 从读/写缓存区(buff)中获取内存并分配到空闲列表里.很明显可以看到buffer cache(buff) 在逐渐的减少中.

4, 同时kswapd 进程不断的写脏页到swap device(so)时,很明显虚拟内存的利用率是在逐渐的增加中(swpd).

5.7 结论

监控虚拟内存性能由以下几个部分组成:

1,当系统中出现较少的页错误,获得最好的响应时间,是因为memory caches(译注:内存高速缓存)比disk caches更快(译注:磁盘高速缓存).

2,较少的空闲内存,是件好事情,那意味着缓存的使用更有效率.除非在不断的写入swap device和disk.

3,如果系统不断报告,swap device总是繁忙中,那就意味着内存已经不足,需要升级了.

Tags: mem, monitor
Posted in 技术相关 | No Comments »

Linux System and Performance Monitoring(CPU篇) (阅读全文)

    此文非原创.转载自:http://www.ourlinux.net/operating-system/linux-system-and-performance-monitoringcpu%e7%af%87/

       前言: 网上其实有很多关于这方面的文章,那为什么还会有此篇呢,有这么几个原因,是我翻译的动力,第一,概念和内容虽然老套,但都讲得很透彻,而且还很全面.第二,理论结合实际,其中案例分析都不错.第三,不花哨,采用的工具及命令都是最基本的,有助于实际操作.但本人才疏学浅,译文大多数都是立足于自己对原文的理解,大家也可以自己去OSCAN上找原文,如果有什么较大出入,还望留言回复,甚是感激!

Tags: cpu, monitor
Posted in 技术相关 | No Comments »

80后的80条幽默哲理的语录 (阅读全文)

1.人长得漂亮不如活得漂亮！

2.当裤子失去皮带，才懂得什麽叫做依赖。

3.烟不听话，所以我们“抽烟”。

4.你发怒一分钟，便失去60秒的幸福。

5.做与不做的最大区别是：后者拥有对前者的评论权。

6.当男人遇见女人，从此只有纪念日，没有独立日。

7.闭上眼睛，我看到了我的前途…… 8.路见不平一声吼，吼完继续往前走。

9.幸福是个比较级，要有东西垫底才感觉得到。

10.人生有时就像电脑，说死机就死机，没得商量。

11.海阔凭鱼跃，破鼓任人捶。

12.有钱的捧个钱场，没钱的回家取点钱来捧个钱场。

13.能够说出的委屈，便不算委屈；能够抢走的爱人，便不算爱人。

14.一句“拿着”胜过两句“我会给你的”。

15.无理取闹，必有所图！

16.不能自拔的，除了爱情，还有别人地里的萝卜。

17.我以为“隐身”别人就找不到我了，没用的，像我这样的人，无论在哪里都像漆黑夜里的萤火虫，够鲜明够出众。

18.有些事，明知是错的也要去坚持，因为不甘心；有些人，明知是爱的也要去放弃，因为没结局；有时候，明知路没了却还在前行，因为习惯了。

19.钻石恒久远，一颗就破产！

20.铁公鸡还会留点铁锈呢，你根本就是个不锈钢公鸡！

21.还没来得及区沾花惹草，就被人拔光了。

22.女为悦己者容，男为悦己者穷。

23.每个人出生的时候都是原创，可悲的是，很多人渐渐都成了盗版！

24.不要说别人脑子有病，脑子有病的前提是必须有个脑子。

25.在哪里摔倒就在哪里躺下。

26.“浪漫”是一袭美丽的晚礼服，但你不能一天到晚都穿着它。

27.把一切平凡的事做好即不平凡，把一切简单的事做对即不简单。

28.我又不是王子，为什莫女孩遇见我总认为自己应该成为公主！

29.情侣间最矛盾的地方就是幻想彼此的未来，却惦记着对方的过去。

30.所谓缘分，就是爱情成功时的理由，失败时的借口；所谓婚礼，就是有情人终成“家属”的仪式；所谓分手，就是女人说了一百次也未必能做到，而男人说一次就能实现的事。

31.逆风的方向，更适合飞翔。我不怕万人阻挡，只怕自己投降。

32.问候不一定郑重其事，但一定要真诚感人。

33.快乐要懂得分享，才能加倍快乐。

34.忙碌是一种幸福，让我们没时间体会痛苦；奔波是一种快乐，让我们真实的感受生活；疲惫是一种享受，让我们无暇空虚。

35.生活就像“呼吸”，“呼”是为了出一口气，“吸”是为了争一口气。

36.我问过烦恼了，他根本不爱你，让我转告你不要自作多情；健康让我带封情书给你：他对你一生不变！

37.知识就像内裤，看不见但很重要。

38.爱一个人好难，爱两个人好玩，爱三个人好烦，爱四个人翻船，爱五个人彻底玩儿完。

39.女人吻男人是一种幸福，男人吻女人是一种口福。

40.结婚就是给自由穿件棉衣，活动起来不方便，但会很温暖。

41.英雄难过美人关，我不是英雄，美人让我过了关。

42.玩命：要在有命的情况下才能玩，命都没了，拿什么玩啊！

43.别人一夸我，我就担心，担心别人夸得不够。

44.爱情永远比婚姻圣洁，婚姻永远比爱情实惠。

45.探索的旅程不在于发现新大陆，而在于培养新视角。

46.本无意与众不同，怎奈何品味出众。

47.一个人能走多远，要看他与谁同行；一个人有多优秀，要看他有谁指点；一个人有多成功，要看他有谁相伴。

48.叹气是最浪费时间的事情，哭泣是最浪费力气的行径。

49.男人的大脑喜欢女人的内心，但是眼睛喜欢女人的外表。

50.有钱就败家，没钱就拜神。

51.当初结婚是看上眼了，后来离婚是看走眼了。

52.咸鱼翻身，还是咸鱼。

53.我可以选择放弃，但不能放弃选择。

54.作为失败的典型，你实在是太成功了。

55.不是人人都能活的低调，可以低调的基础是随时都能高调。

56.女人喜欢长得坏坏的男人，不是喜欢长坏了的男人.

57.古人说:“女为悦己者容”，其实应该是“女为己悦者容”.

58.我们的爱情在这天夭折了，只为了让彼此有重生的机会.

59.老板用你的时候你就是人才，不用你的时候就变成裁人!

60.一个成功的男人就是能够挣到比妻子花的钱更多的钱，一个成功的女人就是能够找到这样一个男人.

61.跌倒了，爬起来再哭.

62.婚姻的杀手有时不是外遇，而是时间.

63.一个月亮一个你，两个影子我和你，三生有幸认识你，四个西施不如你.

64.绝口不提不是因为忘记，而是因为铭记.

65.有人说爱情是上辈子欠下的情债这辈子来还，我上辈子一定俗不可耐，所以今生无债可还!

66.让未来到来，让过去过去.

67.微小的幸福就在身边，容易满足就是天堂.

68.个头大就一定厉害吗？恐龙不是照样灭绝了！

69.善意的谎言：就是给自己的欺骗找一个很好的借口。

70.父母忽悠孩子叫教育；孩子忽悠父母叫欺骗；互相忽悠叫代沟。

71.孤单是一个人的狂欢，狂欢是一群人的孤单。

72.别跟我谈感情，谈感情伤钱。

73.人生最精彩的不是实现梦想的瞬间，而是坚持梦想的过程!

74.感觉不到痛苦的爱情不是真正的爱情，感觉不到幸福的婚姻必是悲哀的婚姻。

75.一道幸福之门关闭时，另一道就会打开。我们经常盯着关闭的门，对开启的门却视若无睹。

76.咖啡苦与甜，不在于怎末搅拌，而在于是否放糖；一段伤痛，不在于怎末忘记，而在于是否有勇气重新开始。

77.人之所以活的累，是因为放不下架子、撕不开面子、解不开情结。

78.爱是费尽心力地全身投入，然后再百转千回地抽身而出！

79.我自横刀向天笑，笑完之后去睡觉!

80.幽默就是一个人想哭的时候还有笑的兴致！
本文来自: 薄雾倾城博客(http://bwqcw.cn) 详细出处参考：http://bwqcw.cn/2009/12/duan-quotations-80-after-the-80-humorous-philosophical-quotations/

Tags: 笑一笑
Posted in 个人生活 | No Comments »

OLPC 2012年推平板电脑 售价仅75美元 (阅读全文)

这个东西真得不错      

          据国外媒体报道，“百元笔记本”项目基金会OLPC前计划于2012年推出一款全新的平板电脑XO-3，售价仅75美元。XO-3的设计者叶维斯·贝哈尔(Yves Behar)表示，该款平板电脑目前仍处于概念阶段。根据当前的设计理念，它将采用8.5英寸x11英寸的触摸屏，没有任何按钮，用虚拟键盘替代物理键盘。

背部配有摄像头，感应充电器，一个角上还安装了可以折叠的圆环式拎手。在厚度上，只有iPhone手机的1/2。OLPC计划于2012年推出该款产品，价格预计为75美元。

Tags: 看一看
Posted in 个人生活 | No Comments »

领导同志演讲的万能模板 (阅读全文)

声明:原图收自互联网!

 

Tags: funny
Posted in 个人生活 | No Comments »

Red Hat Enterprise Linux Life Cycle (阅读全文)

Red Hat provides support and maintenance over stated time periods for the major versions of Red Hat Enterprise Linux (i.e. versions 2.1, 3, 4, or 5) "Life Cycle". The Life Cycle allows customers and partners to effectively plan, deploy and support Red Hat Enterprise Linux.

The Life Cycle identifies the various levels of maintenance for each major release of Red Hat Enterprise Linux over a total period of seven years from the initial release date, which is often referred to as the general availability date.

Software updates to Red Hat Enterprise Linux are delivered via errata advisories. Errata can be released individually on an as-needed basis or aggregated as a minor release (e.g. version 5.2). Errata may contain security and bug fixes, as well as feature enhancements. All errata are thoroughly tested and qualified against the appropriate Red Hat Enterprise Linux release(s).

The Red Hat Enterprise Linux Life Cycle is designed to reduce the level of change within each major release over time increasing predictability and decreasing maintenance costs. All released errata will remain accessible to active subscribers for the entire Life Cycle. Red Hat published this Life Cycle in an effort to provide as much transparency as possibly and may make exceptions from these policies as conflicts may arise.

Every major version of Red Hat Enterprise Linux is maintained and supported independently during the seven year life cycle. For each major version of Red Hat Enterprise Linux, any errata will only be applied incrementally to the previously released errata.

* This is a schematic view of the Life Cycle, time-spans and dates within the 7 year life cycle are subject to adjustment.
During the entire Life Cycle, Red Hat makes commercially reasonable efforts to maintain binary compatibility for the core runtime environment across all minor releases and asynchronous errata (possible exceptions include critical security issues). Furthermore, major versions of Red Hat Enterprise Linux contain a limited set of backward-compatible libraries from the previous major versions to aid with the migration of applications from one major release to another.

Details

The seven year life cycle for a major release of Red Hat Enterprise Linux is divided into three phases.

The following table details what type of software maintenance is performed during each phase of the seven year life cycle:

Tags: opensource, redhat
Posted in 互联网资讯 | No Comments »

MySQL分区（Partition) (阅读全文)

1.什么是数据库分区？
       数据库分区是一种物理数据库设计技术，DBA和数据库建模人员对其相当熟悉。虽然分区技术可以实现很多效果，但其主要目的是为了在特定的SQL操作中减少数据读写的总量以缩减响应时间。

分区主要有两种形式: (row是行，column是列）
   1. 水平分区（Horizontal Partitioning）这种形式分区是对表的行进行分区，通过这样的方式不同分组里面的物理列分割的数据集得以组合，从而进行个体分割（单分区）或集体分割（1个或多个分区）。所有在表中定义的列在每个数据集中都能找到，所以表的特性依然得以保持。

举个简单例子：一个包含十年发票记录的表可以被分区为十个不同的分区，每个分区包含的是其中一年的记录。（朋奕注：这里具体使用的分区方式我们后面再说，可以先说一点，一定要通过某个属性列来分割，譬如这里使用的列就是年份）

2. 垂直分区（Vertical Partitioning） 这种分区方式一般来说是通过对表的垂直划分来减少目标表的宽度，使某些特定的列 被划分到特定的分区，每个分区都包含了其中的列所对应的行。

举个简单例子：一个包含了大text和BLOB列的表，这些text和BLOB列又不经常被访问，这时候就要把这些不经常使用的text和BLOB了划分到另一个分区，在保证它们数据相关性的同时还能提高访问速度。

在数据库供应商开始在他们的数据库引擎中建立分区（主要是水平分区）时，DBA和建模者必须设计好表的物理分区结构，不要保存冗余的数据（不同表中同时都包含父表中的数据）或相互联结成一个逻辑父对象（通常是视图）。这种做法会使水平分区的大部分功能失效，有时候也会对垂直分区产生影响。

在MySQL 5.1中进行分区

MySQL5.1中最激动人心的新特性应该就是对水平分区的支持了。这对MySQL的使用者来说确实是个好消息，而且她已经支持分区大部分模式：

Range（范围） – 这种模式允许DBA将数据划分不同范围。例如DBA可以将一个表通过年份划分成三个分区，80年代（1980’s）的数据，90年代（1990’s）的数据以及任何在2000年（包括2000年）后的数据。

Hash（哈希） – 这中模式允许DBA通过对表的一个或多个列的Hash Key进行计算，最后通过这个Hash码不同数值对应的数据区域进行分区，。例如DBA可以建立一个对表主键进行分区的表。

Key（键值） – 上面Hash模式的一种延伸，这里的Hash Key是MySQL系统产生的。

List（预定义列表） – 这种模式允许系统通过DBA定义的列表的值所对应的行数据进行分割。例如：DBA建立了一个横跨三个分区的表，分别根据2004年2005年和2006年值所对应的数据。

Composite（复合模式） - 很神秘吧，哈哈，其实是以上模式的组合使用而已，就不解释了。举例：在初始化已经进行了Range范围分区的表上，我们可以对其中一个分区再进行hash哈希分区

转载:http://www.phpv.net/html/1708.html

Tags: mysql, Partition
Posted in 技术相关 | No Comments »

Google,微软,Yahoo,eBay等公司服务器数量统计 (阅读全文)

Google：45万台。搜索巨头的服务器数量一直成为猜测的焦点。我们有一个大概的估计，三年前谷歌公司的服务器数目大概是45万台，如果这个数据是准确的，那么现在肯定就不准确了。因为现在谷歌正在不断的创建新的数据中心。近来谷歌公司透露的集装箱数据中心的服务器数量超过了450,000台，但是那是创建于2005 年的单独的设施。

微软 ：30万台。我们有一些微软服务器数量的一些数字，但也过时了。 从公司的数据中心管理软件中的屏幕快照显示，微软在2008年中期大约有218,000 台服务器运行。 该公司的新芝加哥集装箱可以存放三十万台服务器 ，因此，当部署完后，这个数字会迅速改变。

亚马逊：它是世界上最大的在线商城，同时也是世界上最大的云计算运行商之一。亚马逊公司很少谈及它的数据中心运营。但是我们知道它在2008年从Rackab e公司购买了八千六百万美元的服务器。在它的S3存储服务中存储了四百亿物品。

eBay ：5万台以上。在线拍卖和PayPa 支付服务的活跃用户超过1.60亿，四亿四千三百万用户是Skype用户，eBay有一个庞大的数据中心基础设施。在大型数据仓库中，该公司拥有超过8.5 PB的数据。我们不能确定它要求多少台服务器，但是肯定是大于5万台。

雅虎 ：5万台以上。虽然它的数据中心基础设施并不像谷歌和微软那么巨大，但第三大搜索门户运作的服务器可能超过五万台，以支持其大型免费托管的运作，以及其支付托管服务和雅虎商店(Yahoo Stores)。

GoDaddy：这是世界上最大的管理3500万个域名的域名注册企业，但有效的交叉销售托管计划也使Godaddy成为了美国最大的共享主机运营商之一。它的基础设施在范围上和1&1 Internet类似。

惠普/ EDS公司 ：38万台。尽管服务器“所有者”和系统集成商区别不大，但EDS公司拥有庞大的数据中心的运营。 EDS公司的一份文件称EDS公司在180个数据中心管理了38万台服务器。

IBM公司 ：IBM的数据中心空间超过800万平方英尺，同时，在它的数据中心内有大量的服务器，都是用于客户和它自身的。

Facebook：5万台以上。2008年四月份，Facebook表示它只有10000多台服务器。现在它有2亿用户，保存了至少400亿张图片。很显然Facebook已经超出了10,000台服务器，现在它的服务器完全有可能达到50000台。

原文转载自:http://www.21andy.com/blog/20091218/1543.html

Tags: 互联网
Posted in 互联网资讯 | No Comments »

install plugins for cacti0.87e (阅读全文)

在cacti0.87e上装安装thold,monitor 插件的方法和0.87b有很大的不同

流程步骤

              1.非必需但推荐且重要的一些操作
              2.为cacti-0.8.7e打补丁
              3.安装cacti-plugin-0.8.7e-PA-v2.6
              4.安装settings,monitor,thold插件

1.非必需但推荐且重要的一些操作
打补丁会更改cacti一些主体文件,安装cacti-plugin-0.8.7e-PA-v2.6则会改动cacti的数据库,所以建议在打补丁安装插件之前进行如下操作
      1.所有相关的操作最好在内网操作一遍
      2.把cati的数据库进行备份,把cacti的目进行备份,如果目录rra很大的话,则rra log目录可以不用备

2.为cacti-0.8.7e打补丁

wget http://www.cacti.net/downloads/patches/0.8.7e/cli_add_graph.patch
wget http://www.cacti.net/downloads/patches/0.8.7e/snmp_invalid_response.patch
wget http://www.cacti.net/downloads/patches/0.8.7e/template_duplication.patch
wget http://www.cacti.net/downloads/patches/0.8.7e/fix_icmp_on_windows_iis_servers.patch
wget http://www.cacti.net/downloads/patches/0.8.7e/cross_site_fix.patch
patch -p1 -N < cli_add_graph.patch
patch -p1 -N < snmp_invalid_response.patch
patch -p1 -N < template_duplication.patch
patch -p1 -N < fix_icmp_on_windows_iis_servers.patch
patch -p1 -N < cross_site_fix.patch

参考:http://cacti.net/download_patches.php?version=0.8.7e

3.安装cacti-plugin-0.8.7e-PA-v2.6

wget http://mirror.cactiusers.org/downloads/plugins/cacti-plugin-0.8.7e-PA-v2.6.zip
unzip cacti-plugin-0.8.7e-PA-v2.6.zip
ls cacti-plugin-arch
   cacti-plugin-0.8.7e-PA-v2.6.diff  files-0.8.7e  LICENSE  pa.sql  Readme.txt

转到cacti-0.8.7e安装目录，执行

patch -p1 -N < ../cacti-plugin-arch/cacti-plugin-0.8.7e-PA-v2.6.diff 
mysql -p cacti7e <../cacti-plugin-arch/pa.sql

如下图

pa.sql 也可以如下图导入

 

注意:到这一步时cacti-plugin-0.8.7e-PA-v2.6还需要到cacti的UI界面给用户开启可使用此插件的权限,此步暂时不管

wget http://cactiusers.org/downloads/settings.tar.gz   -P ./plugins
wget http://cactiusers.org/downloads/thold.tar.gz -P ../plugins
wget http://cactiusers.org/downloads/monitor.tar.gz -P ../plugins

tar zxvf settings-0.5.tar.gz
tar zxvf  thold-0.4.1.tar.gz
tar zxvf monitor-0.8.2.tar.gz

编辑cacti0.8-7e目录下的include/global.php,添加如下开插件列表

$plugins[] = 'thold';
$plugins[] = 'monitor';
$plugins[] = 'settings';

进入cacti的UI界面为admin用户开启插件的使用权限。如下图

进入cacti的UI界面install 并开启thold插件，如下图

Tags: cacti, cacti plugins
Posted in 互联网资讯 | No Comments »

分类目录

• 个人生活
• 互联网资讯
• 其它类
• 努力工作
• 小技巧
• 建站技巧
• 技术相关

链接

• A Comprehensive Guide to nmap
• A sys admin blog
• CSS学习站
• find back RM files
• highscalability.com
• kovyrin 'S admin blog
• TaobaoUED
• www.linuxfly.org
• 简简单单
• 阿里coolerfeng
• 风雪之隅

文章索引模板

• 2009年十二月
• 2009年十一月
• 2009年十月
• 2009年九月
• 2009年八月

页面

• Archives
• Special Topic
• 订阅
• 听听音乐
• 首页

RSS

• 注册
• 文章 (RSS)
• 评论 (RSS)

14 queries. 0.447 seconds.

苏ICP备09092408号