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

lawhsong

要是这种配置的小鸡，整成双节点RAC，性能会有多大变化呢？**医院的床位编制在2300张左右，日门诊量没有上万，像华西这种规模的医院什么配置的服务器才能满足需要呢？

[ 本帖最后由 lawhsong 于 2009-9-18 18:51 编辑 ]

fals

昨天下班之前写了脚本做热备，吃完晚饭后过去把standby database建起来了。今天观察了一天，日志都用起来了，情况稳定。

再观察两天，下个周二或者周三把1#机的内存给升上去。

fals

原帖由 lfree 于 2009-9-18 08:37 发表
你们高峰多少用户?processes是多少?
使用多长时间了.

我的感觉你们的系统存在性能问题?

昨天上午观察的数字，业务高峰期间session数达到了1842，HP-UX内存还有1.2G左右的free memory。今天观察了一天，基本上free memory都保持在这个数字。

现在的这个系统运行了有七八年了，业务系统（数据采集部份）感觉还没有太严重的性能问题，下面科室自己写的综合统计程序的性能问题也懒得去一个一个的改，人家也不听我们的，觉得他们自己的水平挺高。我们是要求上午不做大的查询，如果发现了长时间的active session，通常情况我们就kill掉就是了。

上次讨论后决定，以后如果kill 之后又连上来，又成了长时间的active session，那么就暂时把这个帐号的create session权限给收了，等到下午再还给他。


门诊医生站问题挺多，也一直没有升级

fals

原帖由 lawhsong 于 2009-9-18 18:49 发表
要是这种配置的小鸡，整成双节点RAC，性能会有多大变化呢？**医院的床位编制在2300张左右，日门诊量没有上万，像华西这种规模的医院什么配置的服务器才能满足需要呢？

RAC管理起来太麻烦，而且现在HP-UX玩得不熟，先拿自己最有把握的办法来搞。业务系统，稳定第一，快速解决问题第一，其他都排在第二位。

我们这边现在收治的病人经常在2900上下，日门诊量周一的时候多些，7500 - 8000之间，上次过了8000，这段时间我没跟踪这个事情了。周六周日门诊量少些。以前内存不够的时候，最担心的就是周一，特别是月底的周一，每次都如临大敌，时时监控着session的状态。

今天咨询了一下专家，专家建议说，我们的这个情况，SGA可以先给到8G，然后再看情况往下调。等物理内存都升完了之后再考虑这个事情吧。

ocp_oracle

RAC也不是什么业务都好使，关键看应用的规模，规模小用上去一点效果都体现不出来！慎用！

lfree

原帖由 fals 于 2009-9-18 22:14 发表


昨天上午观察的数字，业务高峰期间session数达到了1842，HP-UX内存还有1.2G左右的free memory。今天观察了一天，基本上free memory都保持在这个数字。

现在的这个系统运行了有七八年了，业务系统（数据采集部份）感觉还没有太严重的性能问题，下面科室自己写的综合统计程序的性能问题也懒得去一个一个的改，人家也不听我们的，觉得他们自己的水平挺高。我们是要求上午不做大的查询，如果发现了长时间的active session，通常情况我们就kill掉就是了。

上次讨论后决定，以后如果kill 之后又连上来，又成了长时间的active session，那么就暂时把这个帐号的create session权限给收了，等到下午再还给他。


门诊医生站问题挺多，也一直没有升级

高峰期间session数达到了1842，这个也太多了.
我们rac两边(最大)加起来,
606+559=1165 .

而我们的配置内存仅仅4G.

fals

4G + 4G = 8G !!!

lfree

原帖由 fals 于 2009-9-20 21:29 发表
4G + 4G = 8G !!!

是的,我们的连接数量最多是你们的一半.

不过我估计我们的应用没有你们的忙.

[ 本帖最后由 lfree 于 2009-9-21 08:15 编辑 ]

zrqi

没怎么影响业务，挺幸运。
爱吃屁的主机不太熟，18M的双击热备切换在2~3分钟基本可以完成。如果是18M的系统基本上可以不申请停机了。
你们的HIS系统挺能吃内存的，现在1.2G左右的free memory，估计你用不了一年还得加内存。

fals

对于 Unix平台下每一个用户连接数所占用的内存，以及操作系统对内存调度的规律，我们还没有真正的掌握，现在只是根据已有的经验进行估算。

以前16G内存的时候，session也达到过1800多，不过free memory只有100M上下，但还是很少发生页面交换，那时SGA配到2G。每到session达到1800多的时候，一旦发生某一个较长时间active 的session，或者 active session达到40以上的时候，系统整体性能就会极剧下降，active session数很快上升，最高的时候监测到active session 超过70，前端反映极慢，这个时候看内存，页面交换就非常频繁了。理论上讲这个时候服务器还是在运行的，但实际上业务已基本不可用。

这种情况遇到过一次，因为前台业务堵塞得非常严重，直接得启了Oracle数据库，过程非常惊险，天怒人怨啊。回头有空了再慢慢聊这个话题。

HP-UX下的Oracle用户内存分配挺有意思的，等这一阵子忙过了，慢慢研究研究它的规律。