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

データベースアプリケーションまたはシステムのパフォーマンス特性の向上。

1
sp_cursorprepexecが5300万の読み取りを引き起こしていますか?
SQL Server 2012でDynamics AX 2012のインストールを実行しています。カーソルはもう使用されないはずですが、AXはそれを使用しており、この動作を変更できないため、操作する必要があります。 今日、5300万を超える読み取りと20分を超える実行時間を伴う非常に悪いクエリを見つけました。 私は監視ツールのSentryOneを介してこのクエリを見つけました。 declare @p1 int set @p1=1073773227 declare @p2 int set @p2=180158805 declare @p5 int set @p5=16 declare @p6 int set @p6=1 declare @p7 int set @p7=2 exec sp_cursorprepexec @p1 output,@p2 output,N'@P1 bigint,@P2 nvarchar(5),@P3 bigint,@P4 nvarchar(8),@P5 bigint,@P6 bigint,@P7 bigint,@P8 bigint,@P9 bigint,@P10 bigint,@P11 bigint,@P12 bigint,@P13 bigint,@P14 …

2
> =および>のカーディナリティ推定(ステップ内統計値)
SQL ServerがSQL Server 2014のwhere句の「より大きい」と「等しい」をどのように推定するかを理解しようとしています。 私がそうすれば、それがステップに到達したときのカーディナリティ推定は理解していると思います select * from charge where charge_dt >= '1999-10-13 10:47:38.550' カーディナリティの推定値は6672で、32(EQ_ROWS)+ 6624(RANGE_ROWS)+ 16(EQ_ROWS)= 6672(下のスクリーンショットのヒストグラム)として簡単に計算できます。 しかし、私がするとき select * from charge where charge_dt >= '1999-10-13 10:48:38.550' (時間を10:48に増やしたため、ステップではありません) 推定値は4844.13です。 それはどのように計算されますか?

1
Amazon RDS MySQL 5.5 Innodbロック待機タイムアウトを超えました
Amazon RDSに移行して以来、かなりクレイジーなパフォーマンスの問題があり、今日はロックの問題が発生し始めています。そのため、タイムアウトの問題だと思い、使用しているメモリを確認しました。約70MB相当のスワップを行いました。私はmysqltunerを使ってメモリ魔女狩りをしましたが、最大メモリ使用量は約400%と言われていました。Perconaの構成ウィザードのおかげで、今では100%を少し超えています。 ただし、このロックの問題はまだ残っているので、メモリ/スワッピングとは関係がないと思います。それでもロックアウトが発生するのはなぜですか?何が起きてる? 再起動で問題が解決すると確信していますが、それは解決策ではありません。将来これを防ぐために何ができるでしょうか?クエリキャッシュとテーブルをフラッシュしてみましたが、うまくいきました。 RDSのおかげで、他の種類のフラッシュは機能しませんでした:/ 以下に、私が提供できると考えられる豊富な情報を示します。 クエリ INSERT INTO `myTable` (`firstName`, `lastName`, `email`) VALUES ('Travis', 'B...', '...@gmail.com') エラーメッセージ Lock wait timeout exceeded; try restarting transaction テーブルスキーマ CREATE TABLE IF NOT EXISTS `myTable` ( `id` int(15) NOT NULL AUTO_INCREMENT, `firstName` varchar(255) COLLATE utf8_unicode_ci NOT NULL, `lastName` varchar(255) COLLATE utf8_unicode_ci NOT NULL, …



4
500M +アイテムのクエリを処理する方法
私のデータの構造は次のとおりです: date: <timestamp> filter_a: <integer> -> range [0, 1000] filter_b: <integer> -> range [0, 1000] filter_c: <integer> -> range [0, 86400] filter_d: <integer> -> range [0, 6] group: <string> second_group: <integer> variable_a: <float> variable_b: <float> variable_c: <float> a couple more no very important 次のクエリを実行する必要があります。 最初: フィルターデータによってdate、filter_a、filter_b、filter_c、その他 次に、フィルタリングされたデータを使用します。 すべてのレコードを数える 取得平均のvariable_a、variable_bおよびvariable_c 取得標準偏差のをvariable_a、variable_bそしてvariable_c …

3
Postgres部分インデックスの作成を高速化
Postgres 9.4で大きな(1.2 TB)静的テーブルの部分インデックスを作成しようとしています。 私のデータは完全に静的なので、すべてのデータを挿入してから、すべてのインデックスを作成できます。 この1.2 TBのテーブルrun_idには、データをきれいに分割するという名前の列があります。さまざまなをカバーするインデックスを作成することにより、優れたパフォーマンスを得ていますrun_id。次に例を示します。 CREATE INDEX perception_run_frame_idx_run_266_thru_270 ON run.perception (run_id, frame) WHERE run_id >= 266 AND run_id <= 270; これらの部分インデックスにより、望ましいクエリ速度が得られます。残念ながら、各部分インデックスの作成には約70分かかります。 CPUが制限されているようです(topプロセスの100%を示しています)。 部分インデックスの作成を高速化するために何かできることはありますか? システム仕様: 18コアXeon 192GB RAM RAIDに12個のSSD 自動バキュームがオフになっています maintenance_work_mem:64GB(高すぎる?) テーブル仕様: サイズ:1.26 TB 行数:10537億 一般的なインデックスサイズ:3.2GB(〜.5GBの差異があります) テーブル定義: CREATE TABLE run.perception( id bigint NOT NULL, run_id bigint NOT NULL, frame bigint …

1
最新のサーバーでのパフォーマンスの低下
実稼働環境にはいくつかのdbサーバーがあり、そのうち4つはハードウェア構成が非常に似ています。Dell PowerEdge R620、唯一の違いは、最新の2つ(3か月前に購入および構成されたもの)にRAIDコントローラーv710、256GB RAM、およびCPUが2つの物理Xeon E5-2680 2.80GHzであることです。古いもの(約1年前に購入および構成されたもの)には、RAIDコントローラーv700、128GB RAMがあり、2つの物理Xeon E5-2690 2.90GHzで実行されています。BIOSの更新、すべてのドライバーの最新バージョンへの更新など。実行中のすべてのSQL Server 2008R2 Enterprise(SP1)が最新のCUおよびWindows 2012R2 Standardに更新されました。どちらも200 GB SSD x5 RAID10で動作します。それぞれで実行されているデータベースは1つだけで、SSISパッケージを呼び出すジョブを使用して同期されます。私たちのシステム管理者は、ハードウェアやネットワークの設定ミスや失敗がないことを確認するために、多くのパフォーマンスとストレステストを実行しました。予想通り、最新のものはより良いパフォーマンス結果を示しています。ここまでは順調ですね。 私たちが抱えている問題は、Kibanaの画面キャプチャーで確認できます。黄色とオレンジは2つの新しいサーバー(テーブルでは6、7)で、他のすべてのサーバーの下にあります。これらの2つの新しいサーバーの応答時間が遅いことが完全にわかります。それだけでなく、これらの2つのサーバーの負荷も、2つの古いサーバーよりもわずかに少なくなっています(表の淡い青色と濃い青色の線-4,5)。 パフォーマンスカウンターに関する情報を収集するいくつかの監視スクリプトを用意します。DMVと3番目の監視ツールで可能な限り掘り下げたので、私は多くの情報を手元に持っています。しかし、この遅い応答時間に対する答えを見つけることができないため、ここで見逃していることがあるはずです。 最新の2台のサーバーはRAMの使用量が少ないですが、他の古いサーバーと比較すると、負荷が低いため、それは予想通りです。 | Server Name| Mem_MB | Mem_GB | Server_RAM_GB | SQL_max_mem_GB| SQL_min_mem_GB | |------------|--------|--------------|---------------|---------------|----------------| | 4 | 41108 | 40.145263671 | 128 | 120 | 16 | | 5 | …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.