Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

こんにちは。 Windows サポートの水上です。 最近、 Windows サポート チームに、次のようなお問合せがありました。 お問合せ例 1: Processor Queue Length パフォーマンス カウンターでのボトルネック判断基準を確認したい。 お問合せ例 2: パフォーマンス カウンターを監視していたところ、 Disk Queue Length の上昇がみられた。どのように判断すればよいか、確認したい。 今回は、このような疑問に "Queue Length" の意味合いにも触れながらお答えします。 そもそも Queue Length とはなんなのか? Queue Length とは、待ち行列の長さのことです。 Processor Queue Length であれば、 CPU コアの割り当てを待つスレッドの行列の長さを、 Disk Queue Length であれば、ディスク
こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの?」みたいな経験はありませんか?不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、
本記事の公開後の2016年7月にはてなにおけるチューニング事例を紹介した。 はてなにおけるLinuxネットワークスタックパフォーマンス改善 / Linux network performance improvement at hatena - Speaker Deck HAProxy や nginx などのソフトウェアロードバランサやリバースプロキシ、memcached などの KVS のような高パケットレートになりやすいネットワークアプリケーションにおいて、単一の CPU コアに負荷が偏り、マルチコアスケールしないことがあります。 今回は、このようなネットワークアプリケーションにおいて CPU 負荷がマルチコアスケールしない理由と、マルチコアスケールさせるための Linux カーネルのネットワークスタックのチューニング手法として RFS (Receive Flow Steering) を
Mac を使っていて、だんだん動きがもっさりしてきたなー*1と思って /private/var/vm/ 下を見ると、案の定スワップファイルが溜まっていることがある。 こういうケースでの対策としては、・スワップ禁止にする、・/usr/sbin/purgeする、・再起動する、といった手があるけど、スワップ禁止にするのは本当にメモリ不足になる可能性を考えると怖いし、purgeはスワップアウトしたデータを回収してくれないので効果は一時的だし、再起動はめんどい。 そんな場合は、処理が落ち着いたタイミングで以下のようにして、スワップを実メモリに書き戻せばよい*2。スワップファイルも全部消える。 $ sudo launchctl unload /System/Library/LaunchDaemons/com.apple.dynamic_pager.plist $ sudo launchctl load
下記のようなシステムでパフォーマンスが良さげな SQLite を使用予定ですが、もっと速いものが無いか確認のため他のデータベースのパフォーマンスを計測してみました。SQL 利用前提ですが、NoSQL が圧倒的な性能を出す場合は検討する必要があるので KVS も確認しました。 データ件数は 1 億件程度、JDBC SQL 利用可能 INSERT、UPDATE はバッチ SELECT は主キーアクセス性能を重視 将来スケールアウトのための分散はありえるが、スタンドアロンで遅いのはだめ データベースのパフォーマンス比較 計測したデータベース データベース名 タイプ 形態 評判 計測についての備考 SQLite RDB 組み込み ※2 おもちゃ、Android標準 JDBC操作 ※1 H2 RDB 組み込み ※2 組み込み最速 JDBC操作 ※1 Derby RDB 組み込み ※2 Java標準で
どこまで出来るか?!やれるところまでやってやるぜ!!と、威勢が良いのは若い間だけの話。オトナのオトコは、攻めるときはとことん攻めるが自らの限界もわきまえて賢く振る舞うのがスマートってものである。というわけで、今日はMySQLのいろいろな限界についてまとめてみる。皆さんも是非MySQLの限界を知り、MySQLをもっとスマートに使って頂きたい。 SQL文の最大長 MySQLサーバーが実行出来るSQL文の最大長は、max_allowed_packetシステム変数で表される。max_allowed_packetの最大値は1GBである。max_allowed_packetの値はセッションごとにも設定可能なので、デフォルトではそこそこの値(16MBなど)に設定しておいて、必要に応じて大きな対を使うと良いだろう。 データベースの個数 データベースオブジェクトの個数に制限はない。データベースオブジェクトは
MySQL InnoDB Pluginのデータ圧縮機能の続きです。前回はInnoDB Pluginの独自機能であるデータ圧縮の仕組みを解説し、Wikipedia日本語版のデータが約半分にまで圧縮されることを確認しました。今回はデータ圧縮によって性能がどのように変化するかを、実際にベンチマーク試験を行って見ていきます。 試験の方針 データ圧縮による性能への影響は、以下の二点が考えられます。 メリット:データサイズが小さくなるため、ディスクI/Oが減る デメリット:圧縮・展開の処理が行われるため、CPU負荷が高くなる そこで、これらの特徴がよく分かるように試験パターンを工夫します。Wikipedia日本語版のデータはInnoDB上でおよそ5GBありますが、まず狭い範囲に絞って読み取り処理を行うことでディスクI/Oがあまり発生しないようにします。これでCPU負荷の傾向を確認することができます。次
ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基本中の基本であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_
検証方法 ここに取り上げたパフォーマンス カウンタは、一般的なシステム状況のチェック、およびパフォーマンス基準との比較判断に役立ちます。これらのパフォーマンス カウンタを約 60 分間実行して、1 分から 3 分の更新間隔を取ります (この間隔は、カウンタ ログの [プロパティ] パネル、またはパフォーマンス設定パネルおよび画面で設定します)。 メモリ使用率の監視 説明 : Available MBytes カウンタは、コンピュータ上で実行するプロセスが使用可能な物理メモリの容量を、メガバイト (1 メガバイトは 1,048,576 バイト) 単位で表します。この容量は、Zeroed、Free、 Stand by の各メモリ リストにある空間を合計して算出します。Free メモリはすぐに使用できる空間です。Zeroed メモリはゼロでクリアされたメモリ ページで、前のプロセスが使用したデー
モバゲーで知られるDeNAは、バックエンドデータベースにNoSQLを使っていません。なぜか? それはMySQL/InnoDB 5.1の環境で秒間75万クエリという、多くのNoSQLでも実現できないような高性能を実現しているから。DeNAの松信嘉範(まつのぶよしのり)氏は、自身のブログにこんな内容のエントリ「Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server」(英語)をボストしています。 Yoshinori Matsunobu's blog: Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server 松信氏が指摘するように、大規模なネットサービスを提供している企業の多くは分散環境で
Facebookが大規模スケーラビリティへの挑戦で学んだこと(後編)~キャッシュが抱えるスケーラビリティの問題とデータセンターにまたがる一貫性 全世界で3億人を超える会員を抱え、世界最大のSNSとなったFacebook。同社の技術担当バイスプレジデント Jeff Rothschild氏が、10月8日に米カリフォルニア大学サンディエゴ校で行ったセミナー「High Performance at Massive Scale-Lessons learned at Facebook」の内容を再構成して紹介します。 (この記事は「Facebookが大規模なスケーラビリティへの挑戦で学んだこと(前編)~800億枚の写真データとPHPのスケーラビリティ問題」の続きです) キャッシュがスケーラビリティに大きな役割を果たしている Facebookの主な役割は、ユーザーが簡単に(友人たちの)情報を集めることがで
世界各国のメーカーが、魅力的なスペックを備えたAndroidスマートフォンを次から次へと発売している。スマートフォンの購入を検討しているユーザーはもちろん、すでにiPhoneを使っているユーザーにとっても気になる存在だろう。品薄状態が続くiPhone 4をようやく入手した筆者だが、最新スマートフォンOS「Android 2.2」(開発コード名:Froyo)の処理性能には大いに興味をそそられている。 Android 2.2の強化点は「Flash対応」をはじめ盛りだくさんだが、どのユーザーにとっても恩恵があるのは処理性能だろう。米GoogleはAndroid 2.2のアプリケーション実行速度を「これまで(Android 2.1)の2倍から5倍」としている。 幸いにも6月、そのAndroidスマートフォンを心ゆくまでいじりまわす機会が筆者に巡ってきた。日経Linuxの最新号(8月号)で「Andr
About Bootchart is a tool for performance analysis and visualization of the GNU/Linux boot process. Resource utilization and process information are collected during the boot process and are later rendered in a PNG, SVG or EPS encoded chart. The project started as a response to a challenge posted by Owen Taylor on the Fedora development mailing list: Online Casino Deutsch "The challenge is to crea
PageDefrag v2.32 11/01/2006 2 minutes to read By Mark Russinovich Published: November 1, 2006 Download PageDefrag (70 KB) Run now from Sysinternals Live. Introduction One of the limitations of the Windows NT/2000 defragmentation interface is that it is not possible to defragment files that are open for exclusive access. Thus, standard defragmentation programs can neither show you how fragmented yo
ユーザー同士のつながりを元に時系列に140文字のメッセージを20個ほど表示する――。Twitterのサービスは、文字にしてしまうと実にシンプルだが、背後には非常に大きな技術的チャレンジが横たわっている。つぶやき数は月間10億件を突破、Twitterを流れるメッセージ数は秒間120万にも達し、ユーザー同士のつながりを表すソーシャル・グラフですらメモリに載る量を超えている。途方もないスケールのデータをつないでいるにも関わらず、0.1秒以下でWebページの表示を完了させなければならない。そのために各データストレージは1~5ms程度で応答しなければならない。 Twitterのリスト機能の実装でプロジェクトリーダーを務めたこともあるNick Kallen氏が来日し、2010年4月19日から2日間の予定で開催中の「QCon Tokyo 2010」で基調講演を行った。「Data Architecture
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く