HIS主服务器加内存，搞定了

lfree

今天下载了文档仔细看了一下，不了解具体的情况，讲一下自己的想法：

因为我们也要面临一次扩内存的动作，2台4G－》8G，因为在7－8月份，
我们门诊出现过几次业务高峰，服务器一台down的情况，看日志根本看
不出什么问题。这样才有这个帖子：

http://www.itpub.net/thread-1186159-1-1.html

我现在基本很少关注his的应用!

1.如果再有一台HP机器，我觉得要好做一些。
这样可以做2台DG，先在一台DG机器做内存升级，如果成功，剩下的就好办了。
然后申请停主机，我觉得正常应该20分钟升级好机器。
我个人的想法切换还是比较危险！

2.我总觉lz的系统存在性能问题，但是连接数这么高，不清楚的情况下很难下
定论。感觉上好象天健的全部模块，对方都上了。像我们医生录入医嘱这块，
已经使用别的系统来录入，使用3层架构，这样连接数减少许多。但是我们前
一阵子挂号系统重做，原来采用的不是军惠的系统，仅仅从军惠取数据，这样
连接数一下子增加了将近150个.而且执行很密集。

实际上在我看来我们的升级完全是治标不治本，可惜上层根本不理解这些。

smartcobra

楼上使用的是那家的系统？

ocp_oracle

用那家的系统已经不重要，重要是的在讨论技术和经验!

fals

连接数非常高，确实，原因很复杂，很多东西也不是我们能控制的。

1  总后下发的版本功能不全，为了解决我们应用需要的一些功能，分别做了很多外挂程序，包括医生综合、护士综合、质量控制等软件，目前一台医生站（物理机器）至少要挂两个程序才能完成正常工作，这个对连接数是增加得最厉害的。

2  HIS外接的系统极多，特别是早期上的系统，如PACS等，不是以统一接口的方式连接到HIS，而是各RIS直接连接到HIS主服务器进行数据操作，效率很高，但对服务器资源的要求也很高，也增加连接数

3  HIS版本较老，一些功能相近的岗位对应程序没办法合并，比如我们的挂号和门诊收费窗口早就做到了岗位合一了，但程序还没有合，也没办法合，除非升级HIS

4  机动岗位比较多，门诊流量大，一些岗位要兼顾好几个工作，比如各种检查登记台，就开了好几个程序

5  工作人员习惯不好，经常开了客户端又不干活，就那么连着，也不退。

6  科室工作站配置有较大的冗余，现在平均一个临床科就有十来台医生工作站，一些跑win98的机器还在坚持工作，实际上平时也用得很少，但打挤的时候也在用，用完了也不关机，客户端程序也不退出来，就那么挂着，白白消耗系统资源。

…………


原因非常多，医院规模比较大，业务量大，HIS太老，我们自己又改不了程序，总后现在也不管这种细小的升级，所以就成这个样子了。

关于性能问题，特别是不良SQL的问题，目前在我们医院并不是很突出，大多数不良SQL都是出自于各统计部门自己编写的统计程序上，我们一直以来都不准这些程序在上午运行，所以对业务的影响也不是很大，信息科的权威与机关统计部门比起来，那是微不足道，所以也不提这个事情了。

smartcobra

原帖由 fals 于 2009-10-12 15:10 发表
连接数非常高，确实，原因很复杂，很多东西也不是我们能控制的。

1  总后下发的版本功能不全，为了解决我们应用需要的一些功能，分别做了很多外挂程序，包括医生综合、护士综合、质量控制等软件，目前一台医生站（物理机器）至少要挂两个程序才能完成正常工作，这个对连接数是增加得最厉害的。

2  HIS外接的系统极多，特别是早期上的系统，如PACS等，不是以统一接口的方式连接到HIS，而是各RIS直接连接到HIS主服务器进行数据操作，效率很高，但对服务器资源的要求也很高，也增加连接数

3  HIS版本较老，一些功能相近的岗位对应程序没办法合并，比如我们的挂号和门诊收费窗口早就做到了岗位合一了，但程序还没有合，也没办法合，除非升级HIS

4  机动岗位比较多，门诊流量大，一些岗位要兼顾好几个工作，比如各种检查登记台，就开了好几个程序

5  工作人员习惯不好，经常开了客户端又不干活，就那么连着，也不退。

6  科室工作站配置有较大的冗余，现在平均一个临床科就有十来台医生工作站，一些跑win98的机器还在坚持工作，实际上平时也用得很少，但打挤的时候也在用，用完了也不关机，客户端程序也不退出来，就那么挂着，白白消耗系统资源。

…………


原因非常多，医院规模比较大，业务量大，HIS太老，我们自己又改不了程序，总后现在也不管这种细小的升级，所以就成这个样子了。

关于性能问题，特别是不良SQL的问题，目前在我们医院并不是很突出，大多数不良SQL都是出自于各统计部门自己编写的统计程序上，我们一直以来都不准这些程序在上午运行，所以对业务的影响也不是很大，信息科的权威与机关统计部门比起来，那是微不足道，所以也不提这个事情了。

家家有本难念的经啊！

lfree

原帖由 fals 于 2009-10-12 15:10 发表
连接数非常高，确实，原因很复杂，很多东西也不是我们能控制的。

做一个简单的计算，假设2000个client 连上, 每个client session需要200KB 的内存，每个服务器处理需要5MB.


Dedicated server
Total memory required = 2000 X (200KB + 5MB) = 10.4GB

Database Resident Connection Pooling（11g）
Total Memory Required = 40X (200KB + 5MB) = 208 MB

Shared Server
2000 X 200KB + 200 X 5MB = 0.4GB+1G=1.4 GB

这个计算来自：
Oracle Database 11g - New Features for DBAs and Developers.pdf
P165页，书上的计算有错，不应该是520GB，而是52GB。


Oracle Database 11g - New Features for DBAs and Developers.pdf (6.3 MB)

[ 本帖最后由 lfree 于 2009-10-13 08:41 编辑 ]

lfree

前2个星期,我们完成了内存升级以及增加网卡工作,因为我们在7,8月份业务高峰的时候,出现主机自动重启的现象,
没有日志,我个人的感觉就是private网卡的流量很大.

我个人认为内存升级+网卡是权宜之计.无法根本解决问题.

升级后db_time时间大约从25m->20m.大约提升25%上下.

看来要进行业务分割才是硬道理.

lfree

说明解决还是要从根本去解决,
不过有一个奇怪的现象:

db file sequential read 反而变大了 现在 9ms ,以前 6ms-7ms.

总的时间倒是变小了.

fals

楼上的，你们内存升上来之后，Oracle的内存相关参数是怎么配置的？能说一说么？

我们近期有个想法，想把SGA增加到8G试试，现在还不能预期这样的改动对性能有多大影响

lfree

我修改了内核参数/etc/sysctl.conf:
kernel.shmmax = 4294967296 原来2G

oracle参数:
sga_max_size                         big integer 3G  原来1.2G
sga_target                           big integer 3G      原来1.2G
pga_aggregate_target                 big integer 1G 原来512M

cluster_interconnects                string      172.16.XXX.YYY

我加的网卡是有两个接口的,我使用绑定(bond),修改cluster_interconnects参数,
让内部传输走这个接口.