今天突然发现访问不了ERP，一旦需要打开Form界面的时候，IE窗口自动退出。同时桌面有一个日志文件，部分内容如下。
An unexpected exception has been detected in native code outside the VM.Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x77ea364eFunction name=NdrRpcSsDefaultAllocateLibrary=C:\WINDOWS\system32\RPCRT4.dll
通过google查询，发现部分关于vista中怎样使用Jinitiator是用高版本的jvm替换对应的jvm。发现并不能解决问题，卸载掉部分jre的版本也没能够解决问题。最后还是在metalink上找到了解决方法，是msn的插件的问题，想起来前两天还错点了msn的按钮，应该是这个原因吧：
Solution
-- To implement the solution, please execute the following steps::Suggest to check if this plug in is installed and enabled. If this is the case disable it using the following actions:1.Tools - Manage Add-ons - Enable or Disable Add-ons
2. In Show option - "Add-ons that have been used by Internet Explorer"Select from the list and check for Name "Windows Live ...."
e.g "Windows Live Messenger", "Windows Live Sing-in Helper" etc.
3. Select "Disable" option4. Close all the Internet explorer browser sessions. Restart the client machine.
5. Retest the issue.
参考：Note:435562.1
2007年9月2日星期日
2007年6月18日星期一
Jinitiator默认大小
问题：
Compuware统计结果显示许多instance的launce transaction都显示为red，证明性能没有达到定义的SLA水平。其实这个Launce transaction的动作就是——打开浏览器，输入ERP的Form登录地址，载入显示登录界面。为什么这么简单的事务性能却很差。作为访问ERP客户的Agent离ERP服务器很近，网络不应该是考虑因素。最后定位为Cache问题。通过控制面板中，点开Jinitiator，察看Cache面板，缓存大小为安装默认的50M。察看存放缓存的目录，已经达到48M。因为在这个Agent上会访问很多的Instance，所以会有相当多的Jar需要Cache。然后，在Basic面板，Enable Java Console，这样可以从Console查看Applet载入的过程。打开一个最近很少访问的ERP地址，从Console可以看到有部分Jar文件需要重新Download（因为不在Cache目录中），有部分Jar从Cache目录中删除（因为已经达到Cache目录的最大限制），这些都是消耗时间的步骤。
解决方法：
增大Cache目录大小。选定无限制，这是因为这个Agent还有20G，而只用来测试ERP性能。
其他：
可以通过控制台设定Java使用的Cache大小，如果系统运行过程中发现是因为客户端速度太慢的问题。先观察一下更改Cache后的结果在说。有资料说The caching mechanism uses a smart expansion algorithm to store JAR files in an uncompressed format。找了很久没有找到到底是什么smart expansion algorithm。算了，也不重要了。
登录Agent后，发现Cache目录的大小刚刚被人改掉了，出手太慢。检查一下Cache目录大小，已经达到61M了。应该和设想的一样。其他性能较差部分，需要再检查一遍QRun的脚本，看到底是服务器性能问题还是脚本问题。
参考：
Metalink: Doc ID: Note:310976.1
http://www.oracle.com/technology/software/products/developer/files/1.3.1.25/readme.html
Compuware统计结果显示许多instance的launce transaction都显示为red，证明性能没有达到定义的SLA水平。其实这个Launce transaction的动作就是——打开浏览器，输入ERP的Form登录地址，载入显示登录界面。为什么这么简单的事务性能却很差。作为访问ERP客户的Agent离ERP服务器很近，网络不应该是考虑因素。最后定位为Cache问题。通过控制面板中，点开Jinitiator，察看Cache面板，缓存大小为安装默认的50M。察看存放缓存的目录，已经达到48M。因为在这个Agent上会访问很多的Instance，所以会有相当多的Jar需要Cache。然后，在Basic面板，Enable Java Console，这样可以从Console查看Applet载入的过程。打开一个最近很少访问的ERP地址，从Console可以看到有部分Jar文件需要重新Download（因为不在Cache目录中），有部分Jar从Cache目录中删除（因为已经达到Cache目录的最大限制），这些都是消耗时间的步骤。
解决方法：
增大Cache目录大小。选定无限制，这是因为这个Agent还有20G，而只用来测试ERP性能。
其他：
可以通过控制台设定Java使用的Cache大小，如果系统运行过程中发现是因为客户端速度太慢的问题。先观察一下更改Cache后的结果在说。有资料说The caching mechanism uses a smart expansion algorithm to store JAR files in an uncompressed format。找了很久没有找到到底是什么smart expansion algorithm。算了，也不重要了。
登录Agent后，发现Cache目录的大小刚刚被人改掉了，出手太慢。检查一下Cache目录大小，已经达到61M了。应该和设想的一样。其他性能较差部分，需要再检查一遍QRun的脚本，看到底是服务器性能问题还是脚本问题。
参考：
Metalink: Doc ID: Note:310976.1
http://www.oracle.com/technology/software/products/developer/files/1.3.1.25/readme.html
订阅：
博文 (Atom)
