多线程软件连接oracle时的CPU、IO
最近有个工作是测试一个处理数据库表的软件，可以理解为一个加密的过程实际有3000W数据，测试环境50W
软件第一个版本，处理6000条需要5分钟，处理50W的数据需要3小时，由此推算处理完全部数据需要7天多
软件第二个版本，支持多线程，开发说支持40个线程、25个数据库连接，每小时可处理900W的数据，数据库IO基本维持在100%
实际结果处理6000条数据需要1分钟，处理50W数据要1小时
而按开发给出的比例，测试库50W数据处理完成只需要3分钟
在这个过程中学习以下知识点
一、40个线程
windows任务管理器-性能-资源监视器 上看到的线程数
10个左右
二、数据库连接
1.--数据库允许的最大连接数
select value from v$parameter where name = 'processes';
1500个
可以满足我们25个数据库连接
2.--当前的连接数
select count(*) from v$session ;
99个
3.--查看不同用户的连接数
select username,count(username) from v$session where username is not null group by username;
我们数据库有6个用户，测试用户使用的是13个
4. --测试的程序的连接数据
select t.PROGRAM,t.SID,t.STATUS,t.SCHEMANAME,t.OSUSER,t.* from v$sessiont where username ='数据库名' and program='程序Tool.exe';
4个，但是Active的只有1个
三、数据库IO基本维持在100%
linux命令：
iostat -x 1 10
avg-cpu:%user %nice %system %iowait%steal %idle
30.10 0.00 26.18 2.36 0.00 41.36
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz awaitsvctm%util
sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb 0.00 92241.00 16.00 1107.00 136.00 745376.00 663.86 2.09 1.86 0.4651.80
1.如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。
2.如果 idle 小于 70% IO压力就较大了,一般读取速度有较多的wait。
3.同时可以结合vmstat 查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比,高过30%时IO压力高)
4.另外还可以参考
svctm 一般要小于 await (因为同时等待的请求的等待时间被重复计算了)，svctm 的大小一般和磁盘性能有关，CPU/内存的负荷也会对其有影响，请求过多也会间接导致 svctm 的增加。await 的大小一般取决于服务时间(svctm) 以及 I/O 队列的长度和 I/O 请求的发出模式。如果 svctm 比较接近 await，说明 I/O 几乎没有等待时间；如果 await 远大于 svctm，说明 I/O 队列太长，应用得到的响应时间变慢，如果响应时间超过了用户可以容许的范围，这时可以考虑更换更快的磁盘，调整内核 elevator 算法，优化应用，或者升级 CPU。
队列长度(avgqu-sz)也可作为衡量系统 I/O 负荷的指标，但由于 avgqu-sz 是按照单位时间的平均值，所以不能反映瞬间的 I/O 洪水。
linux命令vmstat：用来获得有关进程、虚存、页面交换空间及 CPU活动的信息。这些信息反映了系统的负载情况
vmstat 1 10
1表示每个1秒采集一次服务器状态，10表示采集十次。
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
rb swpd free buffcache si so bi bo in cs us sy id wa st
20 1079592 21175233384 12606724 0 0 708755 1 0 23 10 6610
30 1079592 20728033384 12610472 0 0 405888 8204 11685 33 13 5310
70 1079592 21034033384 12595744 0 050241520 9212 11123 44 21 3410
10 1079592 21244833380 12590016 0 0 76 235312 11814 12597 43 23 3220
10 1079592 131394033388 11487824 0 0 0 467836 8205 103695 35 6000
10 1079592 174707233388 11162524 0 0 0 0 8470 103967 34 5800
20 1079592 174535233388 11162796 0 0 272 32 9498 11352 13 12 7220
30 1079592 174014433388 11165720 0 0 283616 9487 116909 15 7510
11 1079592 173828433388 11165652 0 0 123008 11571 14346 20 19 6010
20 1079592 173803633400 11165664 0 0 122140 10710 13180 13 18 6910
如果r经常大于4，且id经常少于40，表示cpu的负荷很重。
=======================================================================================
Linux
top -u oracle
top - 11:34:11 up 95 days, 15:16,2 users,load average: 1.34, 1.41, 1.38
Tasks: 276 total, 3 running, 273 sleeping, 0 stopped, 0 zombie
Cpu(s): 23.0%us, 13.6%sy,0.0%ni, 61.1%id,0.1%wa,0.3%hi,1.9%si,0.0%st
Mem:24608216k total, 23823184k used, 785032k free, 29628k buffers
Swap:2097144k total,1079624k used,1017520k free, 11966212k cached
"2 users"为当前登录到系统的用户，更确切的说是登录到用户的终端数 -- 同一个用户同一时间对系统多个终端的连接将被视为多个用户连接到系统，这里的用户数也将表现为终端的数目；（linux的）
"3 running"为当前运行中的进程数；
"Cpu(s): 23.0%us" 用户空间占用CPU百分比
经过一番折腾，可以看出来，由于测试服务器是个虚拟机，而且除了oralce,上面还装有mongo,redis等服务
IO并没有达到100%,线程数和连接数都达不到开发所给定的值，所以无法在3分钟处理完测试数据库的50W数据。
非常感谢，我的大学同学、大学学长、现同事、前同事和二哥哥这两天对我的支持，
写完了这篇文章，可是心里没底，因为这确实不是我擅长的领域，而且也不知道这么做是否正确
希望好心人看到了，也给我指正指正，讲解讲解吧
http://user.qzone.qq.com/305132437/blog/1445502435 在机器的利用率了看还没有达到瓶颈。是在正常运行中。这样看并发太累了。可以用工具来测试。测试结果不达标也说明不了什么。
页:
[1]
