某所の"munin"がびっくりするくらい画面表示が重くなっていて、ひょんなことから改善することになった話。 前提条件として、このmuninが動いているサーバは数百台のノード(サーバ)を管理している状態で、muninのバージョンは2.0系でした。 本当は、後学のためにも作ってくれた人に直してもらうべきと思いつつ、あまり悠長なことも言ってられない感じだったので、一人チューニンガソンを敢行。・・・要望があったのでログを残しておきます。(遅くなってごめんなさい) 最初の状態(before) まず、muninのトップページですが、開いてみると、、、 うほっ、19.61秒かかっておりました。これはなかなかのストレスです。 特にHTML部分の出力に19.4秒かかっている。ここをなんとかせねばなるまい。 次に4台分のサーバの各リソースの負荷状況が確認できるページを表示してみると ズラズラと出ております。各
はい、これは僕がいつも良く見るApacheとNginxの性能差に見えます。大体、ApacheはNginxの75%程度の性能に落ち着きます。数十バイトの静的コンテンツに対するリクエスト処理はNginxの得意分野だと思っていたので、大体こんなものです。 そこで、真面目にevent_mpmのチューニングを行ってみました。で、幾度となくベンチを試した結果導き出した、静的コンテンツに対する同時接続数100程度に対して最高のパフォーマンスを示すevent_mpmの設定は以下のようになりました。 [program lang=’apache’ escaped=’true’] StartServers 4 MinSpareThreads 4 MaxSpareThreads 4 ThreadsPerChild 2 MaxRequestWorkers 2 MaxConnectionsPerChild 0 [/p
nginxやvarnishなどがアツいですが、Apacheもまだまだ実績や安定性から採用されていると思います。ここではデフォルトとは異なる値に変更するサーバ設定を中心に、パフォーマンス改善、安全性向上のためのApacheの設定を紹介します。 mpmの確認 > /path/to/bin/httpd -V Server version: Apache/2.2.19 (Unix) Server built: Jun 23 2011 17:13:13 Server's Module Magic Number: 20051115:28 Server loaded: APR 1.4.5, APR-Util 1.3.12 Compiled using: APR 1.4.5, APR-Util 1.3.12 Architecture: 64-bit Server MPM: Worker PreforkやW
この記事は古くなりました。新しい知見は下記を参照。aoking.hatenablog.jp 概要 全文検索エンジン Solr を使用していて、パフォーマンスチューニングに四苦八苦した話。 ここでは、検索時ではなくドキュメントの追加時についてのチューニングについて記してある。 更新自体は参照に比べて頻度が少ないが、参照はレプリケーションして負荷分散しやすい。 更新は整合性を保つために一台のマスターノードに対して行われるので更新はボトルネックになりやすいのだ。 定期的に IO 負荷が高くなる Solr を使っていると、一時的に猛烈に IO 負荷が高まる時がある。fsync になんと1分以上かかるような、猛烈な負荷だ。 これはインデクスのマージ時に起きる IO 負荷で、巨大なインデクス同士のマージだとその合計サイズ分の IO が発生することで IO 処理が専有されたままになっていた。 インデクス
地味に色々と調整しているのでまとめておきます。見よう見まねの継ぎ接ぎばかりですが…。 AutoPatchWorkはwedata(About - wedata)のAutoPagerize用SITEINFOを使わせて頂いていますが、wedataのサーバーは負荷に弱いので、SITEINFOは自前のサーバー(といっても安心のhetemlですが)に置いています。 hetemlサーバーでcronを設定して1時間に1回、SITEINFOを更新するようにしていて、AutoPatchWorkユーザーは一日に1回hetemlサーバーからSITEINFOを取得しています。 ただ、AutoPagerizeのSITEINFOは2MB近くあるので、1万人が毎日アクセスしたら転送量が20GBに達します(全員が毎日更新にくるわけではないので、実際はもっと少ないですが)。hetemlの転送量は「目安として 1日 20GB
Rails運用時で気になるのは、安定性とパフォーマンス。安定性はいろいろ負荷テストをして時間が経たないと分からないので、まずはメモリのパフォーマンスから調べてみます。 とりあえず、ちょっとしたサンプルをmongrelで動かしてみると、44Mほどメモリを確保しています。 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND 1003 14412 0.0 2.2 44316 23556 ? Sl Apr10 0:01 /usr/bin/ruby1.8 /var/lib/gems/1.8/bin/mongrel_rails start んで、同じプロセスをmod_rails(passenger)で起動すると、143Mほど確保されます。 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAN
先日、Web サーバ勉強会 #2 が開かれました。内容は、Apache のチューニングということで、参加したかったのですが、他の予定があって参加できませんでした。 そこで、僕が個人的に行っている Apache のチューニングを紹介したいと思います。最初、スライドで作成しようかと思ったのですが、ブログにまとめたほうがよさそうなのでブログにまとめていきます。 まず、大前提として Apache をチューニングするうえで、大事なことはその Apache が提供する Web サービスの種類のよって大きくチューニングする内容が異なるということです。例えば、動画・写真共有サービスと株価情報のサービスを比較すると、当然のことながら大きくサービスの内容が異なりますし、HTTP レベルでみるとクライアントからのリクエスト数、データサイズ、などがかなり違ってきます。 ですので、まずは自分が扱っているウェブサービ
kazuhoさんが「プロのサーバ管理者の間では存在価値が疑問視されて久しい (Min|Max)SpareServers だと思う」と書いたり、hirose31さんが去年のYAPC::Asiaで{Start,{Min,Max}Spare}Servers,MaxClientsは同じにしているよと発表したり、実際前職のサーバはそのように設定されていたのですが、自分でうまく説明ができてなかったので、調べながら書いてみた。 本当はイントラブログ用に書いていたものですが、がんばったので転載。 前提として、CPUの使用率におけるsystemとfork Re: クラウドがネットワークゲーム開発者にもたらしてくれたもの - blog.nomadscafe.jpでも書いている通りforkってのはサーバにとって重い部類の処理になります。つまり負荷の高いときにforkを大量に行うのはしてはならないことの１つです。
accessibility 10 advanced 195 AMP 13 Android 2 API 7 apps 7 autocomplete 2 beginner 173 CAPTCHA 1 Chrome 2 cms 1 crawling and indexing 158 encryption 3 events 51 feedback and communication 83 forums 5 general tips 90 geotargeting 1 Google Assistant 3 Google I/O 3 Google Images 3 Google News 2 hacked sites 12 hangout 2 hreflang 3 https 5 images 12 intermediate 205 interstitials 1 javascript 8 job s
PHPを使う場合Apacheとnginxどっち使えばいいん？と気になったのでパフォーマンス比較してみました こんな感じの構成で すべて仮想サーバ構成です 負荷元サーバー CPU=2 RAM=1000M がんばるサーバ CPU=4 RAM=1024M DBサーバ CPU=4 RAM=1536MB 使ったミドルウェア Apache 2.2.3 Nginx 0.7.64 PHP 5.3.1 （子プロセス=6 tcp接続） MySQL 5.5.1 spawn-fcgi 1.4.22 wordpress 2.9.1 早速基礎体力というか通常の戦闘力を測ってみます abで多重度1で100回リクエストしてみます 公平を期すために二回目の結果をとっています ab -c 1 -n 100 -H "Host: blog.xcir.net" http://192.168.1.123:82/
期せずして久々の更新になってしまった。ブログを書く気がなくなったとかそういうのではなくてただ単に忙しかっただけ。その間、まぁ仕事が予期せぬ方向から炎上してみたり、事故をもらって愛車が全損したり（フロントガラスが全面熱線入りなんていう変なオプションなどを諸々付けていたからお気に入りだったのに）と決して良いことばかりで忙しかったわけではないけどね！ で、今回は node.js のお話。異様な盛り上がりを見せているものの、じゃぁそれっていったい何かというと「JavaScriptを用いたNon-blocking I/O環境」という非常にシンプルなものだ。 その根底には「うまくスケールできること」と「動作が速いこと」という理念が見受けられる。 まず「うまくスケールできること（多量のアクセスを捌けること）」を解決するにあたり、まずはスレッドモデルか、イベントループかという問題があった。そこで auth
これまでprefork MPMで使っていたApacheを、負荷増加のためworker化することにした。(MPMについては以前のブログ)で紹介した。そんなわけでhttpd.confのMPMに関する設定値を再検討することになったわけだが、ServerLimitのディレクティブのMPMにより違いをうっすらとしか覚えていなかったのでもう一度調べてみた。 prefork MPM の場合 ServerLimitはApacheプロセス稼働中におけるMaxClientsに設定可能な上限値を設定する。これは、preforkの場合は「同時クライアント数 = サーバプロセス数」になるため。 prefork MPM では、MaxClientsを256 (デフォルト) よりも大きな値に設定する必要がある時にだけ使用する。 希望の MaxClients数とくらべて、必要以上に大きな値を指定することは避ける。 work
参考. http://www.typemiss.net/blog/kounoike/20060202-61 http://d.hatena.ne.jp/babie/20060201/p3 http://yutuki.blogspot.com/2007/08/apache-maxclients.html http://d.hatena.ne.jp/hideden/20080409/1207740439 わけあってMaxClientsの設定を色々調べました。初っ端から言い訳ですが勉強中なので、あまり鵜呑みにしないでください。 追記 topのSHRの項目が共有メモリサイズだと思ってたけど、naoyaさんのblogによると違うらしい。 http://d.hatena.ne.jp/naoya/20080212/1202830671 なので↓に出てくるtopのSHMを使っている計算は間違ってる模様。同
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
