タグ付けされた質問 「io」

IO(またはI / O)は入出力の略語であり、最も一般的にはディスクの入出力を指します。

1
I / Oスニッフィングの方法
サイジングのために、アプリケーションがI / Oサブシステムに対してどのような要件を持っているかを理解する必要があります。私はI / Oスニッフィングと呼んでいることを行い、ブロックレイヤーから次のようなイベントのリストを取得したいと思います。 initiator XYZ requests block 4711 from device 0815 initiator BLA writes block 1234 to device 9876 blktraceは私が探しているものだと言われましたが、そのツールからこの情報を取得することはできません。
11 linux  io  block  trace 

2
キャラクターデバイス(テープドライブなど)のパフォーマンスをどのように監視しますか?
ブロックデバイスのパフォーマンスを監視する方法は多数あります。dstatおよびiostat、heck、sarでさえ、ブロックデバイスのI / Oレートに関するデータを提供します。残念ながら、テープドライブなどのキャラクターデバイスのパフォーマンスを監視するための優れたツールはありません。 事前に覚えておくとパフォーマンスを監視するツール(pv、dd + SIGUSR1、おそらくその他)があることは知っていますが、パフォーマンスに応じて3時間または30時間になる可能性のある仕事に2時間かかります。そして、あなたはそれがどれなのか分かりません。 私が考えることができる唯一のことは、おそらくタイムスタンプを使用して、書き込まれたバイトの出力を解析するstraceなどの精巧な使用です。忘れてしまった、または聞いたことがない、よく使用されるツールはありますか?

2
MySQLは非常に単純なSELECTクエリで非常に遅い
InnoDBエンジンを備えたMySQL 5.5データベースにデータを保存する仮想マシンで実行されている単純なWebアプリケーションがあります。約3年間はすべて問題なく動作しましたが、突然、非常に遅くなりました。 たとえば、住所を保持する非常に単純なテーブルがあります。 CREATE TABLE `addresses` ( `address_id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(64) CHARACTER SET latin1 NOT NULL, `firstname` varchar(64) CHARACTER SET latin1 NOT NULL, `street` varchar(64) CHARACTER SET latin1 NOT NULL, `housenumber` varchar(16) CHARACTER SET latin1 NOT NULL, `zip` varchar(5) CHARACTER SET latin1 NOT NULL, `city` varchar(64) CHARACTER …
10 linux  mysql  performance  io 

5
EC2インスタンスのUbuntu 12.04でのI / O待機による高負荷
Ubuntuサーバー12.04を使用していますが、負荷の原因を特定できません。サーバーの応答時間に先週の変化がありました。 Linuxトラブルシューティングを読んだ後、パートI:高負荷 CPUとRAMには問題がないようで、この負荷は次の出力を取得 したコマンドを使用して、I / Oバウンドの負荷に関連している可能性がありtopます ここでは97.6%wa、RAMは解放され、スワップは使用されていません。 以下は、あることを示すコマンドの出力iostatです89% iowait ubuntu@ip-my-sys-ubuntu:~$ iostat Linux 3.2.0-58-virtual (ip-172-31-6-203) 02/19/2015 _x86_64_ (1 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 3.05 0.01 3.64 89.50 3.76 0.03 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn xvdap1 69.91 3.81 964.37 978925 247942876 私はまたiotop、修正間隔が99%I / Oを示した後、ディスクが私がオブザーバーとして書き込んだものを使用しました1266 KB/s そして 悪いですか 応答時間が低下するにつれて。何が原因ですか? …

1
Windowsの「iowait」CPU使用率レポート
Windows はLinuxと同じ方法で「iowait」を説明および報告しますか?つまり、プロセスは「割り込み不可能なスリープ」に入り、費やされた時間は「CPUフリー」から差し引かれますか? もしそうなら、「計算によるCPUビジー?」ではなく、「IOのサービス遅延によるCPUビジー?」を検出するのに適切なPerfmonカウンターはどれですか。

2
Amazon RDS:IOリクエストとは何ですか?
RDSインスタンスを持っているので、かなりの費用がかかります。アマゾンでの私のアカウントアクティビティから、インスタンスには過去7日間で約800,000,000のIOリクエストがあったことがわかります。 少し見方を変えると、私のアプリは1日に約6,000回のユニークアクセスしか獲得できず、それほど多くのデータベース接続を確立することはありません。 それでは、IO要求とは正確には何であり、なぜその数はそれほど多くないのでしょうか。必要に応じて、コストを削減するためにアプリに必要なことは何でもするつもりですが、実際に何が起こっているのかわかりません。 よろしくお願いします。
9 mysql  io  amazon-rds 

2
ログを記録するとMySQLのパフォーマンスが低下しますが、なぜでしょうか。
MySQLのドキュメントでも、サイトのどこにもこれに対する答えが見当たらないことには、私はかなり驚いています(セクション5.2には、それ以外の場合はログが十分にカバーされているようです!) binlogsを有効にすると、(主観的に)小さなパフォーマンスヒットが表示されますが、これは少し余分なIOで予想されるものですが、一般的なクエリログを有効にすると、非常に大きなパフォーマンスヒットが表示されます(クエリの実行時間が2倍になり、または悪いことに)、私がバイナリログで見るものをはるかに超えています。もちろん、今ではすべてのSELECTとすべてのUPDATE / INSERTをログに記録していますが、他のデーモンは停止せずにすべてのリクエスト(Apache、Exim)を記録します。 IOに関して、パフォーマンスの「転換点」に近いことの影響を見ているだけなのでしょうか、それとも、これを発生させるクエリのロギングに関して根本的に難しいことはありますか?すべてのクエリをログに記録して開発を容易にしたいのですが、一般的なクエリログオンでパフォーマンスを回復する必要があると思われるハードウェアの種類を正当化することはできません。 もちろん、遅いクエリをログに記録します。これを無効にすると、一般的な使用法の改善はごくわずかです。 (これはすべてUbuntu 10.04 LTS、MySQLd 5.1.49にありますが、調査ではこれがかなり普遍的な問題であることが示唆されています)

1
毎日5.5 GBが1.2 GBのルートボリュームに書き込まれる-以前のレベルの4倍
問題: 最近、サーバーの1つを改造しました。使用する前にテストされ、正常に機能しましたが、数日前に、ルートボリュームへの通常の書き込み量の約4倍に気付きました。これはパフォーマンスの問題ではありません-サーバーは正常に動作します。 私の改造はかなり広範囲(完全な再構築)だったので、原因に関して多くを続けることはできません。簡単に言うと、私の変更は次のとおりです。 AmazonのLinuxのアップグレード(2011.02から2011.09へ)-ルートボリュームもext3からext4に変更されました php-fcgiからphp-fpmへの移行(現在はtcpを使用) リバースプロキシ(nginx-> apache)設定からnginxのみへの移行 vsftpdをpure-ftpdで置き換える dkim-proxyをopendkimで置き換える isminconfigによるwebminの置き換え ワニスを動的ファイルのキャッシングレイヤーとして追加します(これらのサイトが受けるヒット数のオーバーキルですが、実験です)。 スワップパーティションを追加する 基本セットアップ: 私のスワップ領域は独自のEBSボリュームにマウントされています-スワップボリュームへの書き込みはごくわずかです-本質的にこれを割り引いています(十分な空きメモリがあり、両方とも最小限のスワップ使用量freeをiostat示しています)。 私のデータ(mysqlデータベース、ユーザーファイル(ウェブサイト)、すべてのログ(/ var / logから)、メール、およびvarnishファイルを独自のEBSボリュームに(を使用してmount --bind)。基礎となるEBSボリュームは、/mnt/data 私の残りのファイル-オペレーティングシステムとコアサーバーアプリケーション(nginx、postfix、dovecotなど)-は、ルートボリューム上にある唯一のファイル(合計1.2 GB)です。 新しいセットアップは、古いシステムより「スムーズ」(メモリが少ないなど)で実行され、20日間(10月中旬)安定しています-私の知る限り、昇格した書き込みはこの間ずっと存在していました。 予想とは逆に、読み取りボリュームが少ない(私の読み取りは、ルートボリュームのブロックとバイトの両方の点で、書き込みの約1.5%です)。過去数日間、ルートボリューム(たとえば、新規インストールなど)で何も変更していませんが、書き込みボリュームは予想よりはるかに多くなっています。 目的:ルートボリュームへの書き込みの増加の原因を特定する(基本的に、それがプロセス(およびプロセス)、別の(ext4)ファイルシステム、または別の問題(メモリなど)かどうかを把握する)。 システムインフォメーション: プラットフォーム:AmazonのEC2(t1.micro) O / S:AmazonのLinux 2011.09(CentOS / RHEL派生) Linuxカーネル:2.6.35.14-97.44.amzn1.i686 アーキテクチャ:32ビット/ i686 ディスク:3 EBSボリューム: xvdap1、root、ext4ファイルシステム(noatimeでマウント) xvdf、data、xfsファイルシステム(noatime、usrquota、grpquotaでマウント) xvdg、swap ルートボリュームとデータボリュームは1日に1回スナップショットが作成されますが、これは「読み取り」操作であり、書き込み操作ではありません。(さらに、以前のサーバーでも同じ方法が使用されました。以前のサーバーもt1.microでした。) I / Oを調べる原因となったデータは、前回のAWS請求の詳細に含まれていました(通常のI / Oを上回っていました-このサーバーをセットアップし、最初に多くのものをインストールしていたため、予期しないことではありませんでした)今月の)、その後、接続されたEBSボリュームのCloudWatchメトリクスで。11月(​​サーバーを変更していないとき)からのI / Oアクティビティを推定して月間値を推定し、それを作業していない過去の月のI / Oと比較することにより、「通常の4倍」の数値に到達します。以前のサーバーで。(以前のサーバーからの正確なiostatデータがありません)。同じ量の書き込みが11月まで持続し、170-330MB …

6
ディスクへの重い書き込みを識別する方法は?
CakePHPアプリケーションを実行しているサーバーでこの問題があります。サーバーがめちゃくちゃ遅いので、最初はアプリケーションの問題だと思っていましたが、ディスクへの書き込みが5〜6MB /秒であることがわかりました。 そのような重い書き込みの原因を見つける最も簡単な方法は何ですか? サーバーはGentooを実行しています。

1
I / OエラーでいっぱいのDmesg、スマートok、影響を受ける4つのディスク
新規インストールされたリモートサーバー(Dell Poweredge)で作業しています。4つのドライブ(2TB)と2つのSSD(250 GB)があります。1つのSSDにはOS(RHEL7)が含まれ、4つのメカニカルディスクには最終的にOracleデータベースが含まれます。 ソフトウェアRAIDアレイを作成しようとすると、ディスクが常に障害としてマークされます。dmesgをチェックすると、次のエラーが大量に出力されます。 [127491.711407] blk_update_request: I/O error, dev sde, sector 3907026080 [127491.719699] sd 0:0:4:0: [sde] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [127491.719717] sd 0:0:4:0: [sde] Sense Key : Aborted Command [current] [127491.719726] sd 0:0:4:0: [sde] Add. Sense: Logical block guard check failed [127491.719734] sd 0:0:4:0: [sde] CDB: Read(32) [127491.719742] sd 0:0:4:0: …
8 redhat  hard-drive  io 

1
高IO負荷でrrdgraph生成が失敗する
私たちは4コアのCPUプロダクションシステムを使用しており、多くのcronジョブを実行します。一定のprocキューと通常の負荷は〜1.5です。 夜間は、postgresでIOを集中的に使用します。負荷/メモリ使用量を示すグラフを生成します(rrd-updates.sh)。これは、高IO負荷の状況で時々「失敗」します。ほぼ毎晩発生していますが、すべての高IO状況では発生しません。 私の "通常の"解決策は、postgresを適切にイオン化し、グラフ生成のプリオを増やすことです。しかし、これはまだ失敗します。グラフ生成は、flockを使用したセミスレッドプルーフです。私は実行時間をログに記録します。グラフ生成では、高IO負荷時に最大5分であり、結果として最大4分間グラフが失われるようです。 タイムフレームはpostgresアクティビティと正確に一致します(これは1日中に発生することもありますが、それほど頻繁ではありません)。 )は問題を解決しませんでした。 データが収集されないと仮定すると、追加の問題は、どういうわけかまだ機能していないiceice / niceです。 90%のIOwaitと100のロードがあっても、5秒以上の遅延なしで(少なくともテストでは)、データ生成コマンドを無料で使用できました。 悲しいことに、テストでこれを正確に再現できませんでした(仮想化された開発システムのみ) バージョン: カーネル2.6.32-5-686-bigmem Debian Squeeze rrdtool 1.4.3 ハードウェア:ハードウェアRAID1 マウントオプションのLVMを備えたSAS 15K RPM HDD :ext3とrw、errors = remount-ro スケジューラー:CFQ crontab: * * * * * root flock -n /var/lock/rrd-updates.sh nice -n-1 ionice -c1 -n7 /opt/bin/rrd-updates.sh RetcacheのgithubにOetiker氏からのsomhowに関連している可能性のあるバグがあるようです:https : //github.com/oetiker/rrdtool-1.x/issues/326 これは実際には私の問題(同時書き込み)である可能性がありますが、cronジョブが失敗しないことを説明していません。仮定では、実際に2つの同時書き込みflock -nがあると、終了コード1が返されます(テストで確認されたmanページごと)。出力も電子メールで届かず、cronjobが他の時間に実際に正常に実行されるという観察どういうわけか失われました。 出力例: コメントに基づいて、更新スクリプトの重要なソースを追加しました。 rrdtool …
8 linux  debian  io  rrdtool  ionice 

3
サブツリーの削除( `rm -rf`)がディスクI / Oのための他のプロセスを枯渇させないようにする方法は?
ビジーなサイト用に非常に大きな(マルチGB)Nginxキャッシュディレクトリがあり、一度にすべてをクリアする必要がある場合があります。キャッシュフォルダーを新しいパスに移動し、古いパスに新しいキャッシュフォルダーを作成しrm -rf、古いキャッシュフォルダーを使用することで、これを以前に解決しました。 しかし、最近、忙しい朝にキャッシュをクリアする必要がある場合rm -rf、Nginxとその前にあるサーバーの両方が読み取り集中型であるため、I / O がサーバーアクセスのディスクアクセスを枯渇させています。CPUがアイドル状態にありrm -rf、ディスクIOの98〜99%を占める間に、負荷平均の上昇を観察できiotopます。 をionice -c 3呼び出すときに試しましたrmが、観測された動作にそれほど影響はないようです。 rm -rfさらにディスクを共有するために飼いならす方法はありますか?手がかりを得る別のテクニックを使用する必要がありioniceますか? 更新: 問題のファイルシステムはAWS EC2インスタンスストアです(プライマリディスクはEBSです)。/etc/fstabエントリは次のようになります。 /dev/xvdb /mnt auto defaults,nobootwait,comment=cloudconfig 0 2
8 linux  hard-drive  io  rm  ionice 

6
データムーバーによるLinux I / Oボトルネック
Ubuntuサーバー10.04を実行する94.6GiB RAMの24コアマシンがあります。同じタイプと同じ量のプロセスを実行している別のサーバー(4コア)とは異なり、ボックスでは高い%iowaitが発生しています。両方のマシンはVNX Raidファイルサーバーに接続され、24コアマシンは4つのFCカードを介して接続され、もう1つは2つのギガビットイーサネットカードを介して接続されます。4コアマシンは現在24コアマシンよりも優れており、CPU使用率が高く、%iowaitが低くなっています。 9日間の稼働時間では、%iowaitの平均は16%で、通常30%を超えています。ほとんどの場合、CPU使用率は非常に低く、約5%です(iowaitが高いため)。十分な空きメモリがあります。 私が理解していないことの1つは、すべてのデータがデータムーバーを直接通過するのではなく、デバイスsdcを通過しているように見える理由です。 avg-cpu: %user %nice %system %iowait %steal %idle 6.11 0.39 0.75 16.01 0.00 76.74 Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn sda 0.00 0.00 0.00 1232 0 sdb 0.00 0.00 0.00 2960 0 sdc 1.53 43.71 44.54 36726612 37425026 dm-0 0.43 27.69 0.32 23269498 268696 dm-1 1.00 …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.