マッピングタイプを使いすぎないようにする Elasticsearchでは１つのインデックスの中に複数の異なるスキーマ定義を持つことができる。このスキーマ定義をマッピングタイプという。単に「タイプ」と呼ばれる事もある。フィールドのデータタイプとは別の概念。インデックスはデータベースに、マッピングタイプはその中のテーブルに例えられる事が多いが、同じ名前のフィールドはマッピングタイプが異なっていても定義が共有されたりして、データベースのテーブルほど互いに独立していない中途半端なものになっている。（2.0より前のバージョンではタイプごとにフィールド定義が異なっていても多少使えたりしたが、2.0以降は厳密に禁止されるようになった. 参照：Conflicting field mappings） タイプが異なっていてもデータは同じLuceneインデックスの中に混ざって入ってしまうため、タイプ間で互いに影
こんばんは、 @matsumotoryです。 hb.matsumoto-r.jp 上記エントリにおいて、プロセスの大量メモリ確保に伴うページテーブルサイズとベージテーブルエントリ数の肥大化によるcloneやexecveの性能劣化とCPU使用時間の専有問題、および、それらの解決方法についてシステムコールレベルで確認しました。 そこで今回は、システムコールやそのカーネル内部の処理の性能、というよりは、より実践的な環境であるApache httpdとmod_cgiを用いて、phpinfo()を実行するだけのCGIに対してベンチマークをかけた時にどれぐらいCPUのidleが空くか、システムCPUの使用量が変わるかを、前回示した解決方法の1つであるHugePagesを使うかどうかの観点で比較してみましょう。 特定条件下のWebサーバ環境のシステムCPUに起因する高負荷問題から、システムコールやカーネ
ツチノコブログのWEBサーバベンチマークツール比較の記事で紹介されていた。WebサーバのG-WAN。この記事によると凄く速いようです。 Intel Xeon E5-2640 (6コア/12スレッド 2.50GHz) を2つというサーバで gwan 334944 req/s nginx 111842 req/s と、速いと言われているnginxの3倍の速度を出しています。 このベンチマーク結果がとても気になったので、なぜG-WANが速いのか、自分でも検証してみました。 結論から言うと以下の2つ。 1) G-WANはデフォルトで物理CPUに合わせた数のスレッドを起動する 2) HTMLファイルも一度読み込んでキャッシュする という事です。 今回はAWSのcc2.8xlarge(E5-2670 8コア/16スレッド 2.60GHz *2)を使ってベンチマークを行いました。OSはAmazon L
NTT オープンソースソフトウェアセンタ 笠原 辰仁 稼動統計情報とは、PostgreSQLが独自に収集・記録している情報です。性能やDB内で起こっている問題などを把握する上で、とても重要です。DBMSでの稼動状況を確認・把握するのに非常に便利なので、この情報を活用し、問題の早期発見やチューニング方法の選択に役立てましょう。 稼動統計情報で分かること 稼動統計情報を活用すると、DBMSを運用する上でとても便利な情報が得られます。特に有用なものを紹介します。なお、稼動統計情報の内容はPostgreSQLのバージョンで若干異なり、新しいバージョンほど得られる情報が増えています。詳しくは「有用な情報を持つテーブル/ビュー」を見てください。 DB単位のコミット数やロールバック数 DB毎に、トランザクションのコミット回数やロールバック回数が分かります。それぞれ、スループットとエラー発生数と置き換える
PostgreSQLの設定 チューニング¶ PostgreSQL when it is not your job - Christophe Pettus 経由で DjangoCon Europe 2012 で発表された このスライド を知ったので、 メモ代わりに残してみる。件のblogは抜粋なので、ここでは可能な限り全部載 せます。 最初に¶ 気をつける設定はこれだけ。 ログ メモリ チェックポイント プランナー ログ¶ ログに対して寛容になること。システムへの影響は少ない。 ログは性能問題を解決するための一番いい情報。 どこにログを出す？¶ syslog: すでにsyslogを使うシステムを構築してるならこれがいいでしょう 標準形式のファイル: 標準形式のファイルを使うツールをすでに使っていればこれ。 そうでなければ CSVフォーマット あとの設定はこれ。 log_destination
9 Min Read Optimising NginX, Node.JS and networking for heavy workloads Used in conjunction, NginX and Node.JS are the perfect partnership for high-throughput web applications. They’re both built using event-driven design principles and are able to scale to levels far beyond the classic C10K limitations afflicting standard web servers such as Apache. Out-of-the-box configuration will get you prett
We are proud to be working with our customers while they continue to enjoy our Engine Yard products. Here are some changes we are making
大規模サイトの性能改善作業とは、どういうものなのか――。リクルートの中古車情報サイト「カーセンサーnet」を全面リニューアルした体験を基に、その実態をレポートする。第1回、第2回はミドルウエアのチューニングを行った。後半はLinuxカーネルに原因があると判明するまでの調査に進む。様々なツールを組み合わせて追跡していった。 中古車情報サイト「カーセンサーnet」の性能試験が本格的に始まって10日目。試験の開始当初は、ブラウザーの表示に10秒もかかるなど目標性能に遠く及ばなかった。しかし前回までで紹介したように、ファイル共有システム「NFS」の設定変更、Webサーバー「Apache」のパラメーター修正、PHPアプリケーションの見直しによって、性能は劇的に向上した。 リクルート入社3年目の私は、今回の性能検証プロジェクトのリーダーとして、得意分野を持つチームメンバーと一緒に対策を進めていた。カッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
