查看: 10506|回复: 7
cpu 的利用率不高， 可load average 很高，会是什么原因呢？
认证徽章论坛徽章:71
cpu 的利用率不高， 可load average 很高，会是什么原因呢？
9:23am&&up 32 days, 21:49,&&3 users,&&load average: 18.19, 17.72, 14.72
328 processes: 326 sleeping, 2 running, 0 zombie, 0 stopped
CPU0 states:&&0.1% user,&&0.1% system,&&0.0% nice, 99.3% idle
CPU1 states:&&0.1% user,&&0.0% system,&&0.0% nice, 99.4% idle
CPU2 states:&&0.2% user,&&0.1% system,&&0.0% nice, 99.2% idle
CPU3 states:&&0.4% user,&&0.2% system,&&0.0% nice, 98.4% idle
CPU4 states:&&1.0% user,&&0.2% system,&&0.0% nice, 98.2% idle
CPU5 states:&&1.3% user,&&0.3% system,&&0.0% nice, 97.3% idle
CPU6 states:&&1.2% user,&&0.1% system,&&0.0% nice, 98.1% idle
CPU7 states:&&1.1% user,&&0.0% system,&&0.0% nice, 98.3% idle
Mem:&&3605516K av, 3592996K used,& &12520K free, 1473864K shrd,& &58704K buff
Swap: 2096400K av,&&672872K used, 1423528K free& && && && && && &952524K cached
&&PID USER& &&&PRI&&NI&&SIZE&&RSS SHARE STAT %CPU %MEM& &TIME COMMAND
19799 oracle& & 16& &0&&640M 638M&&637M S& &&&0.9 18.1&&13:27 oracle
19878 oracle& & 15& &0&&631M 629M&&629M S& &&&0.9 17.8&&11:58 oracle
19894 oracle& & 15& &0 G 1139M S& &&&0.7 32.3&&99:59 oracle
6038 oracle& & 15& &0&&203M 201M&&201M R& &&&0.7&&5.7& &0:16 oracle
12913 oracle& & 15& &0&&& &840 S& &&&0.7&&0.0& &0:15 top
10498 oracle& & 15& &0&&360M 358M&&358M S& &&&0.5 10.1& &6:20 oracle
7495 oracle& & 15& &0&&119M 117M&&116M S& &&&0.5&&3.3& &0:14 oracle
17495 oracle& & 16& &0&&& &908 R& &&&0.5&&0.0& &0:02 top
17775 oracle& & 16& &0&&& &840 S& &&&0.5&&0.0& &0:00 top
14325 oracle& & 15& &0&&636M 634M&&634M D& &&&0.3 18.0& &4:12 oracle
7792 oracle& & 15& &0 4932 S& &&&0.3&&1.1& &0:13 oracle
14688 oracle& & 15& &0 2328 S& &&&0.3&&0.6& &0:03 oracle
19836 oracle& & 15& &0 G 1268M S& &&&0.1 36.0 100:42 oracle
18263 oracle& & 15& &0&&314M 312M&&311M S& &&&0.1&&8.8& &1:56 oracle
30491 oracle& & 15& &0&&186M 184M&&184M S& &&&0.1&&5.2& &0:41 oracle
&&949 oracle& & 15& &0&&114M 112M&&112M D& &&&0.1&&3.1& &0:06 oracle
9090 oracle& & 15& &0 2988 S& &&&0.1&&0.7& &0:00 oracle
16701 oracle& & 15& &0 5272 S& &&&0.1&&1.4& &0:00 oracle
& & 1 root& && &15& &0& &504&&456& &440 S& &&&0.0&&0.0& &2:51 init
& & 2 root& && &15& &0& &&&0& & 0& &&&0 SW& & 0.0&&0.0& &0:00 keventd
& & 3 root& && &15& &0& &&&0& & 0& &&&0 SW& & 0.0&&0.0& &0:00 keventd
& & 4 root& && &15& &0& &&&0& & 0& &&&0 SW& & 0.0&&0.0& &0:00 keventd
论坛徽章:25
也有类似疑问，load average表示CPU队列的长度，高就表示有很长的等待队列，但cpu却不高，似乎矛盾！？
招聘 : 认证徽章论坛徽章:71
有些linux发行版可能有bug？
参考：Bug 650934 - Idle System has high load without visible cause
论坛徽章:5
load average不仅仅和CPU有关，和IO也有关系的，你可以写个低效率的SQL，反复刷新，很容易就能模仿上面的情况。
论坛徽章:5
load average不仅仅和CPU有关，和IO也有关系的，你可以写个低效率的SQL，反复刷新，很容易就能模仿上面的情况。
招聘 : 认证徽章论坛徽章:71
如果IO高，所有CPU的idle都很高也是不合理的
论坛徽章:25
IO不高的，CPU也不忙，不是VM
论坛徽章:0
给出vmstat 命令执行结果看下才对啊。光看那两个也不能完全定位问题啊。
itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有
北京市公安局海淀分局网监中心备案编号：10 广播电视节目制作经营许可证：编号（京）字第1149号10613人阅读
Linux 命令（20）
一、什么是系统平均负载(Load average)？
在Linux系统中，uptime、w、top等命令都会有系统平均负载load average的输出，那么什么是系统平均负载呢？
系统平均负载被定义为在特定时间间隔内运行队列中的平均进程树。如果一个进程满足以下条件则其就会位于运行队列中：
(通俗的说，运行队列中的进程树正在消耗内存和CPU资源，从而能算出消耗资源的比例。）
&&&&&&&& - 它没有在等待I/O操作的结果
- 它没有主动进入等待状态(也就是没有调用'wait')
- 没有被停止(例如：等待终止)
例如：
[root@opendigest root]# uptime
7:51pm up 2 days, 5:43, 2 users, load average: 8.13, 5.90, 4.94
命令输出的最后内容表示在过去的1、5、15分钟内运行队列中的平均进程数量。
一般来说只要每个CPU的当前活动进程数不大于3那么系统的性能就是良好的，如果每个CPU的任务数大于5，那么就表示这台机器的性能有严重问题。对于上面的例子来说，假设系统有两个CPU，那么其每个CPU的当前任务数为：8.13/2=4.065。这表示该系统的性能是可以接受的。
二、Load average的算法
上面的输出数据是每隔5秒钟检查一次活跃的进程数，然后根据这个数值算出来的。如果这个数除以CPU的数目，结果高于5的时候就表明系统在超负荷运转了。其算法(摘自Linux 2.4的内核代码)如下：
文件: include//sched.h:
#define FSHIFT 11 /* nr of bits of precision */
#define FIXED_1 (1&#define LOAD_FREQ (5*HZ) /* 5 sec intervals */
#define EXP_1 1884 /* 1/exp(5sec/1min) as fixed-point, 2048/pow(exp(1), 5.0/60) */
#define EXP_5 2014 /* 1/exp(5sec/5min), 2048/pow(exp(1), 5.0/300) */
#define EXP_15 2037 /* 1/exp(5sec/15min), 2048/pow(exp(1), 5.0/900) */
#define CALC_LOAD(load,exp,n) \
load *= \
load += n*(FIXED_1-exp); \
load &&= FSHIFT;
/**********************************************************/
文件: kernel/timer.c:
unsigned long avenrun[3];
static inline void calc_load(unsigned long ticks)
unsigned long active_ /* fixed-point */
static int count = LOAD_FREQ;
count -=
if (count & 0) {
count += LOAD_FREQ;
active_tasks = count_active_tasks();
CALC_LOAD(avenrun[0], EXP_1, active_tasks);
CALC_LOAD(avenrun[1], EXP_5, active_tasks);
CALC_LOAD(avenrun[2], EXP_15, active_tasks);
/**********************************************************/
文件: fs/proc/proc_misc.c:
#define LOAD_INT(x) ((x) && FSHIFT)
#define LOAD_FRAC(x) LOAD_INT(((x) & (FIXED_1-1)) * 100)
static int loadavg_read_proc(char *page, char **start, off_t off,
int count, int *eof, void *data)
int a, b,
a = avenrun[0] + (FIXED_1/200);
b = avenrun[1] + (FIXED_1/200);
c = avenrun[2] + (FIXED_1/200);
len = sprintf(page,&%d.%02d %d.%02d %d.%02d %ld/%d %d\n&,
LOAD_INT(a), LOAD_FRAC(a),
LOAD_INT(b), LOAD_FRAC(b),
LOAD_INT(c), LOAD_FRAC(c),
nr_running(), nr_threads, last_pid);
return proc_calc_metrics(page, start, off, count, eof, len);
三、/proc/loadavg 各项数据的含义
/proc文件系统是一个虚拟的文件系统，不占用磁盘空间，它反映了当前操作系统在内存中的运行情况，查看/proc下的文件可以聊寄到系统的运行状态。查看系统平均负载使用“cat /proc/loadavg”命令，输出结果如下：
0.27 0.36 0.37 4/83 4828/
前三个数字大家都知道，是1、5、15分钟内的平均进程数（有人认为是系统负荷的百分比，其实不然，有些时候可以看到200甚至更多）。后面两个呢，一个的分子是正在运行的进程数，分母是进程总数；另一个是最近运行的进程ID号。
四、查看系统平均负载的常用命令
1、cat /proc/loadavg
2、uptime
名称： uptime
使用权限： 所有使用者
使用方式： uptime [-V]
说明： uptime 提供使用者下面的资讯，不需其他参数：
现在的时间 系统开机运转到现在经过的时间 连线的使用者数量 最近一分钟，五分钟和十五分钟的系统负载
参数： -V 显示版本资讯。
范例： uptime
其结果为：
10:41am up 5 days, 10 min, 1 users, load average: 0.00, 0.00, 1.99
功能说明：显示目前登入系统的用户信息。
语 法：w [-fhlsuV][用户名称]
补充说明：执行这项指令可得知目前登入系统的用户有那些人，以及他们正在执行的程序。单独执行w
指令会显示所有的用户，您也可指定用户名称，仅显示某位用户的相关信息。
参 数：
-f 开启或关闭显示用户从何处登入系统。
-h 不显示各栏位的标题信息列。
-l 使用详细格式列表，此为预设值。
-s 使用简洁格式列表，不显示用户登入时间，终端机阶段作业和程序所耗费的CPU时间。
-u 忽略执行程序的名称，以及该程序耗费CPU时间的信息。
-V 显示版本信息。
4、top
功能说明：显示，管理执行中的程序。
语 法：top [bciqsS][d &间隔秒数&][n &执行次数&]
补充说明：执行top指令可显示目前正在系统中执行的程序，并通过它所提供的互动式界面，用热键加以管理。
参 数：
b 使用批处理模式。
c 列出程序时，显示每个程序的完整指令，包括指令名称，路径和参数等相关信息。
d&间隔秒数& 设置top监控程序执行状况的间隔时间，单位以秒计算。
i 执行top指令时，忽略闲置或是已成为Zombie的程序。
n&执行次数& 设置监控信息的更新次数。
q 持续监控程序执行的状况。
s 使用保密模式，消除互动模式下的潜在危机。
S 使用累计模式，其效果类似ps指令的&-S&参数。
5、tload
功能说明：显示系统负载状况。
语 法：tload [-V][-d &间隔秒数&][-s &刻度大小&][终端机编号]
补充说明：tload指令使用ASCII字符简单地以文字模式显示系统负载状态。假设不给予终端机编号，则会在执行tload指令的终端机显示负载情形。
参 数：
-d&间隔秒数& 设置tload检测系统负载的间隔时间，单位以秒计算。
-s&刻度大小& 设置图表的垂直刻度大小，单位以列计算。
-V 显示版本信息。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：146586次
积分：2206
积分：2206
排名：第18144名
原创：50篇
转载：78篇
(6)(8)(5)(2)(22)(1)(3)(3)(4)(1)(8)(2)(1)(12)(15)(36)
(window.slotbydup = window.slotbydup || []).push({
id: '4740881',
container: s,
size: '200,200',
display: 'inlay-fix'博客访问： 330045
博文数量： 69
博客积分： 2952
博客等级： 少校
技术积分： 683
注册时间：
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： LINUX
$ uptime11:12:26 up 3:44, 4 users, load average: 0.38, 0.31, 0.19
系统平均负载被定义为在特定时间间隔内运行队列中的平均进程树。如果一个进程满足以下条件则其就会位于运行队列中：
它没有在等待I/O操作的结果
它没有主动进入等待状态(也就是没有调用'wait')
没有被停止(例如：等待终止)
上面的输出，load
average后面分别是1分钟、5分钟、15分钟的负载情况。数据是每隔5秒钟检查一次活跃的进程数，然后根据这个数值算出来的。如果这个数除以CPU
的数目，结果高于5的时候就表明系统在超负荷运转了。&
Linux系统Load average负载详细解释& 我们知道判断一个系统的负载可以使用top，uptime等命令去查看，它分别记录了一分钟、五分钟、以及十五分钟的系统平均负载
例如我的某台服务器：
$ uptime
09:50:21 up 200 days, 15:07, 1 user, load average: 0.27, 0.33, 0.37
大部分的人都认为这个数字越小越好，其实有很多关联的提示信息，今天看到这个好文，应该可以给大家说清楚很多问题，转一下：
原文链接：
你可能对于 Linux 的负载均值（load averages）已有了充分的了解。负载均值在 uptime 或者 top 命令中可以看到，它们可能会显示成这个样子：
load average: 0.09, 0.05, 0.01
很多人会这样理解负载均值：三个数分别代表不同时间段的系统平均负载（一分钟、五 分钟、以及十五分钟），它们的数字当然是越小越好。数字越高，说明服务器的负载越 大，这也可能是服务器出现某种问题的信号。
而事实不完全如此，是什么因素构成了负载均值的大小，以及如何区分它们目前的状况是 “好”还是“糟糕”？什么时候应该注意哪些不正常的数值？
回答这些问题之前，首先需要了解下这些数值背后的些知识。我们先用最简单的例子说明， 一台只配备一块单核处理器的服务器。
行车过桥
一只单核的处理器可以形象得比喻成一条单车道。设想下，你现在需要收取这条道路的过桥 费 —
忙于处理那些将要过桥的车辆。你首先当然需要了解些信息，例如车辆的载重、以及
还有多少车辆正在等待过桥。如果前面没有车辆在等待，那么你可以告诉后面的司机通过。 如果车辆众多，那么需要告知他们可能需要稍等一会。
因此，需要些特定的代号表示目前的车流情况，例如：
0.00 表示目前桥面上没有任何的车流。 实际上这种情况与 0.00 和 1.00 之间是相同的，总而言之很通畅，过往的车辆可以丝毫不用等待的通过。
1.00 表示刚好是在这座桥的承受范围内。 这种情况不算糟糕，只是车流会有些堵，不过这种情况可能会造成交通越来越慢。
超过 1.00，那么说明这座桥已经超出负荷，交通严重的拥堵。 那么情况有多糟糕？ 例如 2.00
的情况说明车流已经超出了桥所能承受的一倍，那么将有多余过桥一倍的车辆正在焦急的等待。3.00
的话情况就更不妙了，说明这座桥基本上已经快承受不了，还有超出桥负载两倍多的车辆正在等待。
上面的情况和处理器的负载情况非常相似。一辆汽车的过桥时间就好比是处理器处理某线程 的实际时间。Unix 系统定义的进程运行时长为所有处理器内核的处理时间加上线程 在队列中等待的时间。
和收过桥费的管理员一样，你当然希望你的汽车（操作）不会被焦急的等待。所以，理想状态 下，都希望负载平均值小于 1.00 。当然不排除部分峰值会超过 1.00，但长此以往保持这 个状态，就说明会有问题，这时候你应该会很焦急。
“所以你说的理想负荷为 1.00 ？”
嗯，这种情况其实并不完全正确。负荷 1.00 说明系统已经没有剩余的资源了。在实际情况中 ，有经验的系统管理员都会将这条线划在 0.70：
“需要进行调查法则”： 如果长期你的系统负载在 0.70 上下，那么你需要在事情变得更糟糕之前，花些时间了解其原因。
“现在就要修复法则”：1.00 。 如果你的服务器系统负载长期徘徊于 1.00，那么就应该马上解决这个问题。否则，你将半夜接到你上司的电话，这可不是件令人愉快的事情。
“凌晨三点半锻炼身体法则”：5.00。 如果你的服务器负载超过了 5.00 这个数字，那么你将失去你的睡眠，还得在会议中说明这情况发生的原因，总之千万不要让它发生。
阅读(35970) | 评论(1) | 转发(3) |
相关热门文章
给主人留下些什么吧！~~
谢谢分享！
请登录后评论。理解Linux系统中的load average_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
理解Linux系统中的load average
阅读已结束，下载文档到电脑
想免费下载本文？
定制HR最喜欢的简历
你可能喜欢首页 & Linux/unix/mac进程上下文频繁切换导致load average过高 一、问题现象 现网有两台虚拟机主机95%的cpu处于idle状态，内存使用率也不是特别高，而主机的load average达到了40多。 二、问题分析 先在主机上通过top、free、ps、iostat&等常用工具分析了下主机的CPU、内存、IO使用情况，发现三者都不高。通过vmstat 1 查看的结果如下：
从vmstat的输出结果来看，io项的block in 和block out 并不频繁。而system项的每称的中断数（in)、每秒的上下文切换（cs）特别频繁。这就造成load avaerage会特别高。大方向上的根因找到了，具体是哪个进程如何频繁的进行中断和上下文件的切换呢？ 这里使用pidstat -w 1 （每秒刷新输出上下文切换情况），输出见下图：
从上图中可以看到有cswch(自愿的上下文切换)和nvcswch(非自愿的上下文切换)及对应的命令， 出vsftpd占用的文件交换比较多。可以看到这里显示的cs 值和总值还是有比较大的差距，由于主机上启动了不止一个vsftpd进程，而且pidstat 通过1秒刷新的时候并不会显示所有，通过pidstat -w执行几次收集所有发现所有的vsftpd进程占用的cs值叠加和vmstat里的比较相近了。
将结果通知业务人员后，和业务人员的猜测也一致，由于ftp使用的目录结构层次较深、文件数也比较多，业务在备份老的使用目录并重新创建单层目录后，观察一段后，发现load average降下来了，稳定在1以下。 当然这里只是处理方法的一种，现网中有些程序不好进行这样的修改的，又不让让进程在cpu之间频繁切换的，也有通过设置固定运行的CPU上进行调优的方法，如下两个进程运行在0－7号cpu上：[root@www ~]# taskset -c -p 6389
pid 6389's current affinity list: 0-7
[root@www ~]# taskset -c -p 6580
pid 6580's current affinity list: 0-7 可以通过taskset让其固定在0－1号cpu上运行：[root@www ~]# taskset -c 0,1 -p 6389 这样做的原理是每当进程在切换到下一个cpu core上进会flush当前的cache数据，指定CPU时会减少这样的操作，增加进程的处理速度。这个对老的程序调优时比较有效。 三、有关上下文切换 1、上下文切换的理解 什么是上下文件切换呢？引用老外的一句话：A context switch (also sometimes referred to as a process switch or a task switch) is the switching of the CPU (central processing unit) from one process or thread to another.更详细的说明可以参看linfo站点 或 维基百科 。 context switch过高会导致CPU像个搬运工，频繁在寄存器和运行队列之间奔波 ，更多的时间花在了线程切换，而不是真正工作的线程上。直接的消耗包括CPU寄存器需要保存和加载，系统调度器的代码需要执行。间接消耗在于多核cache之间的共享数据。 2、引起上下文切换的原因 对于抢占式操作系统而言， 大体有几种： 当前任务的时间片用完之后，系统CPU正常调度下一个任务； 当前任务碰到IO阻塞，调度线程将挂起此任务，继续下一个任务； 多个任务抢占锁资源，当前任务没有抢到，被调度器挂起，继续下一个任务； 用户代码挂起当前任务，让出CPU时间； 硬件中断； 什么样的操作会引起CS，这里有一篇博文感觉写的很不错，虽然其中的代码部分并不是理解 。其中有如下几句话： linux中一个进程的时间片到期，或是有更高优先级的进程抢占时，是会发生CS的，但这些都是我们应用开发者不可控的 －－－前面一部分描述的很到位，后面一部分在系统层面和kernel 开发层面可以调用nice 或 renice进行设置优先级以保证某些程序优先在CPU中的占用时间，但也不能细化到CS层面。 站在开发者的角度，我们的进程可以主动地向内核申请进行CS 。操作方法为：休眠当前进程/线程；唤醒其他进程/线程 。 3、上下文切换测试工具 1、LMbench 是带宽（读取缓存文件、内存拷贝、读写内存、管道等）和反应时间（上下文切换、网路、进程创建等）的评测工具； 2、micro-benchmark contextswitch 可以测试不同的CPU在最少多少ns可以进行一次上下文件切换，再转化为秒，我们可以确认该处理器每可以进行的上下文件切换数 ，该工具的使用可以参看tsuna的blog。 4、上下文切换的查看方法 sar -w ，这个只是能看出主机上总的上下文件切换的情况# sar -w 1
Total number of tasks created per second.
Total number of context switches per second. 同样，vmstat也可以查看总的上下文切换情况，不过vmstart输出的结果更多，便比通过对比发现问题：# vmstat 3
procs -----------memory----------
---swap-- -----io----
-system-- ----cpu----
cs us sy id wa
0 查看每个进程或线程的上下文件使用情况，可以使用pidstat命令或者通过查看proc 。# pidstat -w
每个进程的context switching情况
# pidstat -wt
细分到每个threads
查看proc下的文件方法如下：
# grep ctxt /proc/$pid/status
voluntary_ctxt_switches:
#自愿的上下文切换
nonvoluntary_ctxt_switches:
#非自愿的上下文切换 cswch/s: 每秒任务主动(自愿的)切换上下文的次数，当某一任务处于阻塞等待时，将主动让出自己的CPU资源。 nvcswch/s: 每秒任务被动(不自愿的)切换上下文的次数，CPU分配给某一任务的时间片已经用完，因此将强迫该进程让出CPU的执行权。 上下文切换部分零零碎碎先到这里吧，只是想说明上下文切换还是比较重要的一个指标的。nagios check_mk默认有对上下文的监控，其使用的方法是通过两/proc/stat文件里取到ctxt行，并取两个时间段之间的差值来确认。# cat /proc/stat|grep ctxt
本站的发展离不开您的资助，金额随意,欢迎来赏！
分类: Linux/unix/mac linux高级篇, 故障案例
回复 | 引用 本文目前尚无任何 trackbacks 和 pingbacks.您可能也喜欢linux 匿名管道 linux comet模型下的连接数统计 linux内存管理 linux内存分配与回收 ipcs与Linux共享内存 捐助本站
如您感觉本博客有用，可扫码向本博客捐赠近期文章 python实现hp刀片ilo地址配置 shell实现hp刀片ilo地址配置 根据IP和掩码计算网段 shell实现netmask掩码和cidr掩码位转换 s权限位引发postfix及crontab异常处理文章归档 文章归档 选择月份 2017年九月 &(5) 2017年八月 &(3) 2017年七月 &(4) 2017年六月 &(2) 2017年五月 &(3) 2017年三月 &(3) 2017年二月 &(3) 2017年一月 &(4) 2016年十二月 &(4) 2016年十一月 &(6) 2016年十月 &(5) 2016年九月 &(5) 2016年八月 &(9) 2016年七月 &(5) 2016年六月 &(10) 2016年五月 &(18) 2016年四月 &(5) 2016年三月 &(4) 2016年二月 &(5) 2016年一月 &(8) 2015年十二月 &(8) 2015年十一月 &(9) 2015年十月 &(17) 2015年九月 &(10) 2015年八月 &(25) 2015年七月 &(11) 2015年六月 &(15) 2015年五月 &(23) 2015年四月 &(14) 2015年三月 &(22) 2015年二月 &(15) 2015年一月 &(24) 2014年十二月 &(13) 2014年十一月 &(16) 2014年十月 &(19) 2014年九月 &(19) 2014年八月 &(18) 2014年七月 &(20) 2014年六月 &(21) 2014年五月 &(24) 2014年四月 &(17) 2014年三月 &(29) 2014年二月 &(22) 2014年一月 &(22) 2013年十二月 &(24) 2013年十一月 &(20) 2013年十月 &(18) 2013年九月 &(16) 2013年八月 &(16) 2013年七月 &(20) 2013年六月 &(21) 2013年五月 &(19) 2013年四月 &(18) 2013年三月 &(24) 2013年二月 &(21) 2013年一月 &(18) 2012年十二月 &(24) 2012年十一月 &(18) 2012年十月 &(17) 2012年九月 &(17) 2012年八月 &(18) 2012年七月 &(26) 2012年六月 &(36) 2012年五月 &(36) 2012年四月 &(28) 2012年三月 &(46) 2012年二月 &(23) 2012年一月 &(15) 2011年十二月 &(27) 2011年十一月 &(59) 2011年十月 &(19) 2011年九月 &(16) 2011年八月 &(46)
