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

私のHFTソフトウェアでは、株価指数の計算に1つのコアを使用する予定です。それはwhile(true)遅延なしで単純にループし、コンポーネントを可能な限り頻繁に（合計して1秒間に数百万回）計算します。私はそれを毎日1日8時間実行する予定です。 私は自分のコンピューターを毎日フルタイムで毎日レギュラーにロードすることはありませんでした。危ないですか？プロセッサにはある種の「リソース」（もちろん非常に大きい）があり、その後は動作を停止できますか？

9 performance  xeon  central-processing-unit 

PostgreSQL 9.1.2の使用 CPUが過度に使用され、postmasterタスクからディスクへの大量の書き込みが発生しています。これは、アプリケーションがほとんど何も実行していないときにも発生します（1分あたり数十回の挿入）。ただし、適切な数の接続が開いています。 私は自分のアプリケーションの何がこれを引き起こしているのかを特定しようとしました。私はpostgresqlにかなり慣れていないので、今のところどこにも行きません。設定ファイルでいくつかのログオプションをオンにし、pg_stat_activityテーブルで接続を確認しましたが、それらはすべてアイドル状態です。しかし、各接続はCPUを約50％消費し、ディスクに約15M / sを書き込んでいます（何も読み取っていません）。 私は基本的には調整をほとんど加えずにpostgresql.confを使用しています。これを追跡するために何ができるかについてのアドバイスやアドバイスをいただければ幸いです。 以下は、top / iotopが表示しているサンプルです。 Cpu(s): 18.9%us, 14.4%sy, 0.0%ni, 53.4%id, 11.8%wa, 0.0%hi, 1.5%si, 0.0%st Mem: 32865916k total, 7263720k used, 25602196k free, 575608k buffers Swap: 16777208k total, 0k used, 16777208k free, 4464212k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 17057 …

9 linux  performance  postgresql 

3つのWindows 2008 R2ボックスにiSCSIターゲットを提供し、1つのOpenBSD 5.0ボックスにNFSを提供する新しいSynology RS3412RPxsがあります。 sshでRS3412にログインし、ddとさまざまなブロックサイズを使用して小さなファイルと6GBファイルの両方を読み書きすると、優れたディスクI / Oパフォーマンスが示されます。 iSCSI / NFSクライアントでddまたはiometerを使用すると、最大20Mbpsに到達します（これはタイプミスではありません。20Mbps）。Synologyの複数のGbit NICをより有効に活用したいと思っていました。 スイッチとNICポートの設定が自動ネゴシエートではなくギガビットに設定されていることを確認しました。ジャンボフレームを使用した場合と使用しない場合で違いはありません。pingでMTUが現在9000であることを確認しました。2つのファームウェアアップグレードが展開されています。 スイッチの問題を除外するために、iSCSIターゲットとイニシエーター間の直接リンクを試しますが、他のオプションは何ですか？ 私はwireshark / tcpdumpを壊した場合、何を探しますか？

9 performance  nfs  iscsi  troubleshooting 

数日前、ディスクI / Oの待機とディスクアクティビティの低下に気付きました（これは素晴らしいことでした）。次に、キャッシュがいっぱい（*）で断片化していることにも気付きました。次に、キャッシュをフラッシュしました。その後、ディスク遅延とディスクアクティビティは以前のレベルに跳ね上がりました（これは悪かった）。 IOtopは、[jbd2 / sda2-8]と[flush-8：00]が常にディスク使用率の上にあることを示しています。これは、Dell R210、ハードウェアRAID 1（H200）、大量の空きメモリ（合計16 GB、そのうち約8 GBがバッファ/キャッシュ）です。 （*）キャッシュはPHP用のAPC opcodeキャッシュであり、PHPスクリプト実行のためのディスクアクセスを削減します。開発インスタンスのファイルが含まれているため、キャッシュがいっぱいで断片化していました。それに気づいたとき、私はそれらを除外しました。 問題は、理論的にはディスクI / Oが減少するはずなのに、なぜ増加するのかということです。以下は、muninのグラフです。2月6日から8日までキャッシュがいっぱいでした。 @ cyberx86の指示に従ってapc.mmap_file_maskをコメントアウトした後の変更 そして数日後https://serverfault.com/a/362152/88934

9 hard-drive  cache  performance 

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

9 mysql  performance  logging  io 

単一のApacheサーバーでクライアント用に約300のドメインをホストしています。これらはすべてトラフィックが少ないため、サーバーの負荷は問題になりません。 理論的には、サーバー上にこのようなトラフィックの少ないドメインの数を制限する必要はありませんが、サーバー上にドメインが多すぎると、各着信要求をチェックするためのドメインの純粋なリストにより、Apacheが遅くなるのではないかと心配しています。ダウン。 Apache構成がどれだけ長くなることができ、問題なく処理できるさまざまなドメインがいくつあるかという経験則はありますか？500は大丈夫ですか？5000？ 明確化：サーバーが処理できるトラフィック量については尋ねていません。この特定のサーバーは、現在のトラフィックの少なくとも2倍の量を処理できることを知っています。ドメインの数が重要な要素であるかどうかを知りたいです。

9 apache-2.2  performance  configuration  domain 

Windows 2008仮想マシン内で実行されているお客様の1人で、ソフトウェアが異常な動作をしているのを目にしています。ホストはVMWare ESX Serverです。 私が見た最大の問題は、プロセスがソケット接続をドロップするか、ソケット接続がタイムアウトすることです。一部のプロセスは、TCPソケットを介して相互に通信します。場合によっては、リモートシステム（WMI、JDBCなど）へのソケット接続を作成します。 VMのリソースが不足していると思います。ESX管理/パフォーマンスダッシュボードにはアクセスできません。また、ホストVM内のperfmonまたはタスクマネージャーが提供する数値は、ホストOSの正常性を正確に示すものではないことも学びました。 一連の浮動小数点演算を行い、かかった時間を出力するプログラムを書くことができます。次に、その時間を、異なるVMまたは実際のWindowsボックスで取得したものと比較します。 このアプローチは、根本的な原因が本当にVMのパフォーマンスであるかどうかを判断するのに十分です。ただし、これを行うための標準的な方法またはツールがあれば、顧客を納得させる方がはるかに簡単です。 ありますか？

9 performance  vmware-esx 

「昔に」私たちは常にOSドライブ（Windows）をデータドライブから分離しました。Linuxの世界では、あまり慣れていませんが、知恵によって、ベストプラクティスの構成で定義および使用されるボリュームがさらに増えることがわかっています。 サーバーストレージがSAN（ディスクリソースが多くの個々のオペレーティングシステムとアプリケーションによって共有されている）上にある可能性が高いので、OSとデータパーティションをボリュームレベルで分離することは本当に重要ですか？ あなたの考えは何ですか？

9 windows  performance  best-practices 

システムのCPU時間を大量に消費しているプロセスがいくつかあります（vmstatを確認することで判断）。行われているシステムコールの種類を簡単に確認する方法はありますか？ straceがあることは知っていますが、より速くて簡単な方法はありますか？システムコールの「トップ」のようなものはありますか？

9 linux  performance  monitoring  central-processing-unit  strace 

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

9 linux  performance  io  scaling 

NTFSを使用してドライブをフォーマットします。これは、ユーザーがファイルを一元的に保存するためのファイル共有として専用になります。ファイルは大きくなる可能性があります（数十から数百メガバイト）。 だれかが、デフォルトの4k（たとえば64k）よりも大きいアロケーションユニットサイズを使用すると、パフォーマンスが向上することを示唆しました。その背後にある基本原則は理解していると思いますが、実際に有効かどうかはわかりません。これは本当に違いを生むのでしょうか、それとも解決するよりも多くの問題を引き起こす可能性があるのでしょうか？

9 windows  performance  ntfs 

さて、まず第一に、私は運用担当者ではなく開発者であると言っておきます。なので、ここで少し未知の土地に行きますので、ご容赦ください。 Azure仮想マシンを使用して、1.9 GBのzipファイルから50 GBのXMLファイルを抽出したいと思います。したがって、私はAzureでどのインスタンスサイズを使用して、必要以上のコストをかけずに優れたパフォーマンスを実現するかをテストしてきました。 ただし、Azure VMのディスクパフォ​​ーマンスは驚くべきものではありません。何か問題を起こしているのが私なのか、それとも期待どおりの結果が得られるのかを知りたいのですが。 まず第一に、私は何をテストしてきましたか？カスタムの.NETコンソールアプリケーションがあり、それはzipファイルを引数として取り、すぐにzipファイルが存在する同じディレクトリにzipファイルの抽出を開始します。抽出の進行中に、アプリケーションはメガバイト数を計算しますアプリケーションは1秒あたりのターゲットファイルに書き込み、それを出力します。 私のローカル開発マシンでは、このアプリケーション（160〜210 MB /秒の書き込み）でかなり良いパフォーマンスを得ています。したがって、抽出プロセス全体には約8分かかります。私のローカルマシンの仕様は、Intel Core i7 950、3 GHz、4コア（8論理）、12 GB RAM、Samsung SSD 830シリーズ250 GBです。 さて、私はさまざまなインスタンスサイズのテストを始めました、そしてここに私の結果があります。 Windows Server 2012 Datacenter R2（8コア、14 GB RAM）を備えたA4インスタンスで、同じストレージアカウントを使用する4つの仮想ディスクのストライプRAIDを使用し、ホストキャッシュを使用しない場合、30〜35 MB /秒で安定しました。抽出には24分48秒かかりました。ホストキャッシングを有効にすることも試みましたが、実際には違いはありませんでした。 Windows Server 2012 Datacenter（8コア、28 GB RAM、500 GBローカルSSDディスク）を備えたD4インスタンスで、最初の数分間は本当に良いパフォーマンス（150+ MB /秒）を達成し、ピーク時は200 MB /でパフォーマンスを変化させました9 MB /秒の谷と谷。平均パフォーマンスは70〜100 MB / sでした。抽出には9分40秒かかりました。 Windows Server 2012 Datacenter（4コア、14 GB …

9 performance  storage  windows  azure 

異常に遅いRedmineインスタンス（Bitnami Stack）があります。私はこれの根底に到達しようとしているだけなので、ここで議論したいいくつかの理論があります。だから、もし誰かがこれについて何か考えを持っているなら、遠慮なく助けてください:-) システム： Redmine 1.4.xのBitnami Stackは、次のようにRedmine 2.1.0のBitnami Stackにアップグレードされました。 mysqldumpで古いデータベースを作成 Redmine 2.1.0で新しいBitnami Stackをインストールしました すべてのテーブルを再作成してダンプをきれいにインポートしました rake db：migrateなど スタックはOpenSUSE 12.1の仮想マシンで実行されています。空き容量は常に数ギガバイトあり、RedmineリクエストでのCPUスパイクは2 CPUコアの最大50％に過ぎないため、リソースは問題になりません。また、アクセスするユーザーはごくわずかです。 何が非常に重要かもしれません：ユーザーのログインはLDAP（ActiveDirectory）を介して処理されます。 問題： Redmineはリクエストごとに異常に遅い反応を示します。ページが配信されるまでに3秒、場合によっては最大10秒かかることもあります。 私の考え： RedmineのLDAP設定で「オンザフライユーザー作成」がチェックされているかどうかはわかりませんが、今日確認できるのは後日のみです。しかし、ここでのチェックの欠如が問題になるのでしょうか？ログインが正常で承認されると、認証に時間がかかります。しかし、その場でユーザーを作成しない場合、それはセッションのみを維持するのですか、それとも各リクエストで再認証するのですか？ Redmine 2.xは1.4.xよりもかなり遅いので、それは普通のことです。 BitnamiのApache2 + Passenger構成に問題がありますか？ MySQLのインデックスは、MySQLがCPUで非常に落ち着いているという事実を考えると問題ではないでしょうか？ 私には非常に奇妙に思われるもう1つのことですが、おそらく誤った測定結果です（マシンを確認したときに、明日これを再確認する必要があります）。 私はそれがネットワークの問題（ネットワークの反応が遅い、おそらくDNSか何か、サーバーがローカルネットワークにある）かどうかを確認しようとしました。ローカルホスト（OpenSUSE VMの直接ブラウザ）でのリクエストは高速であるように見えましたが、ネットワーク経由のリクエストは高速ではありませんでした。通常、私はネットワークの問題について考えますが、奇妙なことは、実際に接続時間を測定するとき、ネットワークは非常に速いということです。pingは良い、静的な配信時間も。Redmine側で計算されたページのみがアプリケーションサーバーからゆっくりと送信されているように見えましたが、Apacheは高速ですが、リクエストがリモートLANリクエストである場合のみです。非常に奇妙ですが、前述のとおり、これを再確認する必要があります。それは私には不合理に思えます。

9 networking  performance  ldap  redmine 

4 * 2 TBのディスクで構成されるLinuxソフトウェアRAIDレベル5をセットアップしました。ディスクアレイは64kのストライプサイズで作成され、他の構成パラメーターはありません。最初の再構築後、ファイルシステムを作成しようとしましたが、このステップには非常に時間がかかります（約30分以上）。私はxfsとext3ファイルシステムを作成しようとしましたが、どちらも長い時間がかかりました。mkfs.ext3を使用して、次のような動作が確認できました。 iノードテーブルの書き込みは、1053（〜1秒）に達するまで高速で実行され、その後約50を書き込み、2秒待機してから、次の50が書き込まれます（コンソールの表示によると）。 Control + Cで操作をキャンセルしようとすると、本当にキャンセルされる前に30分間ハングします 個々のディスクのパフォーマンスは非常に良好です。それぞれのディスクで個別にbonnie ++を実行し、約95 / 110MB /秒の書き込み/読み取り値を使用しています。すべてのドライブでbonnie ++を並行して実行した場合でも、値は約10 MBしか減少しません。したがって、ハードウェア/ I / Oのスケジューリングは一般的に問題の原因として除外しています。 stripe_cache_sizeとreadahead sizeのさまざまな構成パラメーターを試してみましたが、成功しませんでしたが、ファイルシステムの作成操作に関係があるとは思いません。 サーバーの詳細： Linuxサーバー2.6.35-27-generic＃48-Ubuntu SMP x86_64 GNU / Linux mdadm-v2.6.7.1 これをさらにデバッグする方法について誰かが提案をしていますか？

9 linux  performance  raid  software-raid 

私は定期的に、テストに使用される小さなPostgreSQLデータベースを保存して後で復元しています。テストの結果、そのデータは定期的に更新されます。その後、新しいダンプを作成する必要があります。ダンプは、明確に定義された状態でデータベースを再作成するために定期的に使用されます。 ダンプ（を使用pg_dump -Fc database）には数秒しかかかりませんが、復元（pg_restore -d database）には約1分かかります。これは奇妙なようです。両方にほぼ同じ時間がかかると予想していました（両方のタスクがI / Oバウンドであると仮定した場合）。 復元に問題がありますか？もっと速くできますか？あるいは、ダンプよりもリストアに時間がかかるのは正常ですか？（もしそうなら、なぜですか？） ダンプファイルには通常約3〜4 MiBがあります。DBMSはPostgreSQL V8.4であり、Ubuntu Linuxの下で1GiB RAMを搭載したPentium4 3GHzで実行されます。

9 performance  postgresql  database-backup