MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください！ まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in

まるごとPerl! Vol.1 で執筆させていただいたはてなブックマークのシステムに関する記事が ThinkIT で読めるようになりました。記事全体を何回かにわけて掲載していただいています。まるごとPerlの記事なのですが、実は Perl のことはあまり触れていなくてはてなのサーバー運用概論みたいは話が主なところです。 http://www.thinkit.co.jp/free/article/0610/1/1/ http://www.thinkit.co.jp/free/article/0610/1/2/ せっかくなので現状報告も含めて少し補足をしてみようかなと思います。 現在の数字 記事の中での数字は6月のもので ユーザー：45,000人 ブックマーク数：535万件 ページビュー：5,000万/月 サーバー：17台 となってますが、現在 10 月の方はというと ユーザー: 60,000

インターネット・サービスの激戦区である動画配信で後発ながらYouTubeを上回る成長速度，YouTubeの3倍以上となる1日ひとり3時間以上という平均視聴時間を実現したニコニコ動画。開設後1年足らずで400万人の会員を獲得，日本全体のトラフィックの約10分の1を占める。その成長速度はmixiも上回り，日本史上最速と見られる。 ニコニコ動画は多くのメディアで語られ，2007年10月にはグッドデザイン賞も獲得したが，これまでは社会現象やマーケティングの観点から語られることが多かった。しかしニコニコ動画を作り上げ，その急拡大を支えたのはまぎれもなくエンジニアの技術だ。多くのクリエイタやユーザーを魅了し，巨大なアクセスをさばく技術はどのようなものなのか。ドワンゴのエンジニアに聞いた。 「感情」を共有するアルゴリズム 動画の上に文字をかぶせるサービスはニコニコ動画以前にも存在した。また，動画のタイミ

以下に置いておきました。遅くなってすいません。 http://bloghackers.net/~naoya/pdf/050404inside_hatena_bookmark.pdf 会場で前置きしたように、はてなブックマークは、はてなで一番大きなシステムであるはてなダイアリーあるいは同じ YAPC で発表のあった mixi に比べると、まだそこまで大きな規模ではありません。月間の PV はだいたい 4,000 万 PV 〜 というところです。 ただ、日本でのトラフィックが上から 5 番目みたいな怪物サイトよりも、月間の PV が 1,000 万クラスのサービスの情報の方が、より現実的で役に立つのではないかと思い、はてなブックマークの裏側に絞って話しをしてみました。 ...という前提で見ていただけると嬉しいです。 はてなブックマークのデータのサイズもかなり大きくなってきたので、ぼちぼちパーテ

今年もMySQL Conference 2008に行ってきました。社内向けの報告資料と雑多なメモですが、よろしければ参考にしてください。 *1 概要 MySQLがSunに買収されて始めてのConference 8セッション並列で、OSCONの規模にだいぶ近い MySQLが扱うトラフィック量・データ量がどんどん大きくなってきており、それにどう追従するか、という観点の話が多い 買収の話とか "MySQL、新機能追加は有償版の「MySQL Enterprise」だけを対象に"というのは、かなりミスリーディングな記事 実体は一部のセキュリティ形の機能やnative storage engine-specific driverをMySQL Enterpriseとして出す、という話 Backup機能や、Falcon, Mariaといったストレージエンジンの開発では、Community ServerとE

HOMMEZ(オムズ)はすべての男性の悩みに寄り添い、心と身体の健康を支援し、男性としての喜びを享受できる社会を目指しています。人には相談しづらいAGA、ダイエット、ED、妊活にまつわる男性特有の悩みに対し、情報やソリューションを提供することで男性が前向きに自分らしく生きられる幸せを実現します。

mod_rewriteでサーバーの負荷が高いときだけリダイレクトする ワタシが働いている会社のホームページは、たまーにYahooのトピックスからリンクされます。 トピックスに載るとそれはもう大量のアクセスが津波のように押し寄せてきて、あっというまにサーバーのリソースを食いつぶしてアクセス不能になってしまいます。 こういうときのために、Contents Delivery Networkによるキャッシングも利用してます。 今までは、リンクされそうになったらmod_rewriteでリダイレクトって方法を使っていました。 でも毎回これをやるのが面倒になってきたので、なんとかならんかなーと思って、RewriteMapに初挑戦してみた。 RewriteMap使えばRewriteCondとかRewriteRuleにプログラムの出力結果を使うことが出来るようになるので、これでWebサーバーのロードアベレー

DSASはいかにして可用性を高めているか、ちょっと紹介したいと思います。 今回は概略ということでざざざっと説明します。個別の構成についてはまた回を改めて紹介したいと思います。 │ │ ┌┴┐ ┌┴┐ │ │ │ │ISPの上位ルータ └┬┘ └┬┘ │ │ 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 責任分解点 │ │ ┌┴┐ ┌┴┐ │ ├─[ lb(active) ]─┤ │ │ ├─[ lb(backup) ]─┤ │ │ │ │ │ │L2├─[ Web ]─┤L2│ │SW├─[ Web ]─┤SW│ │ ├─[ Web ]─┤ │ │ │ │ │ │ ├─[ SMTP ]─┤ │ │ ├─[ SMTP ]─┤ │ │ │ │ │ │ ├─[ D B ]─┤ │ │ ├─[ D B ]─┤ │ │ │ │ │ │ ├─[ NFS ]─┤ │ │ ├─[ NFS ]─┤ │ │ │ │ │

Webサーバの負荷を軽減する方法として、リバースプロキシによる代行とロードバランサによる分散が考えられる。今回は、これらによる負荷の低減方法について解説する。（編集部） Apache自体のチューニングによる性能向上には限界があります。よりパフォーマンスを求めるなら、次にやるべきことはメモリの追加や高性能なCPUへの交換など、ハードウェアの見直しです。しかし、それにも限界があります。 リバースプロキシとロードバランサ ハードウェア単体による性能向上が限界に達した場合は、サーバ構成の見直しを行います。まず考えられるのが、リバースプロキシをWebサーバの前面に立ててクライアントからのアクセスを肩代わりさせる方法です。Webサーバがボトルネックになるのを防ぐとともに、セキュリティ向上にも寄与します。 もう1つの方法は、より高可用性を意図した構成として負荷の分散を図ることです。高可用性とは、サーバの