問題タブ [iowait]

ボックスに 100% iowait がある理由を突き止めようとしています。mysql select クエリのようなものを実行すると、システムは 100% iowait になり (サーバー上の複数の CPU で)、ウォッチドッグが強制終了され、httpd 自体が強制終了されることもあります。

vmstat を見ると、約 8 秒ごとに 5MB のディスク書き込みがあることがわかります。これにより、少なくとも 1 つの CPU (4 つのうち) が 1 秒または 2 秒間ブロックされます。

ext3 には数百万のファイルがあると言わざるを得ません (ext2 を試してみましたが、atime もジャーナリングも有効にしていません)。2 つの 300GB ide をミラーリングするハードウェア RAID があります。

dtrace がありません。これらの書き込みの原因を突き止める方法はありますか? また、ファイルシステムを高速化するにはどうすればよいですか?

アイデアは大歓迎です！

ありがとうございました！

多くのマシン/ノードが関係する並行システムがあります。各マシンは、異なる処理を実行する複数のJVMを実行します。これは「階層化」アーキテクチャであり、各層はマシン間で実行される多数のJVMで構成されます。基本的に、最上位層のJVMは、ファイルを介して外部から入力を受け取り、入力を解析して、第2層の「ストレージ」用に同じ数の小さなレコードを送信します。レイヤー2は実際にはデータ自体を永続化しませんが、実際にはレイヤー3（HBaseとSolr）に永続化し、HBaseは永続化のためにレイヤー4（HDFS）に送信するため、実際にはデータ自体も永続化しません。

レイヤー間の通信のほとんどは同期されているため、もちろん、多くのスレッドが下位レイヤーの完了を待機することになります。しかし、これらの待機中のスレッドは、CPU使用率に対して「無料」であると期待しています。

ただし、非常に高いiowait（％waが上）が表示されます。これは、80〜90％のiowaitと10〜20％のsys /usrCPU使用率のようなものです。システムが使い果たされているようです-ssh経由でのログインが遅く、コマンドなどへの応答が遅いです。

私の質問は、下位層が完了するのを待っているすべてのJVMスレッドがこれを引き起こす可能性があるかどうかです。応答（ソケット）を「無料」で待機することは想定されていませんか。これに関して、異なるレイヤーがブロッキングまたは非ブロッキング（NIO）ioを使用するかどうかは重要ですか？正確にどのような状況でLinuxは何かをiowaitとしてカウントしますか（％waがトップ）？マシン上のすべてのJVMのすべてのスレッドが待機している状況にある場合（その間に意味のあることを実行するために実行するスレッドが他にないため、カウントします）？または、CPUを実際の処理に使用する準備ができている他のプロセスがある場合でも、待機中のスレッドも％waにカウントされますか？

それがどのように機能し、この高い％waをどのように解釈するかについて、完全に説明したいと思います。最初は、すべてのスレッドが待機しているときは％waとしてカウントされると推測しましたが、実際にはさらに多くのことを行う余地があるため、スループットの向上を期待してスレッドの数を増やしようとしましたが、それは起こりません。 。ですから、それは本当の問題であり、単に「視覚的な」問題ではありません。

以下の出力は、HBaseとHDFSのみが実行されているマシンから取得されたものです。私が示している問題（最も明確に）は、HBaseおよび/またはHDFSを搭載したマシン上にあります

RAID0 の 2 つのエフェメラル ディスクを備えた Amazon EC2/Rightscale m1.large インスタンスの単一ノード cassandra に関する次の統計があります。(合計 7.6 GB のメモリ)

cassandra Heap には 4 GB の RAM が割り当てられ、800 MB は Heap NEW サイズです。

以下の統計は OpsCenter community 2.0 からのものです

読み取り要求 1 秒あたり 285 ～ 340
書き込み要求 1 秒あたり 257 ～ 720 OS負荷 15.15
～ 17.15
書き込み要求遅延 293 ～ 685 マイクロ
秒キュー サイズ 23 ～ 26 要求 保留中の読み取り要求 8 ～ 20 読み取り要求遅延 69140 ～ 92885 マイクロ 秒OS ディスク遅延 37 ～ 42 ミリ秒 OS ディスク スループット 12 ～ 14 Mb/ 秒2番目

IOWait 60 ～ 70 % CPU 平均

アイドル 24 ～ 30 % の CPU 平均

行キャッシュが無効になっています。

上記の統計は、提供された構成に満足していますか....または、IOWaitを減らすためにさらに調整するにはどうすればよいでしょうか.....多くのIOWaitが発生していると思われるため.....どうすれば最高の状態になるように調整できるでしょうか。

読み取り要求が混在しています....一部は、1 つのスーパー カラム ファミリと、100 万を超えるキーを持つ 1 つの標準からのものです...そして、さまざまな番号があります。スーパー カラムの最大数は 14 で、さまざまな数があります。1 から 10000 までのサブカラムとさまざまな数。列の最大 14 標準の列ファミリで.サブ列は本質的に非常に細く、値は 0 バイトです....名前は 8 バイトです。

プロセスは、スーパー列ファミリーからデータを削除し、処理されたデータを標準のものに書き込みます。

EBS ディスクの方がうまく機能するでしょうか....Amazon EC2 で

Linux debian で PostgreSQL 8.3 を実行する専用のデータベース サーバーがあります。更新/挿入も頻繁に行われている間、データベースは定期的に大量のデータを照会されています。定期的に、データベースが短時間 (10 秒など) 応答しないと、通常の実行フローに戻ります。

top で気付いたのは、その間、データベースが応答しない限り続く iowait スパイクがあることです。同時に pdflush がアクティブになります。したがって、pdflush は、ダーティ ページとバックグラウンドの比率に基づいて、キャッシュされたメモリ空間からディスクにデータを書き戻さなければならないというのが私の考えです。残りの時間、postgresql が正常に動作する場合、pdflush がアクティブでないため、iowait は発生しません。私の vm の値は次のとおりです。

私のmeminfo：

ダーティページがメモリに留まる期間（dirty_expire_centisecs）を微調整して、iowaitスパイクを時間的に均等に分割することを考えています（より定期的にpdflushを呼び出して、より小さなデータのチャンクをディスクに書き込みます）。他に提案された解決策はありますか？

Cassandra の読み取りパフォーマンスを改善するための助けが必要です。カラムファミリーのサイズが大きくなるにつれ、読み取り性能の低下が気になります。単一ノードの Cassandra に関する次の統計があります。

オペレーティング システム: Linux - CentOS リリース 5.4 (最終)
Cassandra バージョン: apache-cassandra-1.1.0
Java バージョン: "1.6.0_14" Java(TM) SE ランタイム環境 (ビルド 1.6.0_14-b08) Java HotSpot(TM) 64 -Bit Server VM (ビルド 14.0-b16、混合モード)

カサンドラ構成: (cassandra.yaml)

• rpc_server_type: hsha
• disk_access_mode: mmap
• 同時読み取り: 64
• 同時書き込み数: 32

プラットフォーム: RAID0 の 4 つのエフェメラル ディスクを備えた Amazon-ec2/Rightscale m1.Xlarge インスタンス。(合計 15 GB のメモリ、4 つの仮想コア、2 つの ECU、合計 ECU = 8)

---

実験構成: GC でいくつかの実験を試みました

Cassandra 構成:
10 GB RAM が Cassandra Heap に割り当てられ、3500MB が Heap NEW サイズです。

JVM 構成:
JVM_OPTS="$JVM_OPTS -XX:+UseParNewGC"
JVM_OPTS="$JVM_OPTS -XX:+UseConcMarkSweepGC"
JVM_OPTS="$JVM_OPTS -XX:+CMSParallelRemarkEnabled"
JVM_OPTS="$JVM_OPTS -XX:SurvivorRatio=1000"
JVM_OPTS= "$JVM_OPTS -XX:MaxTenuringThreshold=0"
JVM_OPTS="$JVM_OPTS -XX:CMSInitiatingOccupancyFraction=40"
JVM_OPTS="$JVM_OPTS -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseCompressedOops"

---

OpsCenter コミュニティ 2.0 からの結果統計:

読み取り要求 1 秒あたり 208 ～ 240
書き込み要求 1 秒あたり 18 ～ 28 OS
負荷 24.5 ～ 25.85
書き込み要求の遅延 127 ～ 160 マイクロ
読み取り要求の遅延 82202 ～ 94612
マイクロ
2 番目
の OS ディスク キュー サイズ 13 ～ 15
要求 保留中の読み取り要求 25 ～ 32

OS ディスクの待ち時間 48 ～ 56 ミリ秒
OS ディスクの読み取りスループット 4.6 Mb/秒
ディスク IOPs 読み取り 420/秒

IOWait 80 % CPU 平均

アイドル 13 % CPU 平均

行キャッシュが無効になっています。

---

列ファミリー 私が読んでいるだけの列ファミリーの 1 つは、CLI によって作成されます。

列ファミリー SSTable サイズ = 7.10 GB、SSTable カウント = 2

XColFam列ファミリーには 59499904 の番号があります。推定された行キー (ほとんどは mx4jtools を介して推定されたさまざまな長さの utf8 リテラル) と、本質的に薄いような列、値が 0 バイトである.....今.

ほとんどの行には非常に少数の列 (おそらく 1 から 10) が含まれている必要があるため、列名の最初のコンポーネントは約 20 から 30 バイトで、2 番目は 8 バイトの整数です....複合列の 2 番目のコンポーネントは動的に繰り返される可能性がありますしかし、確率は低いです.......第1成分はさまざまに繰り返されますが、行の列数は異なる場合があります。

列ファミリーを圧縮しようとSnappyCompressionしましたが、サイズに変化はありませんでした。

20 スレッドで数時間実行され、この列ファミリに対して複数のキー (現在は要求ごとに 2 つのキー) のランダム読み取り要求を行い、行全体を読み取り、列スライスなどを読み取らないスケジュールされたサービスがあります。

1分間に処理するリクエストが少なすぎるため、パフォーマンスが良くないと思います。カラムファミリーのサイズがそれほど大きくない以前は、うまく機能していました。3～4GBくらいでした。

列ファミリーのサイズが大きくなると、読み取りパフォーマンスが急速に低下するのではないかと心配しています。

また、以前は GC と CPU を大量に使用していたため、いくつかの GC とメモリを微調整しようとしました。データ サイズが小さく、波形の iowait が非常に小さい場合。

---

Cassandra のパフォーマンスを向上させるにはどうすればよいですか。あなたの提案は高く評価されます。

アプリケーションが IO バウンドか CPU バウンドかを判断したいと考えています。アプリケーションの実行時間のうち、CPU 待機/IO 待機/CPU での実行などに費やされている時間を特定するツールはありますか? 端末からアプリケーションを実行しています。実際にLinux用のツールがあると聞いたことがありますが、それが何であるかはわかりません。

Oracle Version: 11.1.0.7.0

OracleRACインスタンスの1つでIO待機が高くなっています

1つのSQLの実行による経過時間は長く、実行ごとに1452.57秒です。これはある日突然起こり始めました。以前は、20k（：v4パラメーター）レコードを照会するのに最大3〜4分かかりました

subscribeinfoレコード：5900万（非並列）

チャージレートレコード：2k-3k

SQLは以下のとおりです

o.msisdn、o.spid、o.serviceid、o.ChargeReferenceID、o.channelID、o.nextchargetime、o.failtimestamp、o.lastmonfeeday、o.networkId、o.retryEndDateTime、o.trialType、o.subFlag、oを選択します.faultCode from subscribeinfo o、chargerate r where（o.monthbillid =：v1）and（（（o.state =： "SYS_B_00"）and（o.nextchargetime <：v2）and（（o.IsAutoExtend <>： "SYS_B_01 "）または（（o.IsAutoExtend =：" SYS_B_02 "）and（o.extendflag <>：" SYS_B_03 "））））または（o.subFlag =：" SYS_B_04 "and o.state =：" SYS_B_05 "and o .retryenddatetime>：v2））and（o.ChargeClassForSub = r.chargeclassidx）and（（r.chargemode =： "SYS_B_06" and r.activetype =： "SYS_B_07" and o.nextchargetime！=： "SYS_B_08"）または（ r.chargemode =："SYS_B_09"およびr.activetype<>："SYS_B_10"）または（r.chargemode> =： "SYS_B_11" and r.chargemode <=： "SYS_B_12" and r.basecharge> =： "SYS_B_13"）または（r.chargemode =： "SYS_B_14"）または（r .chargemode =： "SYS_B_15"）または（r.chargemode =： "SYS_B_16"））および（o.failtimestamp <=：v3）および（rownum <=：v4）

AWRレポートによるとトップ5の時限フォアグラウンドイベント

ダイレクトパス読み取り[平均待機時間：22秒、％DB時間：50.75％] DBファイルシーケンシャル読み取り[平均待機時間：15秒、％DB時間：38.00]

制限があるため、完全なAWRレポートを投稿することはできません。だから私が投稿する詳細を聞いてください

以下の説明プランをご覧ください。

ID Exec Ord Operation Go To More Peek Bind Capt Bind Cost2 Estim Card LAST Starts LAST Output Rows LAST Over / Under Estimate1 PStart PStop Work Area 0 7 SELECT STATEMENT
23335 1 2577 1 6 COUNT STOPKEY [+] [+]
[+] 23335 1 257725。ハッシュ結合[+][+]
[+] 23335 20001 125778xオーバー[+]31..テーブルアクセスフルチャージ[+][+]68 3035 1 3036 1x 44..パーティションリストシングル[+]23266.. 25223 1 2577 10x over KEY KEY 53...ローカルインデックスによるテーブルアクセスROWIDSUBSCRIBEINFO[+] [+] [+]
[+] 23266 25223 1 2577 10x over KEY KEY 62....インデックス範囲スキャンIDX_FAILTIMESTAMP_NEW[+][+] [+] [+] 243512100765キーキー

IOSTAT

Linux 2.6.16.46-0.12-smp（mdspdb01）11/16/12

avg-cpu：％user％nice％system％iowait％steal％idle

デバイス：tps Blk_read / s Blk_wrtn / s Blk_read Blk_wrtn

sda 5.71 39.53 121.79 665679995 2051190222

sdb 85.75 178.15 171.12 3000316741 2881953582

sdc 111.05 161.69 43.96 2723201251 740429949

---

monthbillid、nextchargetime、failtimestampの各フィールドのインデックスを作成しました...これにより、カーディナリティが1/6に大幅に向上しましたが、コストが4〜5倍に増加しました。ただし、Oracleはデフォルトで新しいインデックスを取得します

subscribeinfo（monthbillid、nextchargetime、failtimestamp）ローカルテーブルスペースIMUSE_INDEXにインデックスIDX_MONTHBILLQUERYを作成します。

dbms_stats.gather_index_stats（'IMUSE01'、'IDX_MONTHBILLQUERY'）;

AWRレポートにはハード解析=0があります。また、cursor_sharing=FORCEを変更しました

現在、IOは制御下にあります。まだ感じていますが、これは根本的な原因ではありません。また、インスタンスをこのクエリ専用にしました。これは1時間に10回以上発生し、2万件のレコードを取得するのに約100秒かかります。

オプティマイザーモードをfirst_rowsとして使用するか、ヒントfirst_rows（20000）を使用するかを選択するのが適切かどうか、誰かが提案できますか。

現在、統計ジョブを無効にしていますが、一部のテーブルまたは一部のインデックスに対してのみ同じことを有効にできますか？これは可能ですか？

私の友人のデザイナーは、自分の LESS ファイルを手動でコンパイルし、Coda (リモート サイト) にアップロードするのに多くの貴重な時間を費やしていました。彼は私に尋ねました：

Linux サーバー上のファイルの変更を自動的に検出し、遅延なくコンパイルすることはできますか?