※ 最新版があります。こちら↓です ※「Redmineチューニングの実際と限界」 ※ http://www.slideshare.net/kakahane/redmine-48214015 MySQL勉強会 in 大阪#5_公開資料 日時： 2013/11/7 19:00～ 場所： 日本オラクル株式会社 西日本支社 参加： http://atnd.org/events/44157 主題：「事例発表：Redmine + MySQL 応答性能の調査結果と対策」 副題： ～ 200万チケット、画面応答100ms/req を想定したチュー ニング ～ 概要： ・ITS(Redmine)の全社適用後4年が経過した。チケット数 は10万を超え、その後も年間36,000件のペースで増加を 続けている。情報システム部門の業務システムとして 国内外へ活用範囲が拡大するなかで、応答性能の低下 対策が喫緊の課題
はい、これは僕がいつも良く見る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
この記事は古くなりました。新しい知見は下記を参照。aoking.hatenablog.jp 概要 全文検索エンジン Solr を使用していて、パフォーマンスチューニングに四苦八苦した話。 ここでは、検索時ではなくドキュメントの追加時についてのチューニングについて記してある。 更新自体は参照に比べて頻度が少ないが、参照はレプリケーションして負荷分散しやすい。 更新は整合性を保つために一台のマスターノードに対して行われるので更新はボトルネックになりやすいのだ。 定期的に IO 負荷が高くなる Solr を使っていると、一時的に猛烈に IO 負荷が高まる時がある。fsync になんと1分以上かかるような、猛烈な負荷だ。 これはインデクスのマージ時に起きる IO 負荷で、巨大なインデクス同士のマージだとその合計サイズ分の IO が発生することで IO 処理が専有されたままになっていた。 インデクス
ApacheにはコンテンツのMIME-typeに応じてフィルターをかけるAddOutputFilterByTypeディレクティブがありますが、Apache 2.1 以降で非推奨になり、代わりにmod_filterでフィルターをかけることが勧められているようです。 しかしながら、mod_filterの実例があまりにも少ないため、どう使っていいか分からないのが現状です。なので、AddOutputFilterByType DEFLATE text/htmlを書き換えてみることにしました。 mod_deflateのドキュメントには、実例として画像以外をすべて圧縮する方法が以下のように書かれています。 <Location /> # Insert filter SetOutputFilter DEFLATE # Netscape 4.x has some problems... BrowserMatc
KLab Advent Calendar 2011 「DSAS for Social を支える技術」の9日目です。 前回は php を動かしている Apache の手前にリバースプロキシを 置く必要性を解説しました。 今日は、 その前の php のプロセス数を絞る設定と合わせて、実際に Apache で 設定する方法を紹介します。 以降、 php を動かしている Apache の事をアプリサーバー、リバースプロキシ＋ 静的ファイル配信を行っている Apache の事をプロキシサーバーと呼びます。 基本設定 まずは基本的な設定のおさらいです。 アプリサーバー 並列数を絞るには MaxClients を設定します。アプリがどれくらいの時間を CPUの処理で使って、どのくらいの時間を外部リソース待ちに使っているかにも よりますが、だいたいCPU数の1.5倍〜2倍くらいが適当だと思います。 Hyp
SSL アクセラレータの価格に胃を痛めている貴兄、それが買えず SSL のためだけにサーバの台数をニョキニョキ増やしている貴兄、そうでなくとも SSL のパフォーマンスでお嘆きの貴兄のために、いろいろまとめてみましたよ。 SSLセッションキャッシュのタイムアウト設定を長くしよう SSL の負荷のほとんどはセッションの生成によるものなので、当然のようにサーバ側の SSL セッションキャッシュを有効にしておられると思いますが、そのタイムアウトの設定がデフォルトのままという方が多いのではないでしょうか。 たとえばApacheでしたら、設定サンプルのまま SSLSessionCache shm:/usr/local/apache/logs/ssl_gcache_data(512000) SSLSessionCacheTimeout 300 としている方が多いのではないでしょうか。 各サーバのデフォ
kazuhoさんが「プロのサーバ管理者の間では存在価値が疑問視されて久しい (Min|Max)SpareServers だと思う」と書いたり、hirose31さんが去年のYAPC::Asiaで{Start,{Min,Max}Spare}Servers,MaxClientsは同じにしているよと発表したり、実際前職のサーバはそのように設定されていたのですが、自分でうまく説明ができてなかったので、調べながら書いてみた。 本当はイントラブログ用に書いていたものですが、がんばったので転載。 前提として、CPUの使用率におけるsystemとfork Re: クラウドがネットワークゲーム開発者にもたらしてくれたもの - blog.nomadscafe.jpでも書いている通りforkってのはサーバにとって重い部類の処理になります。つまり負荷の高いときにforkを大量に行うのはしてはならないことの１つです。
MySQLでテーブルへのカラム追加、インデックス追加やテーブルの再編成などを行うと、その間テーブルに共有ロックがかかってしまいます。そのためこれらのメンテナンス処理は、通常利用者の少ない深夜早朝帯にサービスを止めて実施する必要があります。本日はそれを無停止、オンラインのままでできないかという話題です。 基本的なアイデア メンテナンス対象の元テーブルをコピーして、作業用の仮テーブルを作ります 仮テーブルに対して、カラム追加などの変更を加えます その間、元テーブルに対して行われる更新処理について差分を記録しておきます 仮テーブルの変更が終わったら、記録しておいた差分データを仮テーブルに反映します 差分データの反映が終わったら、元テーブルと仮テーブルを入れ替えます これと似たようなことを考えた方は結構いらっしゃるのではないでしょうか。ただ、言うは易し、行うは難しです。整合性がきちんと取れるかどう
11月25日、「mobidec 2011」においてコナミデジタルエンタテインメントのスタジオITセンター長である正延光弘氏によるセッション「大ヒットSNSゲーム『ドラゴンコレクション』を支えるコナミのクラウド技術の活用」が行われました。 ドラゴンコレクションは、GREEで提供されている携帯電話向けのカードゲームタイプのRPG。プレイヤーは、エリアごとにある複数のクエストをクリアしていき、モンスターカードや「秘宝」を手に入れ、さらに「ドラゴンカード」を集めていきます。また、ほかのプレイヤーとバトルすることでも秘宝を入手できるというSNS要素も取り入れられていました。2010年9月のサービス開始後、順調にプレイヤー数を伸ばし、現在では登録人数が500万人を超えています。 サービス開始当初は社内でサーバを構築し、フロントエンドに6台のサーバ、バックエンドに3台のデータベースサーバ、そしてロードバ
InnoDB Pluginの面白い機能の一つに、データ圧縮機能があります。今回はその仕組みと効果について見ていきたいと思います。まずはグラフをご覧ください。 これはWikipedia日本語版のデータベースをダウンロードし、記事本文の格納されているtextテーブルをMySQL 5.1＋InnoDB Plugin 1.0の環境にロードしたものです。 元テキスト：今回利用したデータは2009/06/21版のものです(jawiki-20090621-pages-articles.xml.bz2)。元テキストはここからXml2sqlを用いてタブ区切りテキストを取り出したものを用いています。このファイルには1,167,411件の記事が格納されており、容量は3,436MBとなっています。 元テキスト gzip：元テキストをgzipコマンドで圧縮したものです。 MyISAM：記事をMyISAMのテーブルに
MySQL 5.1からデフォルトで有効になっている便利な機能としてプロファイリングというものがある。MySQL 5.0でも利用出来たのだが、実験的な機能という位置づけであり、搭載されていたのはGPL版のMySQL Community Server限定だった。MySQL 5.1からは全てのエディションでプロファイリングを利用することができる。 プロファイリング機能を利用すると、クエリの状態（特に状態遷移やリソースの消費状況）を詳細に分析できるのでとても便利だ。MySQLエンジニア必携の機能といって良いだろう。というわけでプロファイリング機能の使い方を説明しよう。 MySQLサーバにログインしたら、まずは次のようにしてプロファイリングを有効にする。 mysql> SET profiling=1; すると、クエリの情報が記録されるようになる。次に、分析したいクエリを実行する。クエリはなんでもいい
以前にも書きましたが私は某ポータルサイトのシスアド、兼プログラマをしています。月々１億から３億ページビューを裁いていますが、システムの一番大きなコストはトラフィックです。 100MBit専有とまでなると月４０万は軽く行きます。そこでとにかくページビューをあげながらもトラフィックを減らそうと日々努力しています。この記事の目的はハウジングサービスからアマゾンのクラウドフロントに移行した成功例（または失敗例）について書いていきます。 まず、第一回は既存のシステム（静的ファイル用のサーバ）について簡単に説明します。長年、経験を積みながら行った設定です。あくまでも、サーバのスペック、サイトの用途によっても違ってきます。 OS： Gentoo HTTP Server： 最近lighttpdからまたApacheへ ※lighttpdはものすごくライトウェイトだが、バグの対応が遅い、ガンバレMade
さくらVPSで6万PV程度のサイトを運用することになったので、その際の記録を残しておきます。 さくらレンタルサーバ⇒さくらVPS さくらレンタルサーバで運用している時は、ちょくちょく503が発生しておりこれを解決するためにさくらVPSへの移行を行いました。 レンタルサーバの時は、ログ解析や監視ツールなどを導入していなかったので503の頻度やパターンは不明です。（安易な判断でVPSに移行したので、この点は反省です） 本来は原因を追及し、プログラムの改修やサーバ負荷の分散などをすべきですが時間の都合で省いてしまいました。 構成 運用するサイトはpukiwikiで構成されたサイトです。 pukiwikiは、PHPで書かれており大量のデータをRDBを利用せずに構築できる点が大きなメリットです。 今回は１サイトですが、複数のサイトを運用する可能性を考慮してVirtualHostも利用します。 さくら
以下のテストのほとんどは、MySQL ベンチマークを使用した Linux で実行されていますが、これ以外のオペレーティングシステムおよびワークロードに対しても一定の指針になります。 -staticとリンクした場合に最速のバイナリが得られます。 Linux 上では、pgccおよび -O3でコンパイルした場合に最速のコードが得られます。これらのオプションで sql_yacc.ccをコンパイルする場合は、gcc/pgccで関数のすべてをインラインにする際に大量のメモリが要求されるため約 200M のメモリが必要です。MySQL のコンフィギャ時に CXX=gcc も設定して、libstdc++ライブラリ（これは不要です）が含まれないようにします。pgccの一部のバージョンでは、生成されたコードを x586 タイプのプロセッサ（AMD など）すべてで動作可能にするコンパイラオプションを使用しても、
連休中はWiiのマリオカートをやりまくってやっとVR7000越えたmikioです。愛車はマッハ・バイクとインターセプターです。さて今回は、分散ハッシュデータベースサーバTokyo Tyrantでmixiの最終ログイン時刻を管理するようにした時の苦労話を書きます。 ログイン処理は負荷地獄 mixiでは、全てのユーザについて、各々の最終ログイン時刻を管理しています。「マイミクシィ一覧」や「お気に入り」などの画面で、友人が近い時間にログインしていてコミュニケーションがとりやすい状態にあるかどうか確認できるようにするためです。 mixiのほぼ全てのページはログインしないと見られないページなので、ほぼ全てのページにアクセスされるたびにログイン確認が行われます。したがって、最終ログイン時刻はほぼ全てのページにアクセスされる度に更新されることになります。mixiの中で最も重いデータベースのひとつとして「
株式会社ミクシィ 研究開発グループの前坂です。前回の記事でmemcachedは分散に長けた高速なキャッシュサーバであることが紹介されました。今回はmemcachedの内部構造がどう実装されているのか、そしてメモリがどう管理されているのかをご紹介します。また、memcachedの内部構造の事情による弱点も紹介します。 メモリを整理して再利用するSlab Allocationメカニズム 昨今のmemcachedはデフォルトでSlab Allocatorというメカニズムを使ってメモリの確保・管理を行っています。このメカニズムが登場する以前のメモリ確保の戦略は、単純にすべてのレコードに対してmallocとfreeを行うといったものでした。しがしながら、このアプローチではメモリにフラグメンテーション（断片化）を発生させてしまい、OSのメモリマネージャに負荷をかけ、最悪の場合だとmemcachedのプ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く