weblogic挖礦事件

Ⅰ weblogic應用的web.xml經常被覆蓋，如何查到原因

應用的web.xml是不會被webllogic修改的，修改為固定的版本可以建議你看一下不是不有腳本在做更新，可以看一下什麼時間修改的。

Ⅱ Jolt調用Tuxedo服務，該怎麼處理

對於BEA的中間價產品TUXEDO，常採用C/C++語言編寫後台服務程序，廣泛應用於電信、金融等領域，因項目的需要，我們經常面臨調TUXEDO服務的需求！

對於JAVA調TUXEDO服務，有三種方法：一是通過JNI，二是通過WTC，三是通過JOLT！這三種方式各有優劣，簡單的描述為：

JNI

優--無需購買License；發布TUXEDO服務無需做額外限制；無需藉助於任何J2EE容器

劣--JNI影響系統移植；防止過度JNI帶來性能問題

WTC（WEBLOGIC為TUXEDO定製）

優--因定製，存在一套和TUXEDO API相對應的JAVA API；發布TUXEDO服務無需做額外限制；雙向調用

劣--需要購買License；依賴於WEBLOGIC容器，不能移植到其它J2EE容器（如WEBSPHERE，JBOSS）

JOLT

優--可用於但不依賴於J2EE容器（如WEBLOGICWEBSPHERE，JBOSS）；提供的API用WTC類似但不同；

劣--需要購買License；發布TUXEDO服務有些額外的要求；不提供集成的 WebLogic Server-Tuxedo 事務的機制

由此可知，第一，在受限於License經濟壓力或無法要求UXEDO服務方發布服務的情況下，我們可以選擇JNI方式調TUXEDO服務；

第二，當需要一般 Java 客戶端或其他 Web 伺服器應用程序且 WebLogic Server 不是解決方案的一部分時，用戶應使用 Jolt（而不使用 WTC）作為解決方案。

對於jolt方式調TUXEDO服務，3個必須的JAR包：jolt.jar、joltjse.jar、joltwls.jar，下面信息也許對您有幫助：

[轉貼]不涉及wls的jolt客戶端實現

1、如果不使用wls，同樣可以使用jolt提供的pool功能，而這又分為兩種：一種是基於web容器的servlet jolt
pool，另一種則是普通java客戶端的jolt
pool。前者在$TUXDIR/udataobj/jolt/examples/servlet/simpapp下有示例，後者則未提供。
2、如果不使用jolt產品自帶的pool，也可以自己實現。套路為：創建Jolt Session >
基於此session構建JoltRemoteService對象並發起tuxedo調用 > 釋放jolt
session。這里有個要點就是在使用session前需要用session.isAlive()來判斷當前session是否可用，因為JSL的-T
參數及防火牆對idle連接的干擾都可能導致已有的session是無效的。
3、創建JoltRemoteSession時一定記得為三個超時屬性（IDLETIMEOUT/RECVTIMEOUT/SENDTIMEOUT）進行
顯式的設置。idle超時和tuxedo的JSL
-T屬性對應，該設置將保證session.isAlive()返回正確的布爾值。RECV超時則控制client端自發起call至收到tuxedo
return這一過程的預期時常。
5、tuxedo側在ubb里為相應的service配置了SVCTIMEOUT，所以service執行超時後會收到SIGKILL而被終止，這樣一
來，客戶端的call會收到TPESVCERR錯，對應的異常為bea.jolt.ServiceException。客戶端需要對此異常進行處理，此
外，客戶端捕獲此異常的時間點應當和ulog中該server被kill的時間點對應。
6、在客戶端，時不時會發現由於達到RECVTIMEOUT而導致的客戶端接收超時。客戶的疑問是：當前RECVTIMEOUT設置為25s，而ubb中
相應SVCTIMEOUT設置為10s且scanunit為默認的10s，所以理論上不應發生25s的客戶端RECVTIMEOUT超時。庹達人提出了一
種懷疑，即client端請求抵達tuxedo側時，server出現排隊情況，請求未被及時處理，這個排隊時長決定了20s以外的時間差。對於此，建議
客戶使用MSSQ，並監控pq的情況。

使用XMLink和Jolt實現IBM WebSphere與BEA Tuxedo的互連 第一部分

使用XMLink和Jolt實現IBM WebSphere與BEA Tuxedo的互連 第二部分

下面，我們重點關注下WTC，WebLogic Tuxedo Connector (WTC) 提供了 WebLogic Server 應用程序與
Tuxedo 服務之間的互操作性。WTC 允許 WebLogic Server 客戶端調用 Tuxedo 服務，Tuxedo 客戶端調用
WebLogic Server Enterprise Java Bean (EJB) 來響應服務請求，兩者之間的簡單關聯關系如下圖：

關於WTC的配置原則和最佳實踐可參考下面的鏈接：

配置准則
最佳實踐
為方便記，摘錄過來：

配置准則

在配置 WebLogic Tuxedo Connector 時請使用以下准則：

最佳實踐

以下部分提供了使用 WTC 時的最佳實踐：

請參閱「WebLogic Tuxedo Connector 編程人員指南」中的應用程序錯誤管理。
請參閱「WebLogic Tuxedo Connector 管理指南」中的系統級調試設置。
將 Security 的值設置為 DM_PW。請參閱「WebLogic
Tuxedo Connector 管理指南」中的遠程訪問點的身份驗證。
啟用鏈接級加密並將 min-encrypt-bits 參數設置為
40，將 max-encrypt-bits 設置為 128。請參閱「WebLogic Tuxedo Connector 管理指南」中的鏈接級加密。
在 WebLogic Server 群集的所有節點上配置 WTC 實例。
每個群集節點中的每個 WTC 實例都必須具有相同的配置。
請參閱「WebLogic Tuxedo Connector 管理指南」中的如何管理群集環境中的
WebLogic Tuxedo Connector。

在配置連接策略時，請使用 ON_STARTUP 和 INCOMING_ONLY。
ON_STARTUP 和 INCOMING_ONLY 總是成對出現。例如，如果使用 ON_STARTUP 配置了
WTC 遠程訪問點，則必須將遠程訪問點的 Tuxedo 域配置的 DM_TDOMAIN 部分配置為 INCOMING_ONLY。在此情況下，WTC
總是充當會話發起方。請參閱「WebLogic Tuxedo Connector 管理指南」中的配置訪問點之間的連接。

避免使用連接策略 ON_DEMAND。首選連接策略是 ON_STARTUP 和 INCOMING_ONLY。這樣會減少因路由ON_DEMAND 的語義而引起的服務請求失敗。請參閱「WebLogic
Tuxedo Connector 管理指南」中的配置訪問點之間的連接。
在設計應用程序時，請考慮使用以下 WTC 功能：鏈接級故障轉移、服務級故障轉移和負載平衡。請參閱「WebLogic Tuxedo Connector 管理指南」中的配置故障轉移和故障回復。
請考慮使用 WebLogic Server 群集提供額外的負載平衡和故障轉移。要在 WebLogic Server 群集中使用 WTC，請執行下列操作：

如果 WTC 到 Tuxedo 的連接使用了 Internet，則要使用以下安全設置：

應用程序邏輯應該提供機制來管理和解釋應用程序中的錯誤條件。

避免在 TypedFML32 緩沖區內使用嵌入的 TypedFML32 緩沖區。請參閱「WebLogic
Tuxedo Connector 編程人員指南」中的將 FML 用於 WebLogic Tuxedo
Connector。
如果應用程序處理重負載，請考慮配置更多的遠程 Tuxedo 訪問點並讓 WTC 平衡訪問點之間的工作負載。請參閱「WebLogic Tuxedo Connector 管理指南」中的配置故障轉移和故障回復。
在使用事務應用程序時，盡量讓同一事務中涉及的遠程服務能夠從同一遠程訪問點訪問。請參閱「WebLogic Tuxedo Connector 編程人員指南」中的 WebLogic
Tuxedo Connector JATMI 事務。
從網關調度服務時，可用的客戶端線程數可能會限制運行的並發服務數。沒有任何 WebLogic Tuxedo Connector 特性可以增加可用線程的數量。在調用服務時請使用合理的線程模型。請參閱「配置
WebLogic Server 環境」中的線程管理和使用工作管理器優化調度的工作。
WebLogic Server 9.2 及更高版本提供了改進的路由演算法，這增強了事務性能。具體說就是，當 2 階段提交 (2PC) 事務中具有不止一項 Tuxedo 服務請求時，性能就會相應提高。如果應用程序僅向
Tuxedo 域執行單個服務請求，則可以通過設置以下 WebLogic Server 命令行參數來禁用此功能：
通過在緩沖區中使用最大數量的對象來調用構造方法 TypedFML32。即使是很難預測最大數量，提供合理的數量也可以提高性能。可以通過將欄位的數量乘以
1.33 得到近似的最大數量。

注意：
注意，此性能提示不應用於 TypedFML 緩沖區類型。

例如：

如果在 TypedFML32 緩沖區類型中有 50 個欄位，那麼最大數量就是
63。調用構造方法 TypedFML32(63, 50) 比 TypedFML32() 執行得更好。

如果在 TypedFML32 緩沖區類型中有 50 個欄位，並且每個欄位最多可以有
10 個事件，則調用構造方法 TypedFML32(625, 50) 將會有比 TypedFML32() 更好的性能。

當配置 Tuxedo 應用程序（這些應用程序可以作為與 WTC 客戶端互操作的伺服器）時，請考慮平行問題，這一點可以通過在不同 Tuxedo 計算機上仔細配置不同伺服器來實現。
要知道在 Tuxedo 應用程序中可能會存在資料庫訪問死鎖現象。可以通過認真配置 Tuxedo 應用程序來避免死鎖現象。
如果正在使用 WTC 負載平衡或服務級故障轉移，BEA 建議不要禁用 WTC 事務關系。
針對負載平衡出站請求，為導入服務配置使用不同密鑰的多個條目。導入服務將使用復合密鑰來確定每個記錄的唯一性。復合密鑰的構成：服務名稱 + 本地訪問點 + 遠程訪問點列表中的主要路由。
下面是一個如何為 service1 在 TDomainSession(WDOM1,TUXDOM1) 和TDomainSession(WDOM1,TUXDOM2) 之間正確配置負載平衡請求的示例：

ResourceName

LocalAccessPoint

RemoteAccessPointList

RemoteName

service1

WDOM1

TUXDOM1

TOLOWER

service1

WDOM1

TUXDOM2

TOLOWER2

下面是一個錯誤配置負載平衡請求的示例。下面的配置會導致 service1 具有相同的復合密鑰：

ResourceName

LocalAccessPoint

RemoteAccessPointList

RemoteName

service1

WDOM1

TUXDOM1

TOLOWER

service1

WDOM1

TUXDOM1

TOLOWER

在建立連接/會話前更改該會話/連接配置（本地 AP、遠程 AP、密碼和資源）：
接受更改並在新的會話/連接中實現這些更改。

在建立連接/會話後更改該會話/連接配置（本地 AP、遠程 AP、密碼和資源）：
接受更改，但是要到連接斷開並重新連接後，才在現有的連接/會話中實現這些更改。請參閱「管理控制台聯機幫助」中的定位
WTC 服務。

更改導入和導出服務配置：
接受更改並在下一個入站或出站請求中實現這些更改。BEA 建議不要使用此做法，因為這會讓正在進行的請求處於未知狀態。

更改 tBridge 配置：
對已部署的 WTC 服務進行任何更改都會導致異常。在進行任何 tBridge 配置更改前都必須先取消對 WTC 服務的定位。在取消定位和進行配置更改後，必須定位 WTC 服務以便實現更改。

在配置中可以有多種 WTC 服務。
只能將一種 WTC 服務定位到伺服器實例。
WTC 不支持連接緩沖池。WTC 通過單個物理連接多路傳輸請求。
配置更改可按照如下方式實現：

Ⅲ weblogic 如何進行連接回收

一、gc回收 web應用 → 連接池回收
weblogic jconnector Garbage Collector Method:(wls api)
WebLogic Server automatically detects connection leaks by leveraging its Java Virtual Machine
(JVM) garbage collector mechanism. When an application component terminates and the
connections it uses become dereferenced, the garbage collector calls the connection object』s
finalize() method.
When the garbage collector calls the finalize() method, if WebLogic Server determines the
application component has not closed the connection, the server automatically closes the
connection by calling the resource adapter』s ManagedConnection.cleanup() method;
WebLogic Server behaves as it would had it received a CONNECTION_CLOSED event upon proper
closure of the application component connection.
通過JVM垃圾回收機制，wls伺服器能自發探測連接泄露，當應用終止而其所使用的連接變為孤兒時，
垃圾回收器就調用連接對象的finalize方法
垃圾回收器調用finalize方法時，如果wls伺服器確定是應用沒有關閉連接，
wls伺服器將調用資源適配器的ManagedConnection的cleanup方法自動關閉連接，
weblogic伺服器表現得就像它本來應該接收 應用組件連接的其中某個連接上的一個CONNECTION_CLOSED事件

二、程序顯式回收 web應用→連接池
Connection.close()方法調用後，weblogic監控到該動作，由連接池回收並管理連接

三、weblogic的無效鏈接回收
inactive connection timeout 經過設定時間，回收無效鏈接

四、weblogic的連接池自動收縮
Allow Shrinking: 允許自動收縮。如果連接池的初始容量和最大容量不相等，那麼當池中的連接大於初始容量時，經過Shrink Frequency時間，如果連接池中的活動連接不高於初始容量個，那麼連接池中連接的數量會減少到初始容量大。

Ⅳ 我搜索了一些資料，為什麼說Tomcat是一個容器，而weblogic是一個應用伺服器呢他們不都是一個級別的么

應該對你有幫助的!Tomcat是jsp、servlet的容器 WebLogicServer9.x為SOA實現提供了一個完善的企業級基礎 l支持面向服務架構的開發和部署 l通過可靠消息傳遞基礎架構為業務提供事件平台 l通過簡化、可靠的管理功能降低客戶的擁有總成本 l為核心應用提供真正的「零宕機」服務 性能：WLS業界性能評測最好的J2EE伺服器 規范支持： lWLS全面支持J2EE的標准規范和其他標准規范（WebService,SSL,xml等），同時BEA為眾多規范組織的制定者之一，積極參與規范的制定 lTomcat只支持部分J2EE標准，應用局限性強,不能夠安全穩定的支持大並發 技術服務支持： lBEA：完善的售後支持 lTomcat：沒有售後支持 客戶群體： lBEA：全球13000＋企業級用戶的證明 lTomcat：很少企業級用戶 可擴展性 lWLS：集群機制，支持分布式的應用；Tomcat：不支持 可靠性 lWLS：支持Failover；Tomcat：不支持 管理 lWLS：Web控制台進行組件、JDBC、管理和配置；Tomcat：不支持 部署 lWLS：開發模式下，不用重起部署新Web,EJB應用；Tomcat：不支持 開發工具： lWLS：有自己的開發工具Workshop，並且主流IDE支持；Tomcat：沒有自己的開發工具 擴展性 lWLS：可以輕松擴展為支持Portal、Integration的WebLogicPlatform上；Tomcat不支持

求採納

Ⅳ sitescope如何監控

Mercyry SiteScope是一款無代理監測解決方案，可確保分布式IT基礎架構——如伺服器、操作系統、網路設備、網路服務、應用和應用組件的可用性和性能。這款主動的、基於Web界面的基礎架構監測解決方案是非常簡潔的，而且完全根據客戶度身定製，無需在您的上線系統中增加額外的代理。
SiteScope為上線系統提供24×7的監控服務，為維護工程師及時發現問題提供幫助，確保系統架構內一切組建的正常運作。SiteScope在大量增加檢測周期的同時也降低了維護人員的工作成本 。
SiteScope能夠監控UNIX伺服器資源、windows伺服器資源、weblogic應用伺服器、IIS應用伺服器、Oracle資料庫、SQLServer資料庫、F5、URL地址、Ping、內存、CPU、磁碟空間、服務等等系統架構內各種組建的運行狀況；監控器按照指定頻率對目標進行檢測，一旦發現異常會及時向管理員發送意外事件的報警，警報可以通過聲音提醒、email、簡訊等方式發送；另外，SiteScope還可以生成監測活動的匯總報告，該對象從日誌文件中讀取歷史信息，接著總結、篩選信息，並生成圖表格式的報告。 SiteScope常用監控器配置說明： 一、輸入license
在SiteScope樹下Preferences—General Preferences，輸入許可證號、選項許可證。 二、啟動監控歷史記錄視圖
在SiteScope樹下Preferences—General Preferences，「控制面板監控歷史記錄視圖選項」中選擇。 三、Unix資源監控
1． 首先在Preferences—Unix Remote Preferences 增加要監控的unix伺服器
2． 然後新建unix資源監控器
四、weblogic應用程序伺服器
1．輸入伺服器IP、weblogic應用服務的埠號、登錄weblogic console的用戶名/密碼。
2.從weblogic伺服器的weblogic安裝目錄（如：c:\bea\weblogic81\server\lib）拷貝weblogic.jar到SiteScope伺服器，建立一個單獨的目錄（如：c:\weblogic）存放weblogic.jar.
3.在「WebLogic Jar」文件輸入框輸入weblogic.jar文件所在目錄的全路徑（如：c:\weblogic\weblogic.jar）。
注意：不要把weblogic.jar存放在SiteScope伺服器的\SiteScope\java\lib\ext目錄，如果存放在\SiteScope\java\lib\ext目錄會導致SiteScope運行失敗。
五、監控Oracle資料庫
1． 拷貝 Oracle JDBC database driver 文件 (classes12.zip) 到SiteScope伺服器， <SiteScope install path>\SiteScope\java\lib\ext 目錄下. 不解壓縮文件.拷貝完畢之後停止並重新啟動SiteScope服務.
( classes12.zip 文件可以在oracle安裝目錄下得到<oracle install path> \oracle\ora92\jdbc\lib \classes12.zip)
2． 新建類型為「資料庫查詢」或」oracle資料庫」的監控器，輸入如下圖信息。
資料庫連接Url: jdbc:oracle:[email protected]:1521:etsora9
資料庫驅動程序： oracle.jdbc.driver.OracleDriver （大小寫敏感） 六、使用Oracle Database 9i and 10g 模板

變數「OracleAlertLogPath」路徑，例如： \\200.200.200.166\d$\oracle\admin\etsora9\bmp

變數「OracleListenerLogPath」路徑，例如：\\200.200.200.166\d$\oracle\ora92\network\log

七、監控Sql server
1．Windows Remote Preferences 選項中增加sql server伺服器
2．被監控的sql伺服器必須啟動The Remote Registry 服務

Ⅵ Linux里weblogic服務里 /tmp/watch-smartd -B 佔用99%CPU，求大神什麼解決

我們遇到同樣的問題，貌似是被攻擊了。
與
watch-smartd
進程同在的還有一個 Carbon

Ⅶ weblogic 12C版本 大並發時死機

能把你的配置發上來看看嗎？
懷疑你是單核的CPU

WIN2003.。。我也是2003+weblogic+SLQ 2005 沒有你說的那種問題。。。你說的大並發 是指多少。。。 連接數多少