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

約1000万行（または7GB）からなる非常に大きなInnoDBテーブルを一括インポートするのに苦労しています（これは、これまでに作業した中で最大のテーブルです）。 Innoのインポート速度を改善する方法を調査しましたが、今のところ、私のセットアップは次のようになっています。 /etc/mysql/my.cnf/ [...] innodb_buffer_pool_size = 7446915072 # ~90% of memory innodb_read_io_threads = 64 innodb_write_io_threads = 64 innodb_io_capacity = 5000 innodb_thread_concurrency=0 innodb_doublewrite = 0 innodb_log_file_size = 1G log-bin = "" innodb_autoinc_lock_mode = 2 innodb_flush_method = O_DIRECT innodb_flush_log_at_trx_commit=2 innodb_buffer_pool_instances=8 import is done via bash script, here is the mysql code: SET …

10 mysql  performance  innodb  import 

私たちのエンタープライズアプリケーションは、データストレージにSQL Serverを使用し、主にOLTPシステムです。ただし、アプリケーションの重要なコンポーネントは、重要なOLAPワークロードを生成します。 tempdbへの書き込み待ち時間は約100msです。この傾向は、時間をかけて保持し、ALLOW_SNAPSHOT_ISOLATION投入されるオフ。私たちはこれに関して問題のトラブルシューティングを行っていますが、これまでに見つかった唯一の興味深いことは、tempdbへのハッシュとソートの流出が非常に多いことです。これはOLAPワークロードによるものだと思います。 質問 流出の頻度はどの程度ですか？どれか？1秒あたりの流出回数は？予備データによると、毎秒約2回のハッシュ流出と1分あたり25回のソート流出があります。 この流出の頻度が、tempdbの書き込み待ち時間が長い主な原因である可能性はありますか？ その他の情報 コアの数ごとに推奨されているように、tempdbには複数のファイルを使用しています。tempdbファイルはRAID 1 + 0 SAN（高性能SSDを搭載）上にありますが、これはメインのDBデータおよびログファイルと同じデバイスです。tempdbファイルのサイズは、非常にまれに大きくなるほど大きくなっています。トレースフラグ1117または1118は使用していません。別の変数は、このセットアップが、すべて中程度から高い負荷を経験する多くの異なるデータベースで共有されていることです。 100ミリ秒の書き込みレイテンシは、MSDN、SQLスキル、その他のサイトで見つかったtempdb書き込みレイテンシの許容範囲よりもはるかに大きくなっています。ただし、他のデータベースの書き込みレイテンシは良好です（10ミリ秒未満）。他の統計に基づいて、tempdbを特に内部オブジェクトに対して頻繁に使用しているようです。したがって、アプリケーションが内部オブジェクトを非常に多く使用している理由を調べるために掘り下げています。 私たちのプラットフォームには、さまざまな形で現れる実際のパフォーマンスの問題があります。私たちはパフォーマンスカウンターを監視し、DMビューを確認し、アプリの動作を分析して、システムのリソース使用特性を掘り下げようとしています。流出はメモリ内ではなくディスク上で実行されるため、流出は劇的な悪影響をもたらすことがわかっているため、現時点では流出に焦点を当てています。また、流出の数は非常に多いようですが、人々が「高」と見なしていることについて何らかの情報を入手したいと考えていました。

10 sql-server  performance  tempdb 

リアルタイムのGPSデータを約5000 prのレートで受信します。分（4つのTCPサーバーから）。各サーバーは単一の接続を使用してデータを挿入し、挿入と挿入の間でデータをバッファーします。15分ほどごとに、サービスがこのデータをフェッチし、それをトリップに処理します。旅行が生成されたら、実際のGPSデータは通常、それほど重要ではありません。ユーザーが地図上でルートを確認したい場合のみです。 問題は、データベースが挿入されるデータの速度に追いつくのに苦労しているように見えることです。負荷が増加すると、挿入時間が急激に増加し（> 30秒）、その結果、より多くのデータをバッファリングできるようになり、その結果、挿入が大きくなり、挿入時間が長くなります。 現在のデザイン、パフォーマンスを改善するために必要ないくつかのアイデア、いくつかの質問への回答、および人々が持っている可能性のあるその他のヒントについて、いくつかコメントをいただければ幸いです。 現在のデザイン 現在、データは1週間を表すテーブルに分割されており、1年以上経過したデータはセカンダリデータベースにアーカイブされます。挿入と読み取りの両方に使用される編集可能なビューで全体が結合されます。 テーブルデザイン Id（PK、uniqueidentifier） DeviceId（FK、int） PersonId（FK、int） VehicleId（FK、int） TokenId（FK、int） UtcTime（PK、datetime2（3）） 緯度（float） 経度（float） 速度（smallint） 見出し（smallint） 衛星（tinyint） IOData（varbinary（100）） IgnitionState（tinyint） UserInput（tinyint） CreateTimeUtc（datetime2（3）） 指数 DeviceId_CreateTimeUtc_Desc DeviceId_UtcTime_Desc（クラスター化） PersonId_UtcTime_Desc TokenId_UtcTime_Desc VehicleId_UtcTime_Desc 現在、毎週、インデックスを含めて約10 GBを占めています。現在、メインデータベースには約300 GBのデータがあります。 メインデータベースのデータテーブルには、1つのファイルを持つ独自のファイルグループがありますが、メインデータベースの他のすべてのテーブルと同じディスク上にあります。セカンダリデータベースは別のディスクにありますが、同じマシン上にあります。 新しいテーブルパーティション（週）が使用されるときに、インデックスの再構築ジョブも毎週実行していると思います。縮小は行われません。 マシンは12 GBのメモリを搭載した8コアHPであり、メインデータベースを保持するディスクはRAID 10を実行しています。 アイデア プライマリデータベースに保存されるデータの量を、たとえば最大1か月に制限します。少なくとも、データベースをバックアップ/復元用に管理しやすくなりますが、これによりパフォーマンスの向上が見込めますか？ 現在のデータのファイルグループに2つのファイルを作成し、それらを2つの異なる物理パーティションに配布する 現在のデータを保持するマスタースレーブデータベースを作成して、挿入と読み取りが異なるデータベースで実行されるようにする 現在のデータのファイルをSSDディスクに配置します（ミラーリングによりSSDディスクとのパフォーマンスに違いが生じますか？） さらに情報が必要な場合はお知らせください。パフォーマンスに影響を与える恐ろしいほど多くの要因があり、おそらくそれを調整する多くの方法があります。

10 sql-server  database-design  performance  vldb 

Nagiosスクリプトを使用してPostgresデータベース上のデータベース接続の数を監視しようとしたところ、この問題が発生しました。これらは現在開いている接続としてカウントされ、5分ごとに測定されます。 SELECT sum(numbackends) FROM pg_stat_database; それでも、これは多数の短期間の接続を見逃しているようで、統計は現実とはかけ離れています。 スクリプトを手動で実行してみましたが、2秒の接続が数秒離れた2つの接続の間でも大きな変化が見られました。 この情報を信頼できる方法で取得するにはどうすればよいですか？時間間隔中に発生したmax（connectios）など。

10 postgresql  performance  monitoring 

誰かがこれらのクエリを比較して、PostgreSQLクエリが2000ミリ秒未満で実行され、MongoDB集計クエリがほぼ9000ミリ秒、時には130Kミリ秒もかかる理由を説明できますか？ PostgreSQL 9.3.2 on x86_64-apple-darwin, compiled by i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00), 64-bit PostgreSQLクエリ SELECT locomotive_id, SUM(date_trunc('second', datetime) - date_trunc('second', prevDatetime)) AS utilization_time FROM bpkdmp WHERE datetime >= '2013-7-26 00:00:00.0000' AND datetime <= '2013-7-26 23:59:59.9999' GROUP BY locomotive_id order by locomotive_id MongoDBクエリ db.bpkdmp.aggregate([ …

10 performance  mongodb  postgresql 

パフォーマンスの問題を調査しているときに、CXPACKETSへの流入があり、並列処理のコストしきい値と、おそらくMAXDOPを調べる必要があるかもしれないと示唆しています。 MAXDOPに大幅な変更を加える前に、SQL Server 2008のCXPACKET Waitsパフォーマンスチューンへの回答での@mrdennyの回答や、CXPACKET待機への対処からの@ aron-Bertrandの回答-コストしきい値の設定など、他の多くのアドバイスに従っています平行性について。統計情報を毎晩完全に更新するために、メンテナンスに追加しました。これは賢明な動きのように感じます。 ただし、コストのしきい値に変更を加えることはまだ私を悩ませるものです。 並列処理のコストしきい値はどの時点で変更する必要がありますか？（クエリとワークロードのコストを調べた後）このコストに変更を加えた例はありますか？ これが前の質問で回答されたものである場合は謝罪します。 ありがとう！

10 sql-server  performance 

複数のサーバー上のデータベースからのデータを必要とする新機能を実装しています。これらすべてのサーバーのデータを結合して並べ替えるだけです。頭に浮かぶ2つのオプションは次のとおりです。 リンクサーバーを使用して簡単なクエリを作成し、1つのサーバーから実行して他のサーバーからデータを収集するデータを結合して並べ替えます。 アプリケーションを使用してすべてのサーバーからデータを収集し、それをSQL Serverに返して並べ替えます（アプリケーションに並べ替えを実装しないでください）。 SQL Server 2008 r2では、アクティブ/アクティブクラスターでサーバーを実行しています。すべてのデータベースに同じ権限があり、1つのデータベース/サーバーにアクセスできる場合は、それらすべてに権限があります。これは一般向けアプリケーションです（ユーザーログインが必要です）。 リンクサーバーを使用するリスクは何ですか？心配すべきセキュリティ上の欠陥はありますか？アクティブ/アクティブクラスターでリンクサーバーを実行するときに問題はありますか？他の方法と比較して、パフォーマンスに重大な問題はありますか？ リンクサーバーに関する一般的な否定的な「話題」があるようですが、実際に懸念があると思わせるような具体的な情報は見つかりません。

10 sql-server  sql-server-2008  performance  security  linked-server 

MySQLデータベースの1つで単純なテーブルを作成すると、時間がかかります。 mysql> CREATE TABLE blah (id BIGINT UNSIGNED NOT NULL PRIMARY KEY); Query OK, 0 rows affected (16.58 sec) マシンはかなりアイドル状態です： 01:21:26 PM CPU %user %nice %system %iowait %steal %idle 01:21:27 PM all 0.50 0.00 0.21 0.00 0.00 99.29 これを調査する方法はありますか？ 編集：DTestのアドバイスに従って、これは実行プロファイルです： mysql> SHOW PROFILE FOR QUERY 1; +----------------------+----------+ | Status | …

10 mysql  performance 

非常にトラフィックの多いWebサイトを使用しており、毎時間数千の新しいレコードが挿入される可能性があります。 この1つのエラーがサイトに障害をもたらしています。 PDOException: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction: INSERT INTO {location_instance} (nid, vid, uid, genid, lid) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4); Array ( [:db_insert_placeholder_0] => 1059 [:db_insert_placeholder_1] => 1059 [:db_insert_placeholder_2] => 0 [:db_insert_placeholder_3] => cck:field_item_location:1059 [:db_insert_placeholder_4] => 1000 ) MySQLがこのタイプの負荷を処理できなかった場合、私は非常に驚きます。それで、私の質問は、データベースの問題ですか？これだけのトラフィックを処理できるようにMySQLを構成するにはどうすればよいですか？ …

10 mysql  performance  innodb  deadlock  insert 

効率的に分割したい大きなテーブル（数億行）があります。私の質問は、パーティションサイズとパーティション数の間にトレードオフがあるかどうかです。私が理解している限り、クエリは（ほとんどのクエリに対して）クエリに適用可能なパーティション内のみを検索する必要があるため、パーティションで使用される列に対するほとんどのクエリはより高速になります。したがって、効率を最大化するには、大きなテーブルを最大数のパーティションに分割する必要があるので、各パーティションをできるだけ小さくする必要があります。MySQLの場合、これは1024パーティションを意味します。しかし、多数のパーティションを持つことにはパフォーマンス上の欠点がありますか？そうであれば、どのようにして最適なパーティション数を見つけるのでしょうか？ 注：stackoverflowについては多少似た質問がすでにありますが、（私の観点から）マークを逃す答えは1つだけです。だから私は私自身の方法で質問を述べます...うまくいけばそれはより明確です

10 mysql  performance  partitioning 

科学的データ分析のためにワークステーションでMySQL 5.5サーバーを実行していますが、パフォーマンスを最大限に活用するためにMySQLを構成する方法を考えています。私が通常実行するクエリの種類には、10〜20のテーブルの結合が含まれ、非常に長く実行できます。1〜数分は例外ではありません。同時にデータベースにアクセスするユーザーはごくわずかです（最大5人）。2.2 GHzのデュアルコアと4 GBのRAMを搭載したLenovo Thinkpad T61から、コンポーネントを手動で選択した次の新しいマシンにサーバーを移動しました。 Intel i7 3770、4x 3.4 GHz（4x3.7 GHzで稼働） Z77チップセット 16 GBのDDR3 1600 RAM Windows 7 Prof 64ビット WindowsおよびMySQLサーバーはIntel 520シリーズSSDドライブで実行されます。 最初のテスト（両方のマシンで同じクエリを実行）は、新しいテストの速度の決定的な改善を示しましたが、クエリにはまだ多くの時間がかかり、さらに向上することを期待していました。問題のクエリはかなり適切に最適化されています。つまり、すべてのテーブルには、「拡張された説明」の時点でも使用されている適切なキーがあります。 さて、現在のMySQLの設定に戻ります。最初に、MyISAMからInnodbにかなり前に移動したことを述べておきます。 my.iniの調整の一部（つまり、デフォルト設定からの逸脱）： # Maximum size for internal (in-memory) temporary tables. If a table # grows larger than this value, it is automatically converted to disk # …

10 mysql  performance  innodb  mysql-5.5  mysql-5 

お客様のデータベースを追加のサーバーに移動した後、問題が発生しました。これはサイトのパフォーマンスにプラスの影響を与えるはずでしたが、MyISAMのテーブルロックに問題があります。（MyISAMの代わりにInnoDBを使用することを聞いたことがありますが、近い将来エンジンを変更することはできません）。 モデレーターが記事サイトのコメントをアクティブ化するときに実行されるupdate-queryにそれを見つけることができます。これはプロセスです： update-queryが処理されます SET status = 1 WHERE id = 5（インデックスが設定されます） ページのキャッシュファイルが削除されます この時点で、ページ全体が遅くなります。データベース自体は数分間ビジーです。私はプロセスリストを数回フェッチし、さまざまな選択クエリの約60のエントリを確認しました。これらはすべて、テーブルレベルのロックを待機している状態でした。 1.テーブルに対するこの更新が、テーブルレベルのロックを待機するテーブルのarticle_commentsselect-statementsに影響を与える理由がわかりませんarticle。プロセスリストでは、待機中のほとんどすべてのクエリがこのテーブルからのものでした。selectよりもupdate / insertが優先され、これがそのような問題を引き起こす可能性があるという事実を読みましたが、記事テーブル自体はコメントがアクティブになっても更新されないので、selectは待つべきではありません。私はそれを誤解しましたか？ 2.この動作を防止するため、または少なくともより良いバランスを得るために、InnoDBに変更する以外に何かありますか？データベースを新しいサーバーに移動する前にこの問題が発生しなかったという事実に非常に苛立ちました。いくつかの設定ミスがあると思いますが、特定する方法がわかりません。

10 mysql  performance  mysql-5.5  myisam  locking 

数百万行のテーブルがあり、そこからクエリを時々実行する必要があります。通常、最初のクエリは非常に遅くなり（約10秒）、その後のクエリは通常、かなり高速になります（約1秒）。数時間後、遅い/その後速いサイクルが再び始まります。 必要なすべてのインデックスが存在し、適切に使用されていることを実行プランで確認しました。パフォーマンスの違いは、インデックスが後続のクエリのために実際にメモリ内にあるためであると思います（私は正しいですか、それとも他にもあります）考えられる原因？） また、インデックスを使用して他の多くのクエリも実行していますが、これらのクエリは時間がかかりませんし、そのパフォーマンスはそれほど重要ではないため、これらのインデックスが実際に重要なインデックスをメモリキャッシュから押し出しているのではないかと心配しています。 「RAMを追加する」という明らかな修正とは別に、インデックスをメモリに強制的に戻すためにダミークエリを1時間ごとに実行するスクリプトを作成することを考えていました。 これを行うよりエレガントな方法はありますか？SQLServerに、1つの単一のインデックスをキャッシュするだけの十分なメモリがある場合、それをキャッシュする必要があることを示唆する方法と同様に、 私は通常、そのようなことに関してSQLServerを台無しにするのが最善ではないことを知っていますが、私のクエリの異常な性質（非常にまれに実行されますが、タイムクリティカル）は、それが理にかなっていると信じています（可能な場合） 。 また、特定の時点でどのインデックスがメモリにキャッシュされているかを知る方法があるかどうか知りたいです。

10 sql-server-2008  performance  index 

パフォーマンスの問題を診断するために、システムパフォーマンスと比較して、特定のプロシージャが呼び出される回数をよりよく理解したいと思います。特定の期間中に各プロシージャが呼び出された回数を取得する方法はありますか？

10 sql-server  performance  monitoring 

私はアイントホーフェンのFontys大学の学生です。現在、SQL Serverツールの開発を支援するために一連のインタビューを行っています。この分野の専門家からのフィードバックを希望しています。 私の質問の1つは： SQL Serverインスタンスでパフォーマンスと全体的な状態を判断するために、どのパフォーマンスカウンターを確認できますか？ 特に、善が悪くなるときのしきい値に興味があります。 ジャミルヤングアイントホーフェンオランダ

10 sql-server  performance