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

システムが目的に適合するほど十分に機能するかどうかの評価。通常、パフォーマンスとは、システムが1つの操作または一連の操作を時間の経過とともに完了する速度を指します。

1
複数のCOUNTがCASEの1つのSUMよりも速いのはなぜですか?
次の2つのアプローチのどちらが速いかを知りたかったのです。 1)3つCOUNT: SELECT Approved = (SELECT COUNT(*) FROM dbo.Claims d WHERE d.Status = 'Approved'), Valid = (SELECT COUNT(*) FROM dbo.Claims d WHERE d.Status = 'Valid'), Reject = (SELECT COUNT(*) FROM dbo.Claims d WHERE d.Status = 'Reject') 2)SUMとFROM-clause: SELECT Approved = SUM(CASE WHEN Status = 'Approved' THEN 1 ELSE 0 END), …

2
PostgreSQL TRIGGERのスケーリング
Postgresがメカニズムのスケールをトリガーする方法 PostgreSQLを大規模にインストールしており、ログテーブルとTRIGGERを使用してイベントベースのシステムを実装しようとしています。 基本的に、UPDATE / INSERT / DELETE操作の通知を受け取る各テーブルにTRIGGERを作成します。このトリガーが起動されると、ログテーブルに新しい行を追加する(イベントをエンコードする)関数を実行し、その後、外部サービスからポーリングします。 Postgres TRIGGERを使用する前に、それらがどのようにスケーリングするかを知りたいと思います。単一のPostgresインストールでいくつのトリガーを作成できますか?クエリのパフォーマンスに影響しますか?これを試す前に誰かがしましたか?

2
インデックス付き日時列を使用したMySQLパフォーマンスの問題
次の問題を約1時間解決しようとしましたが、それでも解決できませんでした。 さて、テーブルがあります(MyISAM): +---------+-------------+------+-----+-------------------+----------------+ | Field | Type | Null | Key | Default | Extra | +---------+-------------+------+-----+-------------------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | http | smallint(3) | YES | MUL | 200 | | | elapsed | float(6,3) | NO | | …

1
SOS_SCHEDULER_YIELD待機のトラブルシューティング
企業のERP(Dynamics AX 2012)を実行すると、実稼働環境が開発システムよりもはるかに遅いように見えました。 開発環境と実稼働環境の両方で同じアクティビティを実行し、トレースを実行した後、開発環境と比較して実稼働環境でのSQLクエリの実行が非常に遅いことを確認しました(平均で10〜50倍遅い)。 最初はこれをロードに起因すると考え、営業時間外に本番環境で同じアクティビティを再実行し、トレースで同じ結果を見つけました。 SQL Serverで待機統計をクリアし、しばらくの間、サーバーを通常の運用負荷で実行させた後、次のクエリを実行しました。 WITH [Waits] AS (SELECT [wait_type], [wait_time_ms] / 1000.0 AS [WaitS], ([wait_time_ms] - [signal_wait_time_ms]) / 1000.0 AS [ResourceS], [signal_wait_time_ms] / 1000.0 AS [SignalS], [waiting_tasks_count] AS [WaitCount], 100.0 * [wait_time_ms] / SUM ([wait_time_ms]) OVER() AS [Percentage], ROW_NUMBER() OVER(ORDER BY [wait_time_ms] DESC) AS [RowNum] FROM sys.dm_os_wait_stats …

4
良い、悪い、または無関心:WHERE 1 = 1
redditに関するこの質問を踏まえて、クエリをクリーンアップして、クエリのどこに問題があるのか​​を指摘しました。最初にコンマを使用しWHERE 1=1、クエリの変更を簡単にするため、クエリは通常、次のようになります。 SELECT C.CompanyName ,O.ShippedDate ,OD.UnitPrice ,P.ProductName FROM Customers as C INNER JOIN Orders as O ON C.CustomerID = O.CustomerID INNER JOIN [Order Details] as OD ON O.OrderID = OD.OrderID INNER JOIN Products as P ON P.ProductID = OD.ProductID Where 1=1 -- AND O.ShippedDate Between '4/1/2008' And '4/30/2008' And P.productname …

4
MySQLのLOAD DATA INFILEは、InnoDBエンジンでの入力のいくつかのギグの後、80%遅くなります
LOAD DATA INFILEを介して100GBのファイルをロードしています。私はMyISAMで数時間成功しました。 私は今InnoDBを使って試しています。ロードは10MB /秒以上で高速に開始されます(テーブルファイルの増大を監視し、file_per_tableオンになっています)。 しかし、約5 GBのデータの後、2〜4 MB /秒の範囲に低下します。20GBを超えると、約2 MB /秒になりました。 InnoDBバッファープールのサイズは8Gです。そして、LOAD DATA INFILEコマンドを実行する前に次のことを行いました。 SET @@session.sql_log_bin=0; SET autocommit=0; SET unique_checks=0; SET foreign_key_checks=0; alter table item_load disable keys; //Run LOAD DATA INFILE.... 開始が順調に進み、時間がたつにつれて速度が低下している理由がわかりません。 また、同じ設定を使用して、InnoDBとMyISAMおよび5GBテストデータセットを使用したテーブルで同じLOAD DATA INFILEコマンドを実行すると、MyISAMは20倍高速になりました。 InnoDB: mysql> LOAD DATA CONCURRENT LOCAL INFILE '/tmp/item' REPLACE INTO TABLE item_load; Query OK, 2630886 …

4
数百万行の狭いテーブルでクエリのパフォーマンスを向上させることは可能ですか?
現在、クエリの完了に平均2500msかかっています。私のテーブルは非常に狭いですが、4,400万行あります。パフォーマンスを改善するためにどのようなオプションが必要ですか、またはこれは得られるほど良いですか? クエリ SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats] WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31'; テーブル CREATE TABLE [dbo].[Heartbeats]( [ID] [int] IDENTITY(1,1) NOT NULL, [DeviceID] [int] NOT NULL, [IsPUp] [bit] NOT NULL, [IsWebUp] [bit] NOT NULL, [IsPingUp] [bit] NOT NULL, [DateEntered] [datetime] NOT NULL, CONSTRAINT [PK_Heartbeats] PRIMARY KEY CLUSTERED ( [ID] …

3
ストアドプロシージャのスケーラビリティのテスト
各ページの読み込みで特定のユーザーの新しいメッセージの数をUIに配信するために呼び出される電子メールアプリケーションがあります。DBレベルでテストしているものにはいくつかのバリエーションがありますが、すべてストアドプロシージャコールによって抽象化されています。 私は、ブレークポイント(1秒あたりのリクエスト数)がどうなるかを確認するために、DBを強打しようとしています。 一言で言えば、このuserId、newMsgCountなどのテーブルとuserIdのクラスター化インデックスがあります。SQLは、1秒あたり数百または数千のこれらの応答を処理できる必要があります。遅れは私の.NETアプリだと思います。 SQLパフォーマンスに基づいてテスト結果を達成するために、これをどのように良いテストにすることができますか? これには、ストアドプロシージャ名とパラメーターを指定してDBをパンドするツールがありますか? DBが1分を返すことができるかどうかを見たいです。1秒あたり250応答。

3
SQL Server-一時テーブルと物理テーブル
私の職場では、#tempテーブルの使用をやめて、代わりにSPIDを含む永続的な物理テーブルを使用する動きが進行中です。以前に#tempテーブルにINSERTしたことがある場合は常に、たとえばストアドプロシージャの先頭にある一連INSERT INTO dbo.MyPermanentTable (SPID, ...) VALUES (@@SPID, ...)のDELETE FROM dbo.MyPermanentTable WHERE SPID = @@SPIDステートメントと共に、が必要になります。さらに、言うまでもなく、これらの「一時データを保存するための永続テーブル」が使用される場所では、を含めるように注意する必要がありますWHERE SPID = @@SPID。 このプラクティスへの移行の背後にあるロジックは、クエリが実行されているサーバーの全体的なパフォーマンスを向上させることです(tempdbのI / Oと競合を減らすことにより)。私はいくつかの理由でこのアプローチに熱心ではありません-く、潜在的に危険であり、新しいスキームを使用するクエリのパフォーマンスを損なう可能性があるようです。 #tempテーブルを削除するためのこれまたは類似のアプローチの経験はありますか?

2
SQL Server 2016の奇妙なパフォーマンス問題
VMware仮想マシンで実行されているSQL Server 2016 SP1の単一インスタンスがあります。異なるアプリケーション用の4つのデータベースが含まれています。これらのアプリケーションはすべて別々の仮想サーバー上にあります。それらのどれもまだ実稼働で使用されていません。ただし、アプリケーションをテストする人々はパフォーマンスの問題を報告しています。 これらはサーバーの統計です: 128 GB RAM(SQL Serverの場合は110 GBの最大メモリ) 4コア@ 4.6 GHz 10 GBitネットワーク接続 すべてのストレージはSSDベースです プログラムファイル、ログファイル、データベースファイル、およびtempdbは、サーバーの別のパーティションにあります asd ユーザーは、C ++ベースのERPアプリケーションを介して単一画面アクセスを実行しています。 ostress多くの小さなクエリまたは大きなクエリを使用してMicrosoftでSQL Serverのストレステストを行うと、最大のパフォーマンスが得られます。彼が十分に速く答えることができないので、スロットリングすることだけがクライアントです。 しかし、ユーザーがほとんどいない場合、SQL Serverはほとんど何もしていません。それでも、アプリケーションに何かを保存するために、人々は永遠に待つ必要があります。 ポールランダルの「どこが痛いのか教えて」クエリによると、すべての待機イベントの50%はASYNC_NETWORK_IOです。 これは、ネットワークの問題、またはアプリケーションサーバーまたはクライアントのパフォーマンスの問題を意味する可能性があります。どちらも、最大容量でリソースをリモートで使用していません。ほとんどの場合、CPUはすべてのマシン(クライアント、appserver、dbサーバー)で約26%です。 ネットワーク接続の遅延は約1〜3ミリ秒です。dbサーバーのIOは、アプリケーションで通常の使用中に最大20MB / sの書き込み速度です(avgは7-9MB / sです)。ストレステストを行うと、最大で約5GB /秒になります。 バッファキャッシュサイズは、ERPシステムのDBで60GB、ファイナンスソフトウェアで20GB、品質保証ソフトウェアで1GB、ドキュメントアーカイブシステムで3GBです。 SQL ServerアカウントにInstant File Initializationを使用する権利を与えました。少しでもパフォーマンスは向上しませんでした。 通常の使用中のページの平均寿命は約15k +です。予想される重いストレステストの終了中に約.05kに低下します。バッチ/秒は、ワークロードに応じて約2〜8kです。 私はERPアプリはひどく書かれていると思いますが、すべてのアプリケーションが影響を受けるのでできません。最小限の作業負荷でも。 しかし、私はこれを引き起こしているものを特定することはできません。ヒント、ヒントチュートリアル、アプリケーション、ベスト/ワーストプラクティスドキュメント、またはこの問題に関して皆さんが心に留めておくものはありますか? これらはからの結果ですsp_BlitzFirst: 600秒実行しました。アプリの負荷が高いときに開始しました。1/3の時間ASYNC_NETWORK_IOです。また、私はとのネットワーク接続をテストしNTttcp、PsPing、ipferf3、とpathping。珍しいことはありません。応答時間は最大3ms、平均0.3msです。スループットは約1000 MB / sです。 私の調査の結果、常にASYNC_NETWORK_IO一番のウェイトスタットになりました。 Large-Receive-OffloadVMware の機能を無効にした結果を調査しました。まだテスト中ですが、結果には一貫性がないようです。最初の 'ベンチマーク'の結果は19分間でした(一番上の結果は、アプリがSQL …

4
GROUP BYおよびORDER BYを使用した大きなテーブルでのクエリが遅い
次のような、720万タプルのテーブルがあります。 table public.methods column | type | attributes --------+-----------------------+---------------------------------------------------- id | integer | not null DEFAULT nextval('methodkey'::regclass) hash | character varying(32) | not null string | character varying | not null method | character varying | not null file | character varying | not null type | character varying | …

5
大きなテーブルでLEFT JOINを使用して非常に遅いSELECTを最適化する方法
私は何時間もグーグルで独学で解決策を探していましたが、運がありませんでした。ここではいくつかの同様の質問を見つけましたが、この場合は見つかりませんでした。 私のテーブル: 人(〜1000万行) 属性(場所、年齢、...) 人と属性の間のリンク(M:M)(〜40M行) フルダンプ〜280MB 状況:person_idいくつかの場所(location.attribute_value BETWEEN 3000 AND 7000)、性別(gender.attribute_value = 1)、生まれた年(bornyear.attribute_value BETWEEN 1980 AND 2000)、目の色(eyecolor.attribute_value IN (2,3))から すべての個人ID()を選択しようとしています。 これは私の魔女が3〜4 分かかったクエリです。最適化したい: SELECT person_id FROM person LEFT JOIN attribute location ON location.attribute_type_id = 1 AND location.person_id = person.person_id LEFT JOIN attribute gender ON gender.attribute_type_id = 2 AND gender.person_id = person.person_id …

2
推定実行計画を表示すると、CXPACKET、PAGELATCH_SH、およびLATCH_EX [ACCESS_METHODS_DATASET_PARENT]の待機が生成されます
にmax degree of parallelism設定し2、にcost threshold for parallelism設定した4 vCPU VMでMicrosoft SQL Server 2016 SP2-CU6(13.0.5292.0)を実行しています50。 朝、SELECT TOP 100クエリの推定実行プランを表示しようとすると、大量の待機が発生し、推定プランをレンダリングする操作に数分、多くの場合5〜7分の範囲で時間がかかります。繰り返しますが、これはクエリの実際の実行ではなく、推定実行プランを表示するプロセスです。 sp_WhoIsActivePAGEIOLATCH_SH待機またはLATCH_EX [ACCESS_METHODS_DATASET_PARENT]待機のいずれかが表示され、操作中にポールランダルのWaitingTasks.sqlスクリプトを実行すると、待機が表示されるCXPACKETワーカースレッドでPAGEIOLATCH_SH待機が表示されます。 *リソースの説明フィールド= exchangeEvent id=Port5f6069e600 WaitType=e_waitPortOpen waiterType=Coordinator nodeId=1 tid=0 ownerActivity=notYetOpened waiterActivity=waitForAllOwnersToOpen ワーカースレッドは、statsテーブル全体をメモリに格納しているように見えます(Paul Randalのクエリから表示されるこれらのページ番号および後続のページ番号は、statsテーブルのクラスタ化キーに戻ります)。プランが戻ってくるstatsと、さまざまなレコードが残っているだけでキャッシュからテーブルの大部分が失われた後でも(同様のクエリからのシーク操作のためにプルされたと仮定します)、基本的に1日の残りの時間は瞬時です。 クエリが実際にSCAN演算子を使用するプランで実行されている場合、この初期動作を期待しますが、上記のリンクされたプランに示されているように、SEEKオペレーターに到達するためだけに実行プランを評価するときにこれを行うのはなぜですか?ここでのパフォーマンスを向上させるために何ができますか(営業時間前にこのステートメントを実行してデータを適切にキャッシュする以外に)。一対のカバリングインデックスが有益であると考えていますが、実際に動作の変更を保証しますか?ここで、ストレージとメンテナンスウィンドウの制限内で作業する必要があります。クエリ自体はベンダーソリューションから生成されるため、この時点で他の提案(より良いインデックス付け以外)を歓迎します。

2
差分バックアップを行うときにバッチ要求が増加するのはなぜですか
2012年のSQL Serverでのさまざまなアクティビティの長期追跡を開始しましたが、増分バックアップ中にバッチリクエストが増加していることに気付きました。 アイデアを提供するために、通常の日常的なバッチリクエストは1秒あたり約10〜20ですが、差分バックアップの実行中は1秒あたり100〜130に跳ね上がります。 私はこれがそれほど多くないことを知っていますが、それが何が起こっているのか興味がありました。 この問題のトラブルシューティングに役立つ情報がわからない。

1
大規模データベースクエリの最適化(2500万行以上、max()およびGROUP BYを使用)
私はPostgres 9.3.5を使用しており、データベースに大きなテーブルがあります。現在は2500万行以上あり、急速に大きくなる傾向があります。次のような簡単なクエリを使用して、特定の行(すべてunit_idのsに最新のもののみを含む)を選択しようとしていますunit_timestamp。 SELECT unit_id, max(unit_timestamp) AS latest_timestamp FROM all_units GROUP BY unit_id; インデックスがない場合、このクエリの実行には約35秒かかります。定義されたインデックス(CREATE INDEX partial_idx ON all_units (unit_id, unit_timestamp DESC);)を使用すると、クエリ時間は約(わずか)19秒に短縮されます。 クエリをさらに短い時間(ほんの数秒など)で実行できるようになるのではないかと考えています。その場合、クエリをさらに最適化するにはどのような手順を実行する必要がありますか。 テーブル構造のダンプは次のようになります。 CREATE TABLE "all_units" ( "unit_id" int4 NOT NULL, "unit_timestamp" timestamp(6) NOT NULL, "lon" float4, "lat" float4, "speed" float4, "status" varchar(255) COLLATE "default" ) ALTER TABLE "all_units" ADD PRIMARY …

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.