apacheのpreforkについて
http://blog.csdn.net/marcolu/archive/2004/08/02/59085.aspx
よく使われているのは3つだけです.ウォーカーprefork 124 perchild.
1.prefork:機能的にはApacheの運転方式を使って、親プロセスを一つ作って、設定と接続状況によって、対応するサブルーチン数を生成します.このモードは信頼性とロバスト性が一番良い.しかし、性能上、費用がかかりすぎます.私達のこれらの“吸血鬼”の要求に達しられませんでした.もし接続数が多すぎると、長距離登録ができなくなります.接続数が下がってから接続できるようにしなければならないです.これも一番困ることです.
2.ウォーカー:ハイブリッドスレッド/プロセスのMPM.親プロセスの後にスレッドが付いた子プロセスがあります.各サブプロセスのスレッド数は固定で同じです.これは一番「凡庸」なパターンですが、一番多くの人を使うパターンです.性能など各方面でバランスが取れているからです.性能的にはpreforkよりも若干良く、わずかな頑丈さと信頼性を犠牲にしただけです.一般的にこのオプションがオススメです.
3.perchild:ハイブリッドスレッド/プロセスのMPMです.perchild MPMが起動されると、指定された数のサブルーチンが確立され、各サブルーチンは指定された数のスレッドを持ち、負荷が増加した場合、新しいプロセス(サブルーチンは固定されています)は作成されません.もう一つの特徴は、各サブプロセスのために異なるユーザーとグループを配置できることです.仮想ホストごとにサブプロセスを指定することもできます.このモード性能は最適であるが,信頼性とロバスト性は相対的に最悪である.個人的にはこのようなモデルもいいと思いますが、第三者のモジュールを使わないと^u^.
http://blog.csdn.net/tingya/archive/2006/08/09/1040799.aspx
http://blog.csdn.net/tingya/archive/2006/08/28/1133825.aspx
http://blog.csdn.net/tingya/archive/2006/08/28/1133836.aspx
ApacheでPreforking MPMメカニズムの分析を事前に作成します.
http://ldgliguang.blog.163.com/blog/static/81845820074101133992/
ここでこのような説明を見ました.
MaxRequests PerChildを非ゼロに設定することは、2つの利点があります.
1.メモリの漏洩を無限に防ぐことができ、メモリを使い果たします.
2.プロセスに有限寿命を与え、サーバーの負荷が軽減されると活動プロセスの数を減らすのに役立ちます.
http://blog.codingnow.com/2007/05/good_design.
またここで見ました.「ユニクス痛恨者マニュアル」には一言があります.
「コントロールプロセスの発生と終止によってメモリ管理を行うことは、人間の生死をコントロールすることによって疾病に対処するようなものである」
先駆的モデルにはロバスト性や信頼性などのいくつかの利点がある.サブプロセスが異常に終了すると、サーバーは接続をなくし、一つの接続だけが失われます.サーバの残りの部分はまだ動作を継続し、要求にサービスを提供することができる.唯一、問題が発生したことに気づいたユーザは、不幸にも問題を引き起こして要求したユーザである.
しかし、先導モデルは拡張性などの自分の欠点もあります.
この設計の最後の問題は、いくつかの最適化を弱めることです.各要求は自分のプロセスで実行されますので、プロセス間の情報共有は難しいです.
http://archive.netbsd.se/?ml=apache-httpd-dev&a=2004-02&t=44730
hmmm、looks like the httpd parent is trying to shut down a child process gracefully after a decrease in trffic.
write(6)「!」,1)means it's using the pipe of death. Since waitpid()is returning 0,it look s the child processes are't reponding to the pipe of death. Could it be that network traffic is totally dried up during these periods?or could the child processes be in the middle of some long running request?
Could it be that network traffic is totally dried up during these periods?or could the child processes be in the middle of some long running request?
この二つの点から見ると、parent write(6、「!」、1)の後、childは一つの要求があってからこのニュースを知る必要があります.childはidleにいる時、あるべきです.
http://www.webmonkey.com/webmonkey/97/49/index3a_page 4.html?tw=backend
This effectively locks those children into serving requests from that one socket and no other sockets,and they'll be stuck there until enough new requests appar on that socket to wake them alup.
よく使われているのは3つだけです.ウォーカーprefork 124 perchild.
1.prefork:機能的にはApacheの運転方式を使って、親プロセスを一つ作って、設定と接続状況によって、対応するサブルーチン数を生成します.このモードは信頼性とロバスト性が一番良い.しかし、性能上、費用がかかりすぎます.私達のこれらの“吸血鬼”の要求に達しられませんでした.もし接続数が多すぎると、長距離登録ができなくなります.接続数が下がってから接続できるようにしなければならないです.これも一番困ることです.
2.ウォーカー:ハイブリッドスレッド/プロセスのMPM.親プロセスの後にスレッドが付いた子プロセスがあります.各サブプロセスのスレッド数は固定で同じです.これは一番「凡庸」なパターンですが、一番多くの人を使うパターンです.性能など各方面でバランスが取れているからです.性能的にはpreforkよりも若干良く、わずかな頑丈さと信頼性を犠牲にしただけです.一般的にこのオプションがオススメです.
3.perchild:ハイブリッドスレッド/プロセスのMPMです.perchild MPMが起動されると、指定された数のサブルーチンが確立され、各サブルーチンは指定された数のスレッドを持ち、負荷が増加した場合、新しいプロセス(サブルーチンは固定されています)は作成されません.もう一つの特徴は、各サブプロセスのために異なるユーザーとグループを配置できることです.仮想ホストごとにサブプロセスを指定することもできます.このモード性能は最適であるが,信頼性とロバスト性は相対的に最悪である.個人的にはこのようなモデルもいいと思いますが、第三者のモジュールを使わないと^u^.
http://blog.csdn.net/tingya/archive/2006/08/09/1040799.aspx
http://blog.csdn.net/tingya/archive/2006/08/28/1133825.aspx
http://blog.csdn.net/tingya/archive/2006/08/28/1133836.aspx
ApacheでPreforking MPMメカニズムの分析を事前に作成します.
http://ldgliguang.blog.163.com/blog/static/81845820074101133992/
ここでこのような説明を見ました.
MaxRequests PerChildを非ゼロに設定することは、2つの利点があります.
1.メモリの漏洩を無限に防ぐことができ、メモリを使い果たします.
2.プロセスに有限寿命を与え、サーバーの負荷が軽減されると活動プロセスの数を減らすのに役立ちます.
http://blog.codingnow.com/2007/05/good_design.
またここで見ました.「ユニクス痛恨者マニュアル」には一言があります.
「コントロールプロセスの発生と終止によってメモリ管理を行うことは、人間の生死をコントロールすることによって疾病に対処するようなものである」
先駆的モデルにはロバスト性や信頼性などのいくつかの利点がある.サブプロセスが異常に終了すると、サーバーは接続をなくし、一つの接続だけが失われます.サーバの残りの部分はまだ動作を継続し、要求にサービスを提供することができる.唯一、問題が発生したことに気づいたユーザは、不幸にも問題を引き起こして要求したユーザである.
しかし、先導モデルは拡張性などの自分の欠点もあります.
この設計の最後の問題は、いくつかの最適化を弱めることです.各要求は自分のプロセスで実行されますので、プロセス間の情報共有は難しいです.
http://archive.netbsd.se/?ml=apache-httpd-dev&a=2004-02&t=44730
hmmm、looks like the httpd parent is trying to shut down a child process gracefully after a decrease in trffic.
write(6)「!」,1)means it's using the pipe of death. Since waitpid()is returning 0,it look s the child processes are't reponding to the pipe of death. Could it be that network traffic is totally dried up during these periods?or could the child processes be in the middle of some long running request?
Could it be that network traffic is totally dried up during these periods?or could the child processes be in the middle of some long running request?
この二つの点から見ると、parent write(6、「!」、1)の後、childは一つの要求があってからこのニュースを知る必要があります.childはidleにいる時、あるべきです.
accept_mutex_on();
accept();
accept_mutex_off();
http://www.webmonkey.com/webmonkey/97/49/index3a_page 4.html?tw=backend
This effectively locks those children into serving requests from that one socket and no other sockets,and they'll be stuck there until enough new requests appar on that socket to wake them alup.