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

データベースのコンテキストで使用される場合、メモリは、I / Oサブシステムを経由するのではなく、CPUによって直接アドレス指定可能なRAMを指します。

5
SQL Serverオプション「アドホックワークロード用に最適化」を使用しないのはなぜですか?
このようなKimberly TrippによるSQL Serverプランのキャッシュに関するいくつかの素晴らしい記事を読んでいます:http : //www.sqlskills.com/blogs/kimberly/plan-cache-and-optimizing-for-adhoc-workloads/ 「アドホックワークロード向けに最適化する」オプションさえあるのはなぜですか?これは常にオンにすべきではありませんか?開発者がアドホックSQLを使用しているかどうかに関係なく、それをサポートするすべてのインスタンス(SQL 2008+)でこのオプションを有効にしないのはなぜですか?

3
SQL Serverの「合計サーバーメモリ」の消費量は数か月間停滞しており、64GB以上が利用可能
SQL Server 2016 Standard Edition 64ビットが、割り当てられた合計メモリの正確に半分(128GBの64GB)で完全に制限されているように見えるという奇妙な問題に遭遇しました。 出力@@VERSIONは次のとおりです。 Microsoft SQL Server 2016(SP1-CU7-GDR)(KB4057119)-13.0.4466.4(X64)2017年12月22日11:25:00 Copyright(c)Microsoft Corporation Standard Edition(64ビット)on Windows Server 2012 R2 Datacenter 6.3(ビルド9600:)(ハイパーバイザー) 出力sys.dm_os_process_memoryは次のとおりです。 クエリを実行するsys.dm_os_performance_countersと、Target Server Memory (KB)がで131072000ありTotal Server Memory (KB)、その半分以下にあることがわかります65308016。ほとんどのシナリオでは、SQL Serverがそれ自体のメモリをさらに割り当てる必要があると判断していないため、これは正常な動作であると理解しています。 ただし、2か月以上にわたって〜64GBで「スタック」しています。この期間中に、一部のデータベースでかなりの量のメモリを消費する操作を実行し、さらに40個近くのデータベースをインスタンスに追加しました。合計292個のデータベースがあり、それぞれに4GBの256 MBの自動成長率の事前割り当て済みデータファイルと、128MBの自動成長率の2GBのログファイルがあります。毎晩12:00 AMにフルバックアップを実行し、月曜日から金曜日の午前6時から午後8時まで、15分間隔でトランザクションログのバックアップを開始します。これらのデータベースは、全体的なスループットが比較的低いですが、SQL Serverが高速化されていないため、何かがおかしいのではないかと疑っています。Target Server Memory 当然、新しいデータベースの追加、通常のクエリの実行、および実行されたメモリ集約型のETLパイプラインを通じて。 SQL Serverインスタンス自体は、12 CPU、144GBのメモリ(SQL Serverに128GB、Windows用に16GBを予約)、および15K SASドライブを備えたvSANの上にある合計4つの仮想ディスクを備えた仮想化(VMware)Windows Server 2012R2サーバーの上にあります。Windowsは、32GBのページファイルがある64GB C:ディスクに自然に配置されます。データファイルは2TBのD:ディスクに、ログファイルは2TBのL:ディスクの上に、tempdbは256GBのT:ディスクに置かれ、8x16GBのファイルは自動拡張されません。 サーバーで実行されているSQL Serverの他のインスタンスが以外にないことを確認しましたMSSQLSERVER。 このサーバーは完全にSQL Serverインスタンス専用であるため、メモリを消費する可能性のある他のアプリケーションやサービスは実行されていません。 分析にはRedGate …

4
専用のデータベースサーバーでは、OS用にどのくらいのメモリを予約しますか?
データベース機能専用の専用サーバーがあると仮定します。オペレーティングシステム用にどのくらいのメモリを確保する必要がありますか? これはおそらく、特定のOS、特定のデータベースソフトウェアなどによって多少異なると思います。しかし、メモリはデータベースのパフォーマンスにとって非常に重要であるため、ホストOSを枯渇させることなく、データベースに最大限の適切なレベルのメモリを持たせたいと考えています。 そう 手始めに良い経験則は何ですか? 行き過ぎて、ホストOSが何らかの形でデータベースに飢えているかどうかを判断するには、どのカウンタまたはパフォーマンスインジケータを調べる必要がありますか?

5
SQL Serverがより多くのサーバーメモリを消費するのはなぜですか?
SQL ServerはサーバーRAMの87.5%を消費しています。これは最近、速度低下などの多くのパフォーマンスのボトルネックを引き起こしました。この問題を調査しました。インターネットで見つけることができる一般的な解決策の1つは、SQL Serverの最大制限を設定することです。これが行われ、多くの改善が得られました。最大メモリ値が設定されていない場合、SQL Serverがリソースを消費し続ける理由を知りたい

3
インスタンスごとにSQL Server ExpressのメモリとCPUの制限はありますか?
サーバーに8GBのRAMがあり、SQL Server Expressの4つのインスタンスを実行する場合、SQL Serverが使用する合計メモリ制限は1GBですか、4GBですか? このように複数のインスタンスを実行して、各データベースがリソースをより有効に使用できるようにすることをお勧めしますか(サーバーに十分なリソースがある場合)。


4
大量のRAMに対するpostgresqlのチューニング
(ハードウェアの点で)2つの同一のサーバーがあり、どちらもWindows Server 2008 r2の標準インストールであり、最小限のソフトウェアがインストールされています(基本的には私のコードとjvmなどの必要なもの)。 1台のサーバーで、2台目のサーバーpostgresql 9.1でSQL Server 2005を実行しています。これら2台のサーバーでのパフォーマンスの違いは驚異的であり、上司への最初の「SQLサーバーライセンスの代金を支払う代わりにpostgresqlを使用しましょう」と後悔しています。同じコマンドで30秒と15分という違いを話しているのですが、これはこの1つのコマンドだけでなく、私が投げるクエリやコマンドでもあります。両方ともほぼ同じデータを持ち(レコードは異なる順序で挿入されました)、両方のデータベースはまったく同じ構造/インデックスなどを持っています。 しかし、それは単なるパフォーマンスチューニングの問題だと思います。実は、SQLサーバーはサーバー上で32ギガバイトすべてのRAMを使用していますが、postgreslは何も使用しておらず、ギグよりも確実に少ないのですが、実際には詳細に把握していません。 postgresqlで20ギガバイト以上のRAMを使用するにはどうすればよいですか?これらのサーバーはこのデータベース専用に構築されているため、データベースとサポートプロセスで使用されていないラムは無駄になります。

3
使用しているメモリが多すぎるMongoDB
MongoDBを数週間使用していますが、全体的な傾向として、mongodbのメモリ使用量が大きすぎる(データセット+インデックスのサイズ全体よりもはるかに大きい)ことがわかりました。 私はすでにこの質問とこの質問を読んでいますが、私が直面している問題に対処しているものはないようです。実際にドキュメントで説明されていることを説明しています 以下は、htopおよびshow dbsコマンドの結果です。 mongodbはメモリマップドIOを使用することを知っているので、基本的にOSはメモリ内のキャッシュを処理し、理論的には別のプロセスが空きメモリを要求したときに mongodb がキャッシュされたメモリを解放する必要がありますが、私たちが見たところ、そうではありません。 OOMは、他の重要なプロセス(postgres、redisなど)を殺す開始を開始します(この問題を克服するために、RAMを183GBに増やしましたが、現在は動作しますがかなり高価です。mongoは〜87GBのRAMを使用しています。データセット全体のサイズのほぼ4倍) そう、 これだけのメモリ使用量が本当に予想され、正常ですか?(ドキュメントによると、WiredTigerはキャッシュに最大で60%のRAMを使用しますが、データセットのサイズを考慮すると、86GBのRAMを使用するのに十分なデータさえありますか?) メモリ使用量が予想される場合でも、別のプロセスがより多くのメモリを要求し始めた場合、mongoが割り当てられたメモリを手放さないのはなぜですか?RAMを増やしてシステムを完全に不安定にする前に、mongodb自体を含め、他のさまざまな実行中のプロセスがLinux oomによって絶えず殺されていました。 ありがとう!

7
MySQLでMEMORYストレージエンジンを使用しない理由は何ですか?
私は最近、MySQLが認識していない「メモリ」エンジンを持っていることを発見しました(私のデータベース作業の大部分は趣味のプロジェクト向けであるため、必要に応じて学習しています)。このオプションを使用すると、パフォーマンスが大幅に向上するはずなので、それに伴う欠点はあるのでしょうか。私が知っている2つは: 問題のテーブルを保持するのに十分なRAMが必要です。 マシンがシャットダウンすると、テーブルは失われます。 私はAWS EC2を使用しており、必要に応じてより多くのメモリを備えたインスタンスタイプに移行できるため、#1は問題ではないと考えています。必要に応じてディスクにダンプバックすることで、#2を軽減できると思います。 他にどんな問題がありますか?メモリエンジンは、MyISAMまたはInnoDBのいずれよりもパフォーマンスが低下することはありますか?このエンジンではインデックスが異なるということを読んだと思います。これは私が心配する必要があるものですか?

3
Windows 2008R2上のSQL 2008R2の推奨ページファイルサイズ
このMicrosoftの記事-64ビットバージョンのWindows Server 2008またはWindows 2008 R2の適切なページファイルサイズを決定する方法は、64ビットWindows 2008およびWindows 2008R2のページファイルサイズを計算するためのガイダンスを提供します。これは間違いなく汎用サーバーでうまく機能します。Windows 2008 / R2 64ビットで実行されているSQL Server 2008R2のガイダンスは何ですか? メモリ内のデータがページファイルにほとんどヒットしないようにすると、SQLがデータを取得するためにディスクに2回ヒットする可能性があります。SQL Serverでは、メモリ内のデータがページファイルにヒットすることさえ許可していますか?私はを通じて狩りをしましたSQL Server 2008 R2のオンラインブック指導のためにまだページファイルの使用の一切の言及を発見していません。 潜在的な使用シナリオは次のとおりです。物理サーバーに64GBのRAMがある場合、64GBのRAM全体にページファイルが必要ですか?96GBのページファイルに対応する必要がありますか?これは、単一のファイルでは少し過剰に思えます。私は、Windowsがページファイルをメモリに結合して、RAM上のアプリをより簡単にスワップアウトしようとするのが常識であったことを知っていますが、それは本当ですか?ここでは64GB未満のページファイルでパフォーマンスが低下しますか?

2
すべてのデータベースをダンプせずに、innodbファイルibdata1を縮小するにはどうすればよいですか?
InnoDBはすべてのテーブルを1つの大きなファイルに保存しますibdata1。 大きなテーブルを削除した後、ファイルはテーブルがどれほど大きくてもそのサイズを維持しています。データベース全体(合計で数百GBあります)をダンプして再インポートすることなく、そのファイルを圧縮するにはどうすればよいですか? 理由は、ドロップをまだロールバックできるからだと思います。私の場合、必要はありません。

1
SQL Server 2012 Expressがサーバーで9.5GBのRAMを使用するのはなぜですか?
SQL Server 2012 Expressをプライマリデータストアとして埋め込む予定のアプリケーションを構築しています。開発マシン(3GB RAMのWin7-32​​)でテストするときsqlservr.exe、公開されたハードウェアのスケーリング制限から予想されるように、1GBを超えるRAMを使用するプロセスを観察しませんでした、SQL ServerのExpressエディションの。 次に、アプリケーションをサーバーグレードのマシン(16 GB RAMを搭載したWin Server 2008R2 64ビット)に移動して、そこでパフォーマンスを評価しましたが、 sqlservr.exeプロセスが約9.5 GBのRAMに急速に拡大し、そこに留まったことがわかりました。 数回再起動して、効果があるかどうかを確認しましたが、毎回、プロセスは急速に〜9.5GBに戻りました。これで、SQL Server ExpressでRAMを使用できるようになりましたが、これが予想される動作であるかどうかを知りたいので、不適切なRAM使用量に基づくパフォーマンスレベルに依存することはありません。 参考までに、サーバーマシン上のSQL ServerのバージョンSELECT @@VERSIONは次のとおりです。 Microsoft SQL Server 2012 (SP1) - 11.0.3000.0 (X64) Oct 19 2012 13:38:57 Copyright (c) Microsoft Corporation Express Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) 9.5GBの数値は、タスクマネージャーの「プライベートワーキングセット」の数値から取得されました。DBCC …

3
CPU使用率は外部NUMAアクセスのコストに影響しますか?
シナリオ 1つのNUMAノードごとに4つのソケットを持つSQL Serverがあるとします。各ソケットには4つの物理コアがあります。合計512 GBのメモリがあるため、各NUMAノードには128 GBのRAMがあります。 キーテーブルが最初のNUMAノードにロードされます。 質問 そのテーブルから多くのトラフィックを読み取っていると仮定しましょう。NUMAノードを所有するソケットのすべての物理コアのCPU使用率が100%の場合、他のソケットからの非ローカルNUMAアクセスのコストに悪影響を及ぼしますか?または、その一方で、非ローカルNUMAアクセスのコストは、そのソケットがどれほどビジーであるかに関係ありませんか? 私の質問が理にかなっていることを願っています。明確にならない場合はお知らせください。 バックグラウンド 先週、本番サーバーでデータベースの問題が発生し、処理されたビジネスの一部が他のビジネスよりも大きな影響を受けたようです。1分以上かかる論理読み取りの少ないクエリがありました。全体のCPU使用率を調べたところ、約60%でした。ソケット固有のCPUメトリックは確認しませんでした。I / Oメトリックは平均でした。

1
SQL Server-誰でもSUMA、トレースフラグ8048、またはトレースフラグ8015を使用していますか?
最近、SQL Serverスタートアップトレースフラグ8048が含まれ、SQL Server 2008 R2システムでの重大なスピンロック競合の問題が解決されました。 パフォーマンス値がトレースフラグ8048(NUMAノードごとからコアごとにクエリメモリ付与戦略を促進する)、トレースフラグ8015(SQL Serverは物理NUMAを無視する)、またはSUMA(インターリーブされた十分に均一なメモリアクセス、一部のNUMAマシンのBIOSオプション)。 トレースフラグ8048 http://blogs.msdn.com/b/psssql/archive/2011/09/01/sql-server-2008-2008-r2-on-newer-machines-with-more-than-8-cpus -numa-node-may-need-trace-flag-8048.aspxごとに表示 トレースフラグ8015 http://blogs.msdn.com/b/psssql/archive/2010/04/02/how-it-works-soft-numa-io-completion-thread-lazy-writer-workers-and-memory -nodes.aspx システムのワークロードの詳細、問題のあるシステムからのメトリックの収集、介入後のシステムからのメトリックの収集。 トレースフラグ8048は「修正」でしたが、それが最良の修正でしたか?SQL Serverは、トレースフラグ8015により物理NUMAを無視しても同じことを達成できますか?メモリをインターリーブするようにBIOSを設定して、NUMA動作ではなくSMP動作のSUMA動作をサーバーに残してはどうですか? 平和!tw:@sql_handle システムについて:-4 hexコアXeon E7540 @ 2.00GHz、ハイパースレッド-128 GB RAM-WS2008R2-MSSQL 2008 R2 SP2-maxdop 6 ワークロードについて:-2つのレポートアプリケーションサーバーから駆動される1000のバッチスケジュール/キューレポート。-3種類のバッチ:毎日、毎週、毎月-SQL Serverへのすべてのレポートアプリケーションサーバー接続は、単一のサービスアカウントとして作成されます-最大レポート同時実行数= 90 問題のあるシステムに関する主な調査結果:-Perfmonから、15秒間隔--システムは95%〜100%のCPU使用率のまま--SQL Serverのバッファーページ検索<10000 /秒 待機およびスピンロックDMVから、5分間隔 高いCMEMTHREADウェイターと待機時間 高いSOS_SUSPEND_QUEUEスピンとバックオフ Bob Dorrのトレースフラグ8048に関するCSSエンジニアブログの投稿は、NUMAノードごとに8コアを超えるシステムがクエリメモリ許可のボトルネックにより同様の症状に陥ることがあることを示しています。トレースフラグ8048は、戦略をNUMAノードごとではなくコアごとに変更します。 介入 -T8048を設定してMSSQLを再起動しました。違いはすぐに明らかになりました。バッファページの検索速度は100万を超え、1秒あたり800万に急上昇しました。以前は24時間で完了できなかった問題のあるバッチワークロードが、4時間未満で完了しました。トレースフラグ8048の修正値の検証の一部として、調査や介入の焦点では​​ない別のバッチワークロードが提出されました(そして、その望ましくない副作用が最小限であることを確認しました)。このレポートバッチは、以前2時間で完了しました。トレースフラグ8048を設定すると、レポートバッチは約20分で完了しました。 ナイトリーETLにもメリットがありました。ETL時間は約60分から40分に短縮されました。 いくつかの場所から情報を集めて、高度なレポートキューイング、ハードウェアスレッドカウントを超える同時レポートカウント、および結合されたすべてのレポートの単一ユーザーアカウントが、ワーカースレッドのプレッシャーによって1つのNUMAノードにプレッシャーをかけると推測します同じユーザーアカウントの次の着信接続要求に対して不利になります。この時点で、次のNUMAノードはほぼ瞬時にいくつかの接続を取得します。各NUMAノードは、クエリメモリ許可のボトルネックを強調する可能性が高くなります。 クエリメモリ許可のためにさらにレーンを開くと、ボトルネックが解消されました。しかし、費用はわかりません。Bob DorrのCSS投稿により、トレースフラグ8048で追加のメモリオーバーヘッドがあることが明らかになりました。単一ページアロケータ領域内のオーバーヘッドは、MSSQL 2008 R2の最大サーバーメモリによって管理されていますか?もしそうなら、システムはバッファプールキャッシュにあるデータベースページの数が少ないと思います。そうでない場合、最大サーバーメモリを下げる必要がありますか?

1
キャッシュサイズと予約メモリを計画する
実際の実行計画を含むクエリを実行すると、ルート演算子(SELECT)からキャッシュされた計画サイズが32KBであることが通知されます。 sys.dm_exec_cached_plansとを結合するクエリはsys.dm_os_memory_objects、問題のプランを見て、との値が32768(32KB)であり、キャッシュされたプランのサイズと一致するpages_in_bytesと言いますmax_pages_in_bytes。 私が理解していないのは、の値sys.dm_exec_cached_plans.size_in_bytesが49152(48KB)の略であるということです。これらすべてのコラムでBOLを読みました。特に次のようsize_in_bytesに述べています。 「キャッシュオブジェクトが消費したバイト数。」 それが本当に何を意味するのか理解するために、私はパズルの最後の部分を配置することはできません。 すべての演算子(並べ替えとハッシュに使用される追加のメモリ許可については説明しません)は、キャッシュに最適化されたプランで保存される状態の保存、計算の実行などのために、ある程度の固定メモリを必要としますが、どこにありますか? だから、私の質問は: size_in_bytes本当にどういう意味ですか 「キャッシュされた計画サイズ」よりも高い値になるのはなぜですか? すべての演算子/イテレータのメモリの固定量はどこに予約されていますか、「キャッシュされたプランサイズ」(この例では32Kb)ですか、それとも他の場所ですか? 私はそれらが異なる機能を持つ異なるDMVであることを知っていますが、それらは関連しています。でコンパイルされた(キャッシュされた)計画sys.dm_exec_cached_plans参加するsys.dm_os_memory_objects上でmemory_object_addressのカラム。私がここに質問を投稿する理由は、私がこれについて助けを求めて、DMVとそれらのコラムを解釈する方法を理解しているからです。 場合はsize_in_bytes、なぜSQL Serverは、実際の実行計画で別の値をキャッシュされたプランのサイズと言うんですか? 新しいクエリ、新しい番号: 実際の計画 キャッシュされたプランサイズ16KB CompileMemory 96KB DMV: sys.dm_exec_cached_plans.size_in_bytes 24KB sys.dm_os_memory_objects.pages_in_bytes, .max_pages_in_bytes 16KB。 また、このクエリでは、並べ替えおよびハッシュ操作に追加のメモリ許可が必要ないことに注意してください。 Microsoft SQL Server 2012-11.0.5343.0(X64)

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