QPS 数百万的系统是怎么样的？

昨天早上还在去公司的路上，就看到有个微信群网友发了一份Oracle AWR报告，说有点意思。这一下就激发了我的好奇心了。我打开简单看了眼，确实也发现了几个有趣的地方：

实际上我们可以看到，这是一套Oracle 11.2.0.4 RAC（硬件配置为192c/512g），其中User calls是比较高的，每秒高达31508，Parses 为111408，Hard Parses是1247,Executes(SQL)是709032.9。这里能看出几个问题点，SQL执行量很高，硬解析较高（1247/11408）。从这里大概可以判断share pool设置估计也不算太合理，看了一眼果然：

实际上对于OLTP系统，我们建议share pool 设置大概为SGA的15%-20%（实际上Oracle MOS也有类似建议),当然这也要看数据库的实际情况。从这份awr报告来看，略微调大共享迟应该是可以适当降低解析的（进一步看awr会发现 sql area evicted 并不低的).接下来继续看下Top event：

     从上面的event来看，高并发带来了一些争用，这一点从event name和Wait Class可以看出来，不做过多解释了，都是一些非常常见的等待事件。说到这里，我在想，国产数据库什么时候才能有这样如此媲美Oracle一样的OWI，让性能诊断变的如此简单。

    比如对于cursor：pin S 实际调整数据库参数已经意义不大了，我看了下session_cached_cursors设置已经是500了，并不算小。实际上我们以前在某制造业客户也遇到了类似案例，通过调整SQL代码可以进一步降低解析代价，比如把SQL拆分成多个，类似select /*+SQL1 */.....;select *+SQL2 */..... 这样。

    我们来看看这几个执行频率极高的top SQL， 如果你简单计算一下，根据count(executions/900)大概就是QPS，都是select语句。

    随手转了下这份AWR报告，没想到群里有眼睛非常尖锐的朋友居然发现里面有TOP SQL是我司 zCloud 的监控SQL，这里来看看(这里插播一个广告，看上去这是一份证券行业性能数据，据称zCloud目前已应用国内超20家券商客户)。

   虽然物理读看上去有点高，实际上也还好了，15分钟内仅仅执行了1次，单词执行时间不到0.5s的SQL效率还算Ok了。我进一步看了下这2个SQL都是监控内的，其中一个是监控表空间使用情况的，而且都是经过SQL优化专家调优过的SQL：

WITH fr AS
(SELECT /*+materialize LEADING(@"SEL$4" "RB"@"SEL$4" "TS"@"SEL$4" "U"@"SEL$4" "FI"@"SEL$4") USE_NL(@"SEL$4" "U"@"SEL$4")*/ tablespace_name,
sum(bytes) freesize
FROM dba_free_space
GROUP BY tablespace_name)
SELECT /*+ordered use_hash(a b) use_hash(a t)*/ t.tablespace_name AS TABLESPACE_NAME,
a.FILE_CNT AS file_count,
t.contents AS contents,
t.status,
decode(t.status, 'ONLINE', 1, 'OFFLINE', 2, 3) status_code,
t.extent_management AS extent_mgt,
t.segment_space_management AS segment_mgt,
ROUND(a.bytes / 1048576) AS total_mb,
ROUND(maxbytes/ 1048576) AS max_mb,
ROUND(nvl(b.freesize, 0)/1048576) free_mb,
ROUND((maxbytes-(a.bytes-nvl(b.freesize, 0)))/1048576) max_free_mb,
ROUND(nvl(b.freesize, 0)*100/a.bytes, 2) free_pct,
100-ROUND(nvl(b.freesize, 0)*100/a.bytes, 2) usage_pct,
ROUND(nvl((maxbytes-(a.bytes-nvl(b.freesize, 0))), 0)*100/a.maxbytes, 2) max_free_pct,
100- ROUND(nvl((maxbytes-(a.bytes-nvl(b.freesize, 0))), 0)*100/a.maxbytes, 2) max_usage_pct,
ROUND((a.bytes-nvl(b.freesize, 0))/1048576) used_mb,
t.BLOCK_SIZE AS blockSizes,
t.ENCRYPTED AS encryt,
t.BIGFILE AS bigFile,
t.LOGGING AS loggin,
t.ALLOCATION_TYPE AS allocationTypepl ,
decode(a.AUTOEXTENSIBLE, 'YES', 1, 'NO', 2) AUTOEXTENSIBLE_CODE
FROM
(SELECT tablespace_name,
sum(bytes) bytes,
sum(CASE WHEN maxbytes > bytes THEN maxbytes ELSE bytes END) AS maxbytes,
count(*) FILE_CNT,
decode(sum(decode(AUTOEXTENSIBLE, 'YES', 1, 0)), 0, 'NO', 'YES') AUTOEXTENSIBLE
FROM dba_data_files t
GROUP BY tablespace_name) a,
fr b,
dba_tablespaces t
WHERE a.tablespace_name = t.tablespace_name
AND a.tablespace_name = b.tablespace_name(+)
AND t.contents NOT IN ('TEMPORARY',
'UNDO')

这份Oracle AWR 其实并不算非常大型的系统了，这里完再给大家看一份更为夸张的数据。

   这个用户的数据大家可以看到，实际上更为夸张，4节点RAC每秒SQL执行量之和大概是352万，IO层面来看每秒吞吐在4.5G/s 左右。当然这实际上并非最高峰时间点。

   不管怎么讲，这些数据我认为都是较大的，如果要进行国产化替换，也是一件比较有挑战的事儿。