ライブドアの技術の話について書いた、その記事のコメント欄。最初は感情的な批判などがあって話題とは別の方向で炎上し気味だったんでうーんと思ってたんですが、後半になってきて少し面白い議論が出てきました。 こんな反応があった。 アクセス数が増加している段階で、ApachやAppServerのスレッド数をいじろうが、ヒープサイズを増やそうが、DBのパラメータをいじろうが、はてまたアプリを書き直そうが、性能要求にミートするには相当のワークが発生しますし、どう最適化、チューニングしても追いつきません。そのようなチューニングにお金をかけるならサーバーを追加したほうが安く上がるのではないかと思うのですが、如何でしょう? それに対する僕の返信は、 確かに何千万もするファイルサーバーとか、ロードバランサーとかで問題が解決できる機会っていうのは存在すると思います。なので ”負荷が高ければ、結局サーバーを単純に増
今日は以前のエントリーで書くと述べたConsistent Hashingに関して語らせて頂こうかと思います。ただしConsistent Hashingはセミナーやカンファレンスなどでかなり語られていると思いますので、コンセプトに関しては深入りせず、実用性に着目したいと思います。 問題定義 分散されたキャッシュ環境において、典型的なレコードを適切なノードに格納するソリューションはkeyのハッシュ値に対しmodulo演算を行い、その結果を基にノードを選出する事です。ただし、このソリューションはいうまでもなく、ノード数が変わるとキャッシュミスの嵐が生じます。つまり実世界のソリューションとしては力不足です。 ウェブサイトのキャッシュシステムの基本はキャッシュがヒットしなかったらデータベースにリクエストを発行し、レコードが存在したらキャッシュしてクライエントに返すという流れです。ここで問題なのが一瞬
発表会では、東京大学 情報理工学系研究科の平木敬教授が、同プロジェクトの概要、新しく開発したプロセッサなどの説明を行なった。 今回発表されたGRAPE-DRプロセッサは、できる限り機能を絞って小型化したというコプロセッサを512コア搭載し、動作周波数500MHzで512G FLOPSの演算性能を1チップで実現。1チップで512コア、512G FLOPSは世界最高を達成し、また、消費電力は最大60W、アイドル時30Wで、こちらも汎用プロセッサとして演算速度当たり世界最低だという。 プロセッサは16の演算ブロック、共有メモリ、PLL(Phase Locked Loop)などの各モジュールで構成されたシンプルな構造。演算ブロックに32コアを内蔵し、32×16の512コアとなっている。1つのコアはレジスタ、加算(FADD)、乗算(FMUL)など、演算に必要な回路のみに切り詰めたという。演算の実行は
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
