resinのresin.co nf最適化access-log出力ログを調整します.
resinのresin.co nf最適化access-log出力ログを調整します.
作者:lizongbo发表于:00:25.水曜日、2月18 th、2009
著作権声明:任意で転載できます.転載する時は必ずハイパーリンクで文章の原本の出所と作者の情報と著作権の声明を明示してください.
http://618119.com/archives/2009/02/18/135.html
現在のサーバ上のレスポンス.co nfのログ構成は、一般的に以下の通りです.
「stdout-log path=」logs/stdout.logs「timestamp=」[%Y-%m-%d%H:%S]「rollver-size="200 mb"/」
「stder-log path=」love/stder.log「timestamp=」[%Y-%m-%d%H:%M:%S]」rollver-size="200 mb"/]
「access-logs path=」logs/access.logs「rollver-period=」1 D「rollver-size=」200 mb/」
この場合、ログは常にlogs/access.logsのような固定ファイルに出力され、ファイルサイズが200 M未満の場合、reinは先にすべてのログ操作をロックし、ファイルの内容をファイル名のタイムスタンプがあるファイルにコピーし、現在のログファイルの内容をクリアする.
この場合は、ディスクioの操作も多くなりますし、ロック機構によりスレッドがいっぱいになりやすくなり、その結果、レスポンスがwebappによってモニタされ再起動されます.
以前はこの問題が発生した時、簡単にaccess-logsを閉じるだけで周りを回っていましたが、最近はウェブサイトのresinも再起動されました.
webはlvs負荷バランスですので、accesslogsをオフにすることで解決できません.
resinのソースコードの分析を見て、現在の業務の実際の状況に合わせて、ログの構成を調整することによって、時間周期的に切断して問題を解決することができます.
分析と実験を通して、レスポンスの配置を大体において調整しました.
「stdout-log path-format=」logs/stdout.logs.%Y%m"timestamp=""[%Y-%m-%d%H:%M:%S]"rollver-period="1 D"/"
「stder-log path-format=」log/stder.log.%Y%m"timestamp=""[%Y-%m-%d%H:%M:%S]"rollver-period="1 D"/"
「access-logs path-format=」logs/access.logs.Y%m%d_%H"rollver-period="1 h"/"
(デフォルトフォーマットはcombined形式)
上はstdoutとstderを天分にカットします.access.logsは時間単位でカットします.
大体の分析過程:
ピーク時にログがスクロールするとスレッドがロックされます.
JMX監視はスレッドスタックを見ると、多くのスレッドがcomp.caucho.server.log.Access Log.logを実行していることが分かります.
次にAccess Logのロゴ方法を分析します.
見られます
if(_issharedBuffer&!_isAutoFlash){
synchronized(_sharedBurerLock){
この2つのオプションのデフォルト値は、シルバーシェアーdBuffer=true、AutoFush=falseです.
(レスポンス.com nfには対応する属性が設定されていないので、例えば、shared-buffer=「false」aut-flaush=「false」)
この2つの属性は公式文書に直接リストされていません.
http://caucho.com/resin-3.0/config/log.xtp#rollover
(テストしましたが、aut-flush=「true」は設定できません.バッファされていないので、スクロールができると判断していないままファイルに打ち込みました.rollover-sizeはほとんど無効です.)
comp.caucho.vfs.AbstractRollover Log.java中:
prvate static final long DEFAULtml OVERHuCHECKUPERIOD=600 L*1000 L;
privte long(urollover CheckPeriod=DEFAULTU Rollo OVER_CHECKUPERIOD)
スクロールログの検出周期はデフォルトでは10分です.
このパラメータは、resin.co nfで動的に構成されていない.
ファイルが指定されたサイズを超えた後、ログスクロールの方法は、comp.caucho.vfs.AbstractRollover LogのrolloverLogであり、これも同期方法である.
ファイルの内容を実行する操作はmovePathToArchive方法です.
そしてmovePathToArchiveのやり方は:
キーコードは、path.writeToStream(out)とpath.truncate()です.
前の方法は、現在のファイルの内容を読んでからoutに書くということです.
後の方法は、現在のファイルの内容をクリアすることです.
その対応の実現は:
comple.ccaucho.vfs.Pathとcomp.ccaucho.vfs.FilePath.
コード全体の分析から、レスポンスはファイルサイズでログをスクロールした時、現在のファイルが200 Mを超えていることを検出し、バッファをすべて現在のログファイルaccess.logsに書き込んで、access.logの内容を読み出して、access.log.00206.1047のようなファイルに書き込み、書き終わったら、FileOutput Streamのapple falseを利用します.s.logの内容が空です.新しいファイルに内容をコピーしてから、現在のファイルの内容をクリアするのに相当します.
このプロセス全体では、同期されているので、201 Mのログをコピーする際には、スレッドは全部ロックされていますが、この時には大量のユーザーからの要求が殺到しています.jmxスレッドが高すぎて、webapp監視が警告されて、resinが監視されて再開されます.
解決策:
path-format属性を使用して、pathを置換します.
例えば設定:
「access-logs path-format=」logs/access.logs.Y%m%d_%H"rollver-period="1 h"/"
このように1時間ごとに1つのファイルを打って、ログの出力を切り替える時、自動的に切り替えて、もうmovePathToArchive操作を生みません.
jvm.Logにも無くなりました.「Archiving access log to」という日記です.
Stdoutとstderも同様に処理しています.この二つのログがある内はあまり多くないので、天によってスクロールするように配置できます.
stdout-log要素とstder-logsにもpath-format属性があります.
なぜresinがFileのrenameToを使わないのかというと、Javaのioでは、すべてのストリームが閉じられていて、しかもオペレーティングシステムにプログラムがないので、ファイルに引用を持っていない場合、ファイルの名前を変更してやっと成功できます.そして、レンameToはオペレーティングシステムに依存しています.このようなファイルを読み書き操作しています.Resinもこのため、ファイルサイズでスクロールするときは、コピーしたファイルを使って内容をクリアするしかないです.
原文の住所:http://618119.com/archives/2009/02/18/135.html
作者:lizongbo发表于:00:25.水曜日、2月18 th、2009
著作権声明:任意で転載できます.転載する時は必ずハイパーリンクで文章の原本の出所と作者の情報と著作権の声明を明示してください.
http://618119.com/archives/2009/02/18/135.html
現在のサーバ上のレスポンス.co nfのログ構成は、一般的に以下の通りです.
「stdout-log path=」logs/stdout.logs「timestamp=」[%Y-%m-%d%H:%S]「rollver-size="200 mb"/」
「stder-log path=」love/stder.log「timestamp=」[%Y-%m-%d%H:%M:%S]」rollver-size="200 mb"/]
「access-logs path=」logs/access.logs「rollver-period=」1 D「rollver-size=」200 mb/」
この場合、ログは常にlogs/access.logsのような固定ファイルに出力され、ファイルサイズが200 M未満の場合、reinは先にすべてのログ操作をロックし、ファイルの内容をファイル名のタイムスタンプがあるファイルにコピーし、現在のログファイルの内容をクリアする.
この場合は、ディスクioの操作も多くなりますし、ロック機構によりスレッドがいっぱいになりやすくなり、その結果、レスポンスがwebappによってモニタされ再起動されます.
以前はこの問題が発生した時、簡単にaccess-logsを閉じるだけで周りを回っていましたが、最近はウェブサイトのresinも再起動されました.
webはlvs負荷バランスですので、accesslogsをオフにすることで解決できません.
resinのソースコードの分析を見て、現在の業務の実際の状況に合わせて、ログの構成を調整することによって、時間周期的に切断して問題を解決することができます.
分析と実験を通して、レスポンスの配置を大体において調整しました.
「stdout-log path-format=」logs/stdout.logs.%Y%m"timestamp=""[%Y-%m-%d%H:%M:%S]"rollver-period="1 D"/"
「stder-log path-format=」log/stder.log.%Y%m"timestamp=""[%Y-%m-%d%H:%M:%S]"rollver-period="1 D"/"
「access-logs path-format=」logs/access.logs.Y%m%d_%H"rollver-period="1 h"/"
(デフォルトフォーマットはcombined形式)
上はstdoutとstderを天分にカットします.access.logsは時間単位でカットします.
大体の分析過程:
ピーク時にログがスクロールするとスレッドがロックされます.
JMX監視はスレッドスタックを見ると、多くのスレッドがcomp.caucho.server.log.Access Log.logを実行していることが分かります.
==============================
"resin-tcp-connection-*:80-5973" Id=41812 in BLOCKED on lock=java.lang.Object@14dca59
owned by resin-tcp-connection-*:80-5545 Id=41588
at com.caucho.server.log.AccessLog.log(AccessLog.java:310)
at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:206)
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229)
at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:268)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:389)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:507)
at com.caucho.util.ThreadPool.run(ThreadPool.java:433)
at java.lang.Thread.run(Thread.java:619)
次にAccess Logのロゴ方法を分析します.
見られます
if(_issharedBuffer&!_isAutoFlash){
synchronized(_sharedBurerLock){
この2つのオプションのデフォルト値は、シルバーシェアーdBuffer=true、AutoFush=falseです.
(レスポンス.com nfには対応する属性が設定されていないので、例えば、shared-buffer=「false」aut-flaush=「false」)
この2つの属性は公式文書に直接リストされていません.
http://caucho.com/resin-3.0/config/log.xtp#rollover
(テストしましたが、aut-flush=「true」は設定できません.バッファされていないので、スクロールができると判断していないままファイルに打ち込みました.rollover-sizeはほとんど無効です.)
comp.caucho.vfs.AbstractRollover Log.java中:
prvate static final long DEFAULtml OVERHuCHECKUPERIOD=600 L*1000 L;
privte long(urollover CheckPeriod=DEFAULTU Rollo OVER_CHECKUPERIOD)
スクロールログの検出周期はデフォルトでは10分です.
このパラメータは、resin.co nfで動的に構成されていない.
ファイルが指定されたサイズを超えた後、ログスクロールの方法は、comp.caucho.vfs.AbstractRollover LogのrolloverLogであり、これも同期方法である.
ファイルの内容を実行する操作はmovePathToArchive方法です.
そしてmovePathToArchiveのやり方は:
キーコードは、path.writeToStream(out)とpath.truncate()です.
前の方法は、現在のファイルの内容を読んでからoutに書くということです.
後の方法は、現在のファイルの内容をクリアすることです.
その対応の実現は:
comple.ccaucho.vfs.Pathとcomp.ccaucho.vfs.FilePath.
コード全体の分析から、レスポンスはファイルサイズでログをスクロールした時、現在のファイルが200 Mを超えていることを検出し、バッファをすべて現在のログファイルaccess.logsに書き込んで、access.logの内容を読み出して、access.log.00206.1047のようなファイルに書き込み、書き終わったら、FileOutput Streamのapple falseを利用します.s.logの内容が空です.新しいファイルに内容をコピーしてから、現在のファイルの内容をクリアするのに相当します.
このプロセス全体では、同期されているので、201 Mのログをコピーする際には、スレッドは全部ロックされていますが、この時には大量のユーザーからの要求が殺到しています.jmxスレッドが高すぎて、webapp監視が警告されて、resinが監視されて再開されます.
解決策:
path-format属性を使用して、pathを置換します.
例えば設定:
「access-logs path-format=」logs/access.logs.Y%m%d_%H"rollver-period="1 h"/"
このように1時間ごとに1つのファイルを打って、ログの出力を切り替える時、自動的に切り替えて、もうmovePathToArchive操作を生みません.
jvm.Logにも無くなりました.「Archiving access log to」という日記です.
Stdoutとstderも同様に処理しています.この二つのログがある内はあまり多くないので、天によってスクロールするように配置できます.
stdout-log要素とstder-logsにもpath-format属性があります.
なぜresinがFileのrenameToを使わないのかというと、Javaのioでは、すべてのストリームが閉じられていて、しかもオペレーティングシステムにプログラムがないので、ファイルに引用を持っていない場合、ファイルの名前を変更してやっと成功できます.そして、レンameToはオペレーティングシステムに依存しています.このようなファイルを読み書き操作しています.Resinもこのため、ファイルサイズでスクロールするときは、コピーしたファイルを使って内容をクリアするしかないです.
原文の住所:http://618119.com/archives/2009/02/18/135.html