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

私が取り組んでいるデータ処理システムのパフォーマンスに問題があります。大量のCXPACKETおよびLATCH_EX待機イベントを示す1時間のperoidから待機統計を収集しました。 システムは3つの処理SQL Serverで構成され、多数の数値計算と計算を実行してから、中央のクラスターサーバーにデータを供給します。処理サーバーでは、一度に最大6つのジョブを実行できます。これらの待機統計は、ボットネックを引き起こしていると思われる中央クラスターに関するものです。中央クラスタサーバーには、16コアと64GB RAMがあります。MAXDOPは0に設定されます。 CXPACKETは実行中の複数の並列クエリからのものであると思いますが、LATCH_EX待機イベントが何を示しているのかわかりません。私が読んだことから、これは非バッファ待機かもしれませんか？ これらの種類の待機統計の原因が何であるか、このパフォーマンス問題の根本原因を調査するために私が取るべき措置は何ですか？ 上位のクエリ結果は合計待機統計であり、下位のクエリ結果は1時間の統計です。

13 sql-server  performance  query-performance  parallelism  wait-types 

テーブルが与えられた場合： Column | Type id | integer latitude | numeric(9,6) longitude | numeric(9,6) speed | integer equipment_id | integer created_at | timestamp without time zone Indexes: "geoposition_records_pkey" PRIMARY KEY, btree (id) このテーブルには2000万件のレコードがありますが、比較的多くはありません。ただし、シーケンシャルスキャンが遅くなります。 max(created_at)それぞれの最後のレコード（）を取得するにはどうすればよいequipment_idですか？ 私はこのトピックの多くの回答を読んだいくつかのバリエーションを使用して、次の両方のクエリを試しました： select max(created_at),equipment_id from geoposition_records group by equipment_id; select distinct on (equipment_id) equipment_id,created_at from geoposition_records order by …

13 postgresql  performance  index  greatest-n-per-group 

私は小さな会社の一員なので、いつものようにさまざまな役割を担当しています。最新のものは、.NET Webアプリ専用のSQL Serverボックスを調達しています。32 GBのRAMを備えたデュアルXeon E5-2620（6コア）2.00 GHz CPU構成（合計12コア）で引用されています。これにより、ディスクアレイの予算が制限され、基本的にRAID 1構成の2つの2.5インチSAS 300 GBドライブ（15k RPM）で構成されます。 ディスクのセットアップがSQL Serverにとって最適ではないことを知っているので、データベース、ログファイル、およびtempdbを独自のドライブに配置できるように、RAID 10をプッシュしたいと考えています。これを予算と両立させるには、CPUコアの数を減らすことを検討する必要がありますか？それとも、コアを保持し、使用するドライブを少なくして、おそらくデュアルRAID 1セットアップで4台を使用することで、より良い銀行を獲得できますか？ 追加の統計情報は次のとおりです SQL Serverデータベースは、おそらく80％対20％の多数の読み取りから書き込みに傾いています。現在のDBサイズは現在約10 GB、 26 GBで、1か月あたり250 MBの割合で増加しています。 現在、Webサーバー（RAID 1の12 GB Ram、2 x 10k 300GB SASドライブ）と共有されているシングルクアッドコアXeonボックスでSQL Server 2008 R2 Standardを実行し、SQL Server 2012 Standardへの移行を検討しています。 データベースは約100〜150人の同時ユーザーにサービスを提供し、バックグラウンドスケジューリングタスクがスローされます。これを読んで、12コアは深刻すぎると思います！ SQL Azure DBにリンクされたAzureクラウドサービス（2つの小さなインスタンス）にアプリケーション全体をデプロイしました。テスト時のパフォーマンスは合理的でしたが（ほとんどゼロの負荷）、予測不可能だったため、本番環境で使用する勇気を失いました。スケールアウトのアプローチではうまくいくかもしれませんが、たった10 GBのデータベースを使用すれば、今すぐスケールアップしてお金を節約できます。 最初はライセンスコストを見落としていましたが、SQL Server 2012のライセンスがコアの数に基づいていることに気付きませんでした。SQL Server 2012 StandardライセンスのBizSpark MSDNサブスクリプションを持っているので、これがすぐに利用できるコアの数について調べる必要があります。

13 sql-server  performance  configuration  hardware 

2つのクエリを比較しようとしています。 クエリ1： SELECT a,b,c,d,e FROM tableA LEFT JOIN tableB ON tableA.a=tableB.a WHERE tableA.b=tableB.b AND tableA.c=tableB.c AND tableA.d=tableB.d AND tableA.e=tableB.e クエリ2： SELECT a,b,c,d,e FROM tableA LEFT JOIN tableB ON tableA.a=tableB.a AND tableA.b=tableB.b AND tableA.c=tableB.c AND tableA.d=tableB.d WHERE tableA.e=tableB.e これら2つのクエリで同じ結果が得られると言ってもいいですか？ さらに、最初のクエリが、より大きなWHERE条件を実行するためのより大きなテーブルを作成すると言うのは正しいですか？一方、2番目のケースでは、より単純なテーブルがWHERE適用されたシンプルなテーブルが作成されます。 結果が同じであると仮定すると、どのクエリを優先する必要がありますか？明らかなパフォーマンスの問題はありますか？

13 mysql  performance 

かなり簡単な質問で、おそらくどこかで答えられましたが、Googleの正しい検索質問を作成できないようです... 特定のテーブルの列の数は、そのテーブルのサブセットでクエリを実行するとき、クエリのパフォーマンスに影響しますか？ たとえば、テーブルFooに20個の列があり、クエリでそれらの列のうち5個しか選択されていない場合、20個（たとえば10個）の列があるとクエリのパフォーマンスに影響しますか？簡単にするために、WHERE句のすべてがこれらの5つの列に含まれていると仮定します。 オペレーティングシステムのディスクキャッシュに加えて、Postgresのバッファキャッシュの使用が心配です。Postgresの物理ストレージ設計に対する理解が非常に失われています。テーブルは複数のページに保存されます（デフォルトではページごとに8kのサイズに設定されています）が、そこからタプルがどのように配置されているのかよくわかりません。PGは、これら5つの列を構成するデータのみをディスクからフェッチするのに十分スマートですか？

13 postgresql  performance  query-performance 

私はWebアプリケーション（プロジェクト管理システム）を構築していますが、パフォーマンスに関してはこれについて疑問に思っていました。 課題テーブルがあり、その中には他のさまざまなテーブルにリンクする12の外部キーがあります。そのうち8つは、他のテーブルからタイトルフィールドを取得するために参加する必要があります。これは、Webアプリケーションでレコードが意味をなすようにするためです。これらの結合ごとに1つのフィールド。 今、永続的な理由で自動増分主キーを使用するように言われました（シャーディングがGUIDを使用する必要がある場合を除きます）が、varchar（最大長32）のパフォーマンスを使用するのはどれほど悪いですか？つまり、これらのテーブルのほとんどは、おそらく多くのレコードに含まれないでしょう（それらのほとんどは20未満でなければなりません）。また、タイトルを主キーとして使用すると、95％の時間を結合する必要がないため、SQLの95％でパフォーマンスヒットさえ発生します（私は思う）。私が考えることができる唯一の欠点は、私はより高いディスクスペース使用量を持っているということです（しかし、1日は本当に大したことです）。 列挙の代わりにこのようなものの多くにルックアップテーブルを使用している理由は、これらの値のすべてがアプリケーション自体を介してエンドユーザーによって構成可能である必要があるためです。 多くのレコードを持つことを除いて、テーブルの主キーとしてvarcharを使用することの欠点は何ですか？ 更新-いくつかのテスト それで、私はこのものでいくつかの基本的なテストをすることにしました。私は100000レコードを所有しており、これらは基本クエリです。 ベースVARCHAR FKクエリ SELECT i.id, i.key, i.title, i.reporterUserUsername, i.assignedUserUsername, i.projectTitle, i.ProjectComponentTitle, i.affectedProjectVersionTitle, i.originalFixedProjectVersionTitle, i.fixedProjectVersionTitle, i.durationEstimate, i.storyPoints, i.dueDate, i.issueSecurityLevelId, i.creatorUserUsername, i.createdTimestamp, i.updatedTimestamp, i.issueTypeId, i.issueStatusId FROM ProjectManagement.Issues i ベースINT FKクエリ SELECT i.id, i.key, i.title, ru.username as reporterUserUsername, au.username as assignedUserUsername, p.title as projectTitle, pc.title as ProjectComponentTitle, …

13 mysql  performance  innodb  primary-key 

私は、2TBデータベースのパーティションテーブルへのライブマイグレーションを計画するプロセスです。システムは広範に言えばドキュメントストアであり、スペースの大部分は50kbから500kbのLOBに割り当てられ、500kbから1MBの範囲の小さな割合です。移行の一部には、古いデータベースから新しいデータベースへのBCPデータが含まれます。 データの現在/過去の区分により、最終的な切り替えに先立って（静かな期間中に）段階的に古いデータを抽出し、稼働中のシステムへの影響を最小限に抑えることができるため、BCPが好ましいアプローチです。データ量とストレージの可用性により、パーティションスキームへのその場での再構築が不可能になります。 BLOBの内容により、ROWS_PER_BATCHではなくKILOBYTES_PER_BATCHを試してみると、パフォーマンスがいくらか向上するのではないかと思われます。BCPドキュメントでは、SQLがこの値に基づいて操作を最適化できることが提案されています。 私が見つけることができないのは、これらの最適化の性質やテストを開始する場所に関するガイダンスです。提案がなければ、4/8/16/32 / 64mbの境界で短いランを開始してみます。 おそらくパケットサイズを変更することでいくらかの利点が得られます（サーバーレベルの設定ではなく、BCP -aパラメーター）。より一般的なアプローチがない限り、これを最大65535に上げる傾向があります。

13 sql-server  performance  bcp 

あるお客様では、アプリケーションのパフォーマンスに問題があります。SQL Serverデータベースのデータを消費および更新する.NET 3.5 Webアプリです。現在、本番環境は、フロントエンドとしてのWindows 2008 R2マシンと、バックエンド上のSQL Server 2008 R2クラスターで構成されています。このアプリは、COM +とMSDTCを使用してデータベースに接続します。 ここで何が起こっているのか：エンドユーザーは、アプリケーションの速度が遅いと不満を言うことがあります。一部のページは、予想よりもロードに時間がかかります。何が起こっているのかを理解しようと試みているうちに、パフォーマンスの低下の原因となる可能性のあるデータベース側での奇妙な動作を見つけることができました。予想されることを実行するのにより多くの時間がかかるSQLステートメントが時々あることに気付きました。プロファイラートレース（TSQL_Durationテンプレートを使用）を使用して実行時間の長いクエリを特定し、これらのステートメント（主にアプリケーションのストアドプロシージャの呼び出し）の一部を特定しました。 問題は、これらのストアドプロシージャをSQL Management Studioのデータベースで直接実行すると、時間がかかる（約7/8秒）こともあれば、高速（1秒未満）になることもあります。SQLマシン（4コア、32 GB）が他のアプリケーションで使用されておらず、これらのクエリの実行にこれほど時間がかからないため、これがなぜ起こるのかわかりません。 DBAやSQL Serverの第一人者ではない私は、問題を理解するのに役立つかもしれないものを調べようとしてきました。以下は、問題を解決しようとするためにとったステップと、これまでに発見したことです。 アプリケーションによって呼び出されるすべてのTSQLコードは、ストアドプロシージャで記述されます。 SQL Serverプロファイラーで長時間実行されるクエリの一部を特定しましたが、Management Studioで実行すると、実行に時間がかかる（4〜10秒）か、迅速に実行（1秒未満）します。パラメーターに渡された同じデータを使用して、まったく同じクエリを実行しています。これらのクエリは、主に選択ステートメントを含むストアドプロシージャです。 待機およびキューの統計を調べて、いくつかのリソースで待機しているプロセスがあるかどうかを確認しようとしました。次のクエリを実行しました。 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 …

13 performance  sql-server-2008 

最近、予測不能になったSQL Server 2005があり、その理由について頭を悩ませています。数秒で実行されるクエリは、計画を変更し、数分かかります（フルテーブルスキャンまたはインデックススプールに時間がかかります）。最初の最も明白なことは、統計が古くなってオプティマイザーが混乱することですが、これはそうではないと確信しています-まず、基礎となるデータが大きく変化していないためです2番目に、統計の自動作成と統計の自動更新が両方とも真であるためです。ただし、オプティマイザーは混乱しています。チューニングアドバイザーでSQLを実行CREATE STATISTICSすると、（次のSQLが誤動作するまで）修正しているように見える複数列のステートメントが多数得られます。 これを根本原因とするアプローチに使用できる戦略のアイデアはありますか？「通常の」統計だけでは不十分な理由はありますか？

13 sql-server-2005  performance 

以下の構成のサーバーでホストされている、サイズ300 GBのデータベースの1つからデータをヒット/フェッチする、実行速度の遅いSQLサーバークエリの根本原因を突き止めようとしています。 Windows Server 2003 R2、SP2、Enterprise Edition、16 GB RAM、12 CPU's 32ビット SQL Server 2005、SP4、Enterprise Edition、32ビット。 64ビットへのアップグレードについては既に1か月以上かかるとの情報を提供しています。 しかし、現在の問題では、メモリのプレッシャーを解決できるか、最終的にRAMを増やすという結論に達することができる場合、データを収集しようとしています。 完了したアクション：このデータベースでは、インデックスの再作成と統計の更新が適切です。 以下に示すように、過去5日間、ロード時間中に実行されたセマフォのwaittypeに気付きました。 以下のクエリの後のいくつかの情報：バッファのサイズ= 137272 SELECT SUM(virtual_memory_committed_kb) FROM sys.dm_os_memory_clerks WHERE type='MEMORYCLERK_SQLBUFFERPOOL' セマフォメモリ=以下のクエリごとに644024 SELECT SUM(total_memory_kb) FROM sys.dm_exec_query_resource_semaphores 以下はdm_exec_query_resource_semaphores、sys.dm_exec_query_memory_grantsDMV から収集された詳細情報です。 したがって、上記の情報が収集され、SP_Blitzデータごとにリソースセマフォが問題のようです。 リソースセマフォIDに割り当てられたメモリ 'target_memory_kb'は、使用可能な16 GB RAMと比較して低すぎますか。 注* 8時間の分析ごとに 'target_memory_kb'を実行すると、使用可能な16 GBと比較して常に1 GB未満になりますか？ ここで問題になる可能性のあるものと解決方法は、提案してください ありがとう

13 sql-server  performance  sql-server-2005 

可能なRDBMSのいずれかを使用してデータベースを作成したい。約150列のテーブルがあります。目的は、いくつかの他のオブジェクトの最近傍探索を実行することです。つまり、これは150次元空間のNNSです。 L1またはL2距離のような明らかな方法を使用しようとしましたが、もちろん、行数が多いテーブルの場合は時間がかかります。また、KDツリー（テストしていないことに注意してください）とPG-Stromを確認しようとしましたが、これらは、多くの次元を持つデータには適していません。 数学の方法（KD-treeなど）または技術的な方法（PG-Stromなど）を使用して、記述された検索の速度をどうにかして向上させることができますか？ NNSの速度を改善できるRDBMSを使用するようにします。しかし、MySQLとPostgreSQLは私にとって最も適切なDBMSです。

13 database-design  performance  nearest-neighbor 

動的SQLを使用したくないと言った人がいました。具体的な例や実際の例を挙げていただけますか？個人的には、データベースに数回コーディングします。柔軟性があるので大丈夫だと思います。私の推測では、SQLインジェクションまたはパフォーマンスについてです。他に何か？

13 sql-server  performance  stored-procedures  dynamic-sql  sql-injection 

私はブログの投稿からこのクエリを得ました： SELECT object_name, counter_name, cntr_value FROM sys.dm_os_performance_counters WHERE [object_name] LIKE '%Buffer Manager%' AND [counter_name] = 'Buffer cache hit ratio' 投稿は、キャッシュへのヒットの割合を与えると述べた。0〜100の値になることを示しているようです（87の結果を示しました）。 しかし、それを実行すると、非常に高い数値が得られます。以下に例を示します。 object_name counter_name cntr_value SQLServer:Buffer Manager Buffer cache hit ratio 9990 これは99.90％を意味しますか？ そうでない場合、それはどういう意味ですか？そして、どうすれば本当の価値を得ることができますか？ 注：257から352363までの値を取得しました 関連する場合は、他のサーバー統計をいくつか示します。 ページの平均寿命：145 ページ読み取り/秒：1,380,009,009

12 sql-server  performance  sql-server-2012 

データベースのパフォーマンスを考慮する場合、VLFはどれほど重要ですか？VLFの最適な状況とは何でしょうか？

12 sql-server  performance  transaction-log 

作業チケットのFirebird 2.5データベースを最適化しています。それらはそのように宣言されたテーブルに保存されます： CREATE TABLE TICKETS ( TICKET_ID id PRIMARY KEY, JOB_ID id, ACTION_ID id, STATUS str256 DEFAULT 'Pending' ); 通常、処理されておらずPendingステータスにある最初のチケットを見つけたいです。 私の処理ループは次のようになります： 最初のチケットを取得する場所 Pending チケットを使用してください。 チケットステータスの更新=> Complete 繰り返す。 派手なものは何もありません。このループの実行中にデータベースを監視している場合、各反復でインデックス付き読み取りの数が増えていることがわかります。パフォーマンスは、私が知ることができるほどひどく低下するようには見えませんが、私がテストしているマシンはかなり速いです。ただし、一部のユーザーから時間の経過とともにパフォーマンスが低下するという報告を受けました。 にインデックスがありますStatusが、それでもTicket_Id繰り返しごとに列をスキャンするようです。私は何かを見落としているように見えますが、何がわからないのですか。このようなものに対するインデックス付き読み取りの増加数は予想されていますか、それともインデックスが何らかの形で誤動作していますか？ -コメントの編集- Firebirdでは、次のように行の取得を制限します。 Select First 1 Job_ID, Ticket_Id From Tickets Where Status = 'Pending' だから、「最初」と言うとき、私はそれをどこに限定レコードセットを要求しているだけですStatus = 'Pending'。

12 performance  index  firebird