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

Linuxファイルシステムに数百万のテキストファイルを保存し、圧縮して任意のコレクションをサービスとして提供できるようにします。キー/値データベースのような他のソリューションを試しましたが、並行性と並列性の要件により、ネイティブファイルシステムを使用することが最良の選択です。 最も簡単な方法は、すべてのファイルをフォルダーに保存することです。 $ ls text_files/ 1.txt 2.txt 3.txt これは、フォルダ内のファイル数に制限のないEXT4ファイルシステムで可能です。 2つのFSプロセスは次のとおりです。 Webスクレイプからテキストファイルを書き込みます（フォルダー内のファイルの数に影響されません）。 ファイル名のリストで指定された、選択したファイルを圧縮します。 私の質問は、1つのフォルダーに最大1,000万個のファイルを保存すると、上記の操作のパフォーマンスや一般的なシステムパフォーマンスに影響しますか？

15 files  filesystems  performance  ext4 

ワークステーションで重いI / Oプロセスをいくつか実行していますが、最近iotopそれらを監視するためにインストールしました。これが最近のスクリーンショットです。 IO>コラムの読みについて少し混乱しています。これは、ディスクが約1500％のI / Oアクティビティで実行されていることを示しています。それも可能ですか？ これらの読み取り値からディスクの最大I / Oを把握するにはどうすればよいですか？そして、iotopはどのように相対I / Oアクティビティを計算しますか？

15 performance  io  disk  top 

大きなワードリストを重複排除する必要があります。いくつかのコマンドを試して、こことここでいくつかの研究を行いました。そこでは、単語リストを重複排除する最も速い方法はawkを使用しているように見えることを説明しています。 awk-> O（n）？sort-> O（n log n）？ しかし、これは真実ではないようだ。私のテスト結果は次のとおりです。 sort -u input.txt -o output.txt 実数0m12.446s ユーザー0m11.347s sys 0m0.906s awk '!x[$0]++' input.txt > output.txt 実数0m47.221s ユーザー0m45.419s sys 0m1.260s したがって、sort -uを使用すると3.7倍高速になります。どうしてこれなの？重複排除を行うためのさらに速い方法はありますか？ ***********アップデート******** 誰かがコメントで指摘したように、私の単語リストはすでにある程度ソートされている可能性があります。この可能性を排除するために、このPythonスクリプトを使用して 2つのワードリストを生成しました。 List1 = 7 Mb List2 = 690 Mb 結果AWK： List1を リアル0m1.643s ユーザー0m1.565s sysの0m0.062s List2 実2m6.918s ユーザー2m4.499s sys 0m1.345s 結果SORT： List1 …

14 bash  awk  performance  sort 

次のbashスクリプトでcurlバックグラウンドプロセスを実行しています。 START=$(date +%s) for i in {1..100000} do curl -s "http://some_url_here/"$i > $i.txt& END=$(date +%s) DIFF=$(( $END - $START )) echo "It took $DIFF seconds" done 49Gb Corei7-920専用サーバー（仮想ではない）があります。 topコマンドを使用してメモリ消費とCPUを追跡しますが、それらは限界からはかけ離れています。 ps aux | grep curl | wc -l現在のcurlプロセスの数を数えるために使用しています。この数は2〜4千まで急速に増加し、その後連続的に減少し始めます。 パイピングcurlを介して単純な解析をawk（curl | awk > output）に追加すると、curlプロセスの数は1〜2千に増え、その後20〜30に減少します。 プロセスの数がそれほど劇的に減少するのはなぜですか？このアーキテクチャの境界はどこですか？

14 linux  performance  bash  curl  wget 

私のDebian Wheezyシステムはdeadlineスケジューラーを使用しています。私はionice忙しい時間にディスクを集中的に使用するジョブのI / O優先度を再スケジュールするのに慣れています。 ionicemanページ、カーネルのドキュメントと、このopenSUSEの文書は、すべてのみことを示唆しているcfqスケジューラは、アカウントにかかるionice介入。彼らは、他のスケジューラーがそれを無視することを明示的に述べていませんが、彼らが言及している唯一のものはcfqです。 特にdeadline、他のスケジューラは動作しioniceますか？

13 linux  performance 

例えばためbzipありpbzip、並列バージョンbzip。sortパフォーマンスを改善するためのそのような並列化ツールはありますか？

13 performance  sort 

私はcca 26 000ファイルのディレクトリがあり、これらすべてのファイルでgrepする必要があります。問題は、できるだけ早くそれを必要とすることです。そのため、grepがfindコマンドから1つのファイルの名前を取得し、ファイルに一致を書き込むスクリプトを作成することは理想的ではありません。「引数リストが長すぎます」問題の前に、このすべてのファイルをgrepするのにccaに2分かかりました。それを行う方法はありますか？編集：常に新しいファイルを作成するスクリプトがあるため、すべてのファイルを異なるディレクトリに配置することはできません。

13 files  grep  performance 

マニュアルページにはbarrier、ext4 のオプションについて記載されています。 書き込みバリアは、ディスクへのジャーナルコミットの適切な順序付けを強制し、揮発性ディスク書き込みキャッシュを安全に使用できるようにしますが、パフォーマンスがいくらか低下します。ディスクが何らかの方法でバッテリバックアップされている場合、バリアを無効にするとパフォーマンスが安全に向上する場合があります。 バッテリー（およびSSD）を搭載したラップトップは、バッテリーバックアップディスクを搭載していると見なされますか？では、barrier=0ラップトップでext4を使用するのは安全ですか？

13 hard-disk  performance  ext4  laptop  cache 

大量の書き込みアプリケーションを実行すると、システム全体の速度が低下することに気付きました。これをさらにテストするために、これを実行して（比較的）低CPU、高ディスクアクティビティを実行しました。 john -incremental > file_on_SSD これにより、毎秒何万もの文字列がシステムディスク上のファイルに送り出されます。 これを行うと、マウスが遅れ、TTYが応答しなくなり、アプリケーションが「フェード」し、一般的にコンピューター全体が使用できなくなります。最終的にControl + Cができるjohnと、システムは数秒後に完全な強度に戻ります。 これは極端な例ですが、高速ソースからの大きなファイルのコピーやトランスコーディングなど、書き込みの負荷が少し少ないアクティビティで同様の問題が発生します。 私のメインOSディスクは、EXT4を備えた非常に高速なSSD（OCZ Agility 60GB）です。私の書き込みした場合johnEXT4との機械的なディスクへの出力レートがたくさん遅いものの、私は（SSDは毎秒〜42,000の単語を行い、機械は8000ワット/秒をして）同じスローダウンを経験しません。スループットが関係する場合があります。メカニカルディスクもシステムとは関係ありません。それは単なるデータです。 そして、カーネル2.6.35-2を使用していますが、この問題は、SSDを入手したときに、おそらく.31またはその頃の何かを使用していたときに気づきました。 それでは、減速の原因は何ですか？EXT4の問題？カーネルの問題？SSDの問題？上記のすべて？他に何か？ 追加のテストを実行する必要があると思われる場合は、何をすべきかを伝えるコメントをドロップするだけで、質問に結果を追加します。

13 kernel  performance  io  ssd 

比較的最近のカーネルでLinux cgroupを使用して2つのデュアルコアLinuxシステムをインストールしています。1つはDebian Squeezeを実行しており、もう1つはUbuntu 11.04 Natty Narwhalを実行しています。古いカーネルにもかかわらず、Debianシステム上でcgroupの動作が少し改善され、CPUの負荷分散が実現しました。しかし、それはすべてに適しているわけではなく、ここで私が尋ねている特異な奇妙さは両方のシステムで起こります。 コントロールグループを使用したLinuxのリソース管理を読むと、問題の再現方法を示す例が示されています。Ubuntuバージョンは次のとおりです（これをルートとして実行します）。 cd /sys/fs/cgroup/cpu [On Debian Squeeze start at /mnt/cgroups/cpu instead] mkdir low high echo 512 > low/cpu.shares echo 2048 > high/cpu.shares yes low > /dev/null & echo $! > low/tasks yes high > /dev/null & echo $! > high/tasks ps -C yes -opid,%cpu,psr,args [repeat …

13 linux  performance  cgroups 

私はlogcheckのcronジョブとして設定しているように、それがプロセスを実行していますたびに見えgrepによってlogcheck私のCPUの1/4を中心に取り上げます。 CPUのフルキャパシティが必要になる特定の時間帯があり、特定のプロセス（何らかの方法で指定できる場合を除く）を除いて、システムができるだけ少ないリソースを使用するようにします。 Debian 9.1をKDEマシンに設定して、ユーザーが明示的に起動していないプロセスがシステムリソースを大量に消費するのを防ぎ、バックグラウンドプロセスの負荷を軽減するパフォーマンスモード（または「ゲームモード」）に設定することは可能ですか？ ：そのモードが再び停止するまでcronジョブを遅らせますか？

12 debian  cron  performance  cpu  laptop 

TOPコマンドを実行すると、プロセスは1208％のCPU使用率を示し、IRIXモードがオンの状態で合計CPU usr時間は81.7％です。IRIXモードをオフに変更すると、プロセスは99％のCPU使用率を示し、合計ユーザーCPU時間は43％になります。 何が起こっているのでしょうか？ 更新 CPU使用率が正しく報告されないようにVMが正しく構成されていませんか？

12 performance  cpu  top 

強大なstrace私を失望させた。これはどのようにして可能ですか？ time fooこれは、foo実行に数秒かかる（ "実際の"）が、ユーザー空間（ "user"）とカーネル（ "sys"）の両方で無視できるCPU時間を使用することを示しています。好奇心のために、foo以下に定義されています。 そのため、CPU命令を実行するのではなく、他の何かを待つのにほとんどの時間を費やしています。通常、私はそれがどのように待っているかを見ることができますstrace-つまり、どのシステムコールが長期間ブロックしているのか。残念ながら、このアプローチは機能しませんでした。 strace -ttt -T -C -w fooは、システムコール、タイムスタンプ、およびシステムコールに費やされた（実際の）時間の概要を示しています。しかし、この特定のプロセスは、システムコールの内部で費やされる全体（実）時間はごくわずかであることを示しました。 fooですjournalctl -b -u dev-hugepages.mount。これを再現するために、毎回異なるsystemdユニットへの最後の引数を変更しなければならなかったことを除いて。つまり、調査対象の遅延は、あるsystemdユニットのログを取得しようとしたときに初めて発生しました。 編集：主な質問に答えた後、私はこの遅延を再現する問題が発生している理由にも気付きました。 このプロセスに費やされる時間は特定の問題であり、明らかにすべてのシステムで発生するわけではありません。https://github.com/systemd/systemd/issues/7963

11 performance  time  strace 

swappinessパラメータは、カーネルがプロセスを物理メモリからスワップディスクに移動する傾向を制御します。デフォルト設定とは何ですか？全体的なパフォーマンスを向上させるためにそれを構成する方法

11 linux  performance  swap 

私は6年ほど問題なくDebianテストを使用しています（定期的に更新しています）が、最近「ランダムな動作が見られ始め、 "再起動まで持続する低いI / Oパフォーマンス"と要約できます。 問題は、突然すべてのディスクの読み取りと書き込みが約5MB /秒に遅くなり、連続的な読み取りと書き込みが発生することです。レートが非常に低いため、ディスクは機械的にチャレンジされたりストレスを受けたりしませんが、再起動するまですべてが遅くなります。 コンピューターのI / Oサブシステムは、1つのOCZ Vertex 3 SSDと2つのWD Caviar Black HDDで構成されています。SSDはOSの読み取りが多い部分を保持し、HDD上のパーティションは残りを保持します。 問題を診断するために、私は次のことを試みましたが成功しませんでした： top CPUでもI / Oの使用でも暴走は見られません。 hdparmディスクの通常のパフォーマンス評価を返します（-tただし、チェックしただけです）。 smartctlディスクのパフォーマンスの問題は表示されません。長いテストの結果、ディスクは新品同様であることがわかりました。 システムにはZ77チップセット、16GBのRAM、Intel i7 3770K CPUがあり、統計にはRAM、I / O、またはCPUの飽和の兆候はありませんが、このような問題（特にカーネル空間）をデバッグする経験はありません。任意の助けをいただければ幸いです。 更新1： 予防策として、すべてのパーティションで（強制的に）fsckを実行しました。すべてのFSはクリーンです。 ちなみに、1か月前にリリースされて適用されたBIOSアップグレードを見つけました。 50％を超えて埋められるパーティションはありません。 アップデート2： 問題は2日間浮上していません。どちらかfsckまたはBIOSのアップデートは、システム内のいくつかの目詰まりを掃除しました。私はまだ問題を監視しており、死後の回答で質問を閉じます。 更新3： 問題が表面化し、さらに掘り下げました。答えを見てください。

11 linux  performance  io