tatamilab.jp
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください! まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
2007/04/27 “twitter”がブームだ。140バイト以内の短いメッセージで“現在進行形”の自分のステータスをほかのユーザーとシェアするだけのオンラインサービスだが、本国の米国はもとより、日本でも非常な人気を集めている。Alexaでアクセス数の推移を調べると、今年に入ってから本格的にブレークしている様子が分かる。4月22日にはニューヨークタイムズもtwitterと、サンフランシスコ在住の創業者2人を記事で取り上げている。 twitterのコミュニケーションツールとしての新しさ twitterに参加してみると、チャットやメール、SNSといった、既存のコミュニケーションツールのいずれとも異なる、不思議なつながり方が新鮮で楽しい。熱心にメッセージを更新するユーザーを見ていると、CUSeeMe、ICQ、mixiなどが登場したときに人々が示した熱狂に近いものを感じる。 twitterでは、
まるごと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
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
インターネット・サービスの激戦区である動画配信で後発ながら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 万クラスのサービスの情報の方が、より現実的で役に立つのではないかと思い、はてなブックマークの裏側に絞って話しをしてみました。 ...という前提で見ていただけると嬉しいです。 はてなブックマークのデータのサイズもかなり大きくなってきたので、ぼちぼちパーテ
初登場になります、酒井といいます。 今回は Six Apart のサービスで使われている MogileFS というファイルシステムを紹介したいと思います。MogileFS については、日本語の情報はあまり…、というかほとんどない状況ですので参考にしていただければと思います。では早速。。。 MogileFS とは MogileFS とは、Perl で記述されているオープンソースな分散ファイルシステムです。 プロジェクトホームページ http://www.danga.com/mogilefs/ メーリングリスト http://lists.danga.com/mailman/listinfo/mogilefs 上記のホームページ内でも紹介されていますが、主に以下のような特徴があります。 アプリケーションレベルでの実装なので特殊なカーネルモジュールいらず。 ファイルを複数ホストに自動コピー / バ
今年も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
こんにちはスエヒロです。 今回は弊社が提供しているブログサービス「nowa」(ノワ http://nowa.jp)の仕組みをサーバ構成を中心に紹介したいと思います。 nowaでは一般的なブログサービス要素とSNS要素の機能を実装しています。弊社には先行して提供している「livedoor Blog」、「フレパ」といった大規模なサービスがありますので、そちらの開発・運用で問題になった点などを参考にしつつ開発を進めています。具体的にはアクセスによる負荷への対策、データベースの分散化、画像のストレージング、冗長性、スケーラビリティといった点になります。 - ポータル(nowa.jp)、CMS(cms.nowa.jp) のサーバ構成 ポータルページ(nowa.jp)とCMSページ(cms.nowa.jp)は、静的なファイルのリクエストを捌く+動的なコンテンツへのリクエストをプロキシするフロントサーバ
_ [ソフトウェア] DB分散の次は非同期処理がウェブアプリのスケーリングのトレンドになる サイボウズも memcached + MySQL DB 分散 Cybozu Developer Network: MySQL Users Conference Japan 2007 講演概要 を読んで、memcached でキャッシュ& 複数の MySQL をアプリのロジックで分散化というのは、もうすっかりスケーラブルなウェブアプリの作り方として常套手段になったと思いました。 2004 年 4 月の MySQL カンファレンスでの Brad Fitzpatrick の発表 Inside LiveJournal's Backend (PDF)から約 3 年半。Mixi やはてなのようなエッジな企業はだいぶ前からこの構成を採用してますが、対法人のビジネスをしているサイボウズでも採用されたというのは一つ
2008-09-27 17:53:11 +0900 (78d); rev 114 この文書について 分散型メモリオブジェクトキャッシングシステムである memcached について、その仕組み、導入やプログラミング言語からの利用方法までを紹介します。 この文章は常に書きかけです。誤字脱字や間違いの指摘や情報提供などを歓迎します。 この文書の対象者 memcached の導入を検討しているひと memcached をプログラミング言語から利用する方法を知りたいひと memcached の仕組みや仕様を知りたいひと 環境について 以下のような環境を想定しています。 UNIX および UNIX ライク OS x86 アーキテクチャ memcached は x86 以外のアーキテクチャでも動作しますが、この文書では x86 前提として記述します。 memcached とは memcached は
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 ]─┤ │ │ │ │ │
RestWiki をたまに見直すと新たな発見があって面白い。 たとえば先日、「ステートレスなやりとりとは何か(What is Stateless Interaction?)」という箇所を見つけて、興味深く読んだ。このページは以前も絶対に読んでいるはずなのだが、 人間は忘れてしまうものである。 RestWiki の例でも充分わかりやすいのだけれど、自分でも例を思いついたので書きとめておく。 ステートフルサーバとステートレスサーバはどう違うのか。 まずは、ステートフルの例: 客: こんにちは 店員: いらっしゃいませ。○○バーガーへようこそ 客: ハンバーガーセットをお願いします 店員: サイドメニューは何になさいますか? 客: ポテトで 店員: ドリンクは何になさいますか? 客: ジンジャーエールで 店員: +50円でドリンクをLサイズにできますがいかがですか? 客: Mでいいです 店員:
4月14日から17日までの4日間、米カリフォルニア州サンタクララにおいて、MySQL Conference and Expo(以下、MySQLカンファレンス)が開催された。MySQL関連の最大のイベントである。セッションは有料で、日本円で10万円を超える金額にもかかわらず、参加登録者数は2,000人近くに達し※、日本からも多くのユーザーが参加していた。 ※ セッション参加のできない、展示会場のみの申し込み者も含む。 今回のMySQLカンファレンスでは、複数データセンターにまたがってMySQLを活用するような大規模事例、ペタバイト級の規模に挑戦する事例、MySQL Clusterの事例、Heartbeat + DRBDによる高可用性の事例など、さまざまな事例が発表された。とくにFacebookは、1万台のWebサーバ、800台のキャッシュサーバ(memcached)、そして1,800台のMy
Webサーバの負荷を軽減する方法として、リバースプロキシによる代行とロードバランサによる分散が考えられる。今回は、これらによる負荷の低減方法について解説する。(編集部) Apache自体のチューニングによる性能向上には限界があります。よりパフォーマンスを求めるなら、次にやるべきことはメモリの追加や高性能なCPUへの交換など、ハードウェアの見直しです。しかし、それにも限界があります。 リバースプロキシとロードバランサ ハードウェア単体による性能向上が限界に達した場合は、サーバ構成の見直しを行います。まず考えられるのが、リバースプロキシをWebサーバの前面に立ててクライアントからのアクセスを肩代わりさせる方法です。Webサーバがボトルネックになるのを防ぐとともに、セキュリティ向上にも寄与します。 もう1つの方法は、より高可用性を意図した構成として負荷の分散を図ることです。高可用性とは、サーバの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く