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

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


2
Redisがすべてのメモリとクラッシュを占有する
Redisサーバーv2.8.4は、8 GBのRAMと16 GBのスワップスペース(SSD上)を備えたUbuntu 14.04 VPSで実行されています。ただしhtop、redis一人22.4 Gで記憶を占有していることを示しています! redis-server記憶不足のために最終的にクラッシュしました。Memそして、Swpの両方が、その後、100%に当たるredis-server他のサービスと一緒に殺されます。 からdmesg: [165578.047682] Out of memory: Kill process 10155 (redis-server) score 834 or sacrifice child [165578.047896] Killed process 10155 (redis-server) total-vm:31038376kB, anon-rss:5636092kB, file-rss:0kB redis-serverOOMクラッシュまたはから再起動すると、service redis-server force-reloadメモリ使用量が100MB未満に低下します。 質問:redis-serverクラッシュするまで、メモリをどんどん占有するのはなぜですか?どうすればこれを防ぐことができますか? maxmemoryredisがmaxmemory制限に達するとデータの削除を開始するため、設定が機能しないのは本当ですか? redis-serverを再起動した後 Redisバージョン: Redis server v=2.8.4 sha=00000000:0 malloc=jemalloc-3.4.1 bits=64 build=a44a05d76f06a5d9 更新 ときhtopのメモリ使用量を報告redis-server4.4gのRAMと22.6Gスワップされることを、Redisの内のすべてのキーによって取り込まれたスペースの量はわずかである60.59636307 MBことで報告されたように、rdbtools。これは、redis-server再起動直後に使用されるRAMの量でもあります。 INFO ALLいつredis-serverメモリを大量に消費しているのか mem_fragmentation_ratio:0.19 127.0.0.1:6379> …

3
T-SQLでCASTを使用したパフォーマンスヒット
指定されたフィールドに対して一般的にSQL条件ステートメントを発行するSQLジェネレーターがあります(説明のために、次のようにラベルを付けますmyField)。 myFieldタイプがの場合NVARCHAR、次のように、上記のフィールドと文字列を比較できますmyField = 'foo'。 ただし、これはタイプのフィールドでは機能しませんNTEXT。したがって、キャストとの比較を行う必要があります CAST(myField as NVARCHAR(MAX)) = 'foo'。これmyFieldは、タイプがNVARCHARまたはの場合に実際に機能しNTEXTます。 すでにタイプのあるフィールドで前述のキャストを実行すると、パフォーマンスにどのような影響がありNVARCHARますか?私の希望は、SQL ServerがそれmyFieldが既に型であると動的に認識できるほどNVARCHAR効果的になることです(事実上をCAST何もしない状態に変えます)。

3
インデックスの最大行サイズエラー
array列に上限はありますか? 配列フィールドに挿入すると、このエラーが発生します- PG::Error: ERROR: index row size 3480 exceeds maximum 2712 for index "ix_data" これが私のテーブル定義です- create table test_array(id varchar(50), data text[]); ALTER TABLE test_array ADD PRIMARY KEY (id); CREATE INDEX ix_data ON test_array USING GIN (data); 配列フィールドを検索しているので、配列フィールドにインデックスが必要です。

1
SQL Serverでのvarcharのサイジングに関する現在のベストプラクティスは何ですか?
ストレージとパフォーマンスの両方の観点から、varchar列の大きさを決定する最良の方法を理解しようとしています。 パフォーマンス 私の研究から、それはそうですvarchar(max)は、本当に必要な場合にのみ使用してください。つまり、列が8000文字以上を収容する必要がある場合、1つの理由はインデックス作成の欠如です(ただし、一般にvarcharフィールドでのインデックス作成には少し疑いがあります。ただし、DBの原則はかなり新しいので、それが根拠がないかもしれません。 )および圧縮(より多くのストレージの問題)。実際、クエリは可能な最大サイズを考慮しなければならないため、一般的に人々はvarchar(n).... oversizingを行うときに必要なものだけを使用することを推奨しているようです。しかし、エンジンはデータの実際の平均サイズの推定値として、示されたサイズの半分を使用することも述べられています。これは、データから平均サイズを決定し、それを2倍にし、それをnとして使用する必要があることを意味します。ただし、変動性が非常に低いがゼロではないデータの場合、これは、最大サイズの最大2倍のサイズ変更を意味します。洞察をいただければ幸いです。 ストレージ 実際のストレージは実際のデータに制限されていることを念頭に置いて、行内ストレージと行外ストレージのしくみについて読んだ後、nの選択はストレージにほとんどまたはまったく影響がないように思えます(それがすべてを保持するのに十分な大きさであることを確認してください)。varchar(max)を使用しても、ストレージに影響はありません。代わりに、可能であれば、各データ行の実際のサイズを〜8000バイトに制限することが目標になる場合があります。それは物事を正確に読んでいますか? コンテキスト 一部の顧客データは少し変動するため、通常、必要な列よりも少し幅を広く(たとえば15〜20%大きく)します。他に特別な考慮事項があるかどうか疑問に思っていました。たとえば、一緒に仕事をしている人から、2 ^ n-1サイズを使用するように言われました(ただし、それを証明するものは見つかりませんでした。 最初のテーブル作成について話している。新しいテーブルの送信を開始し、サンプルデータ(または最初の本番データセットのみ)を送信することをお客様から言われます。これを見て、データを保持するためのテーブルを作成します。将来のインポートとサンプルの内容を処理できるように、テーブルを作成します。ただし、特定の行は長くなるようにバインドされているため、それらをパディングします。 問題はどれくらいか、そして技術的なガイドラインはありますか?

2
多くの列といくつかのテーブル-パフォーマンスの面で
はい、私はデータの正規化が(現状のまま)私の優先事項であることを認識しています。 私は列の車両データを格納する65個の列を持つテーブルを持っている:used_vehicle、color、doors、mileage、priceなど、合計65インチ 今、私はそれを分割して持つことができるVehicleテーブル、VehicleInterior、VehicleExterior、VehicleTechnical、VehicleExtra(すべての一対一のメインとVehicleテーブル)。 約500万行(車両)があるとします。 上SELECTでのWHERE句:パフォーマンスが(どちらの場合は、上の少なくともインデックスを付けて検索するほうが良いでしょうIDs): Vehicle 65列のテーブルまたは VehicleテーブルJOINSに関連するすべてのデータを返すために、他の4つのテーブル(すべてで5万行)にVehicle? (データベースエンジンごとに、PostgreSQLやMySQLを検討してください)。 以前の経験から得られた詳細な洞察を本当に感謝しますか?

3
運用SQL Serverの主要なパフォーマンスの問題、これをトラブルシューティングするにはどうすればよいですか?
この質問は、基本的にこの質問の補足質問です 。SQLServer 2016の奇妙なパフォーマンスの問題 このシステムで生産性が向上しました。前回の投稿以降、このSQL Serverには別のアプリケーションデータベースが追加されました。 これらはシステム統計です: 128 GBのRAM(SQL Serverの場合は最大110 GBのメモリ) 4コア@ 2.6 GHz 10 GBitネットワーク接続 すべてのストレージはSSDベースです プログラムファイル、ログファイル、データベースファイル、およびtempdbは、サーバーの個別のパーティションにあります。 Windowsサーバー2012 R2 VMwareバージョンHPE-ESXi-6.0.0-Update3-iso-600.9.7.0.17 VMware Toolsバージョン10.0.9、ビルド3917699 Microsoft SQL Server 2016(SP1)(KB3182545)-13.0.4001.0(X64)2016年10月28日18:17:30 Copyright(c)Microsoft Corporation Standard Edition(64-bit)on Windows Server 2012 R2 Standard 6.3(Build 9600:) (ハイパーバイザー) 現在、システムに大きなパフォーマンスの問題があります。非常に高いCPU使用率とスレッド数: アクティビティモニターの待機統計(あまり信頼性がないことはわかっています) sp_blitzfirstの結果: sp_configureの結果: サーバーの詳細設定(ドイツ語のみの不幸) MAXDOP設定は私が変更しました。 これはおそらくSQL Server自体の問題ではないことを認識しています。これはおそらく、仮想化(vmware)、ネットワーク関連(すでにテスト済み)、またはアプリケーション自体の問題です。私はそれをさらに釘付けにしたいだけです。 ASYNC_NETWORK_IOが高いと、sqlserverプロセスのスレッド数が多くなりますか?スレッドを閉じることができないため、多くのワーカーが急上昇すると思います。そうですか? 必要な追加情報を提供します。よろしくお願いします! 編集: の結果 …

3
突然インデックスやクエリを変更する必要がある理由に答える方法
私は3年の経験を持つジュニアDBAです。私たちの仕事は、クエリを微調整するか、特定のコードを書き換えるか、インデックスが必要であることを開発者にアドバイスすることです。 開発チームが頻繁に尋ねる1つの簡単な質問は、「昨日は問題なく動作しましたが、何が突然変化しましたか?」です。インフラストラクチャの側面を確認するよう求められます。問題に対する最初の反応は、常に検証される最初のことであるインフラストラクチャに最大の責任を負わせることです。 開発チームからの「何が変わったのか」という質問にどのように答えればよいでしょうか?皆さんは今まで同じ状況に直面しましたか?もしそうなら、あなたの経験を共有してください。

2
SQL CLRを使用したセキュリティまたはパフォーマンスのリスク[終了]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 SQL ServerでCLRを使用する際に、特定のセキュリティまたはパフォーマンスのリスクはありますか?

1
バースト使用のためのIO要件の見積もり
SQLデータベースを1日中定期的に照会するアプリケーションがあります。比較的大量のデータに対する個々のリクエストが散在する、ゼロまたはわずかなアクティビティの期間があります。これらの要求が発生した場合、主な目的はデータを迅速に提供することであり、副次的な目的はそれを費用対効果の高い方法で行うことです。アプリケーションの性質上、データ/インデックスが前のクエリ(異なるユーザー、データの異なる部分で作業)からRAMにキャッシュされることはほとんどありません。 比較的安定した使用を経験するシステムの場合、ディスクキューの長さを観察し、その数を比較的小さく保つという経験則を聞きました。これは特にAWSで実行され、100 IOPSあたり1のディスクキューの長さが妥当であるという経験則を確認しました。 そのようなシステムのIO要件をどのように見積もることができますか?個別のバースト性のあるクエリを処理する場合、ディスクキューの長さは信頼できる指標ですか?考慮すべき他の指標はありますか?

1
プロシージャキャッシュヒット率を向上させる方法は?
プロシージャキャッシュヒット率が95%未満であると私が知ることができることは問題です。私のボックスでは、値は85から95%に移動します。 この問題を解決するにはどうすればよいですか?サーバーには十分なRAMがあるようですので、問題にはなりません。他に何ができますか?

2
MySQLは別のテーブルに対して結合するときにインデックスを使用しません
2つのテーブルがあります。最初のテーブルには、CMS内のすべての記事/ブログ投稿が含まれています。これらの記事の一部は雑誌にも掲載される場合があります。その場合、それらは雑誌固有の情報を含む別のテーブルと外部キーの関係を持っています。 以下は、これらの2つのテーブルの作成テーブル構文の簡略化されたバージョンで、いくつかの重要でない行が削除されています。 CREATE TABLE `base_article` ( `id` int(11) NOT NULL AUTO_INCREMENT, `date_published` datetime DEFAULT NULL, `title` varchar(255) NOT NULL, `description` text, `content` longtext, `is_published` int(11) NOT NULL DEFAULT '0', PRIMARY KEY (`id`), KEY `base_article_date_published` (`date_published`), KEY `base_article_is_published` (`is_published`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; CREATE TABLE `mag_article` ( `basearticle_ptr_id` int(11) NOT NULL, …

3
SQL Server 2008 R2の一般的なメモリ要件
私はDBAの仕事の経験はありませんが、SQLサーバーに追加のリソースを要求するためのケースを作ろうとしていて、何人かが実行する必要のある大まかな概算を提供してくれる賢い人たちを集めることを望んでいました。ITが本番SQLサーバーに割り当てたリソースの割り当てが少ないのではないかと思います。 ハードウェアとソフトウェア: データベース:SQL Server 2008 R2エンタープライズデータベース Windows:Windows 2008 r2 Enterprise 64ビット、VMwareで実行していることを確認してください。 プロセッサー:Intel(R)Xeon(R)CPU E7-4860 @ 2.27GHz 2.26 GHz(2プロセッサー) 搭載メモリ:4GB データベースファイル用ハードドライブ:300 GB バックアップ用ハードドライブ:150GB ログ用ハードドライブ:100GB 応用: 合計で約170GBのデータを追加する3つのメインデータベース、同じサーバー上のReporting Servicesデータベース(SSRS)があり、毎日生成される多分10の異なるレポート(それぞれ平均70万件のレコードを含む)を格納しています。私たちのユーザーベースは約20人の同時ユーザーです。そのうち5人は、大量のデータを処理する大量のレポートを生成する「リソース集中型」と考えることができます。ユーザーの大半は、asp.net WebサイトおよびレポートサーバーWebサイトを介してデータベースと対話します。さらに、開発者はサーバーに直接リモート処理することにより、BIDSでSSISを広範囲に使用します(最大2つのリモート接続)。最後に、かなり複雑なデータウェアハウジング操作があり、サーバーでも実行されるSSISパッケージを介して、おそらく1日あたり300万件のレコードを取り込みます。 現在の問題: 慢性的なサーバータイムアウトがあり、ウェブサイトへの応答時間がかなり悪いです。私たちが持っているメモリの量(4GB)はおそらく大きなボトルネックだと思います。以前の追加メモリの要求は、より多くのクエリ最適化を実行する必要があるという一般的な応答で拒否されました。私たちはsqlの専門家ではありませんが(私たちのセットアップでわかるように)db adminの専門家ではありませんが、ハードウェアがボトルネック。 tl; drを回避してくれてありがとう!

3
RESTful APIのSQLデータベース構造
RESTful APIを作成しています。リソースを中心にデータベーステーブルを設計する最良の方法を決定するのに苦労しています。 最初は、リソースごとのテーブルが適していますが、これにより、リソースチェーンをさらに下っていくと、テーブルが指数的に大きくなるのではないかと心配しています。 たとえば、ユーザー、クライアント、販売の3つのリソースがあるとします。ユーザーは私のAPIのサブスクライバーであり、クライアントはユーザーの顧客であり、販売は各クライアントがユーザーアカウントに対して行った購入です。 次のように販売リソースにアクセスします GET /users/{userID}/clients/{clientID}/sales/{salesID} したがって、10人のユーザーがあり、それぞれに10人の顧客がいて、それぞれの顧客について10件の売上がある場合、テーブルサイズは、リソースチェーンを下に行くほど大きくなります。 SQLが大きなテーブルに対応できるとは確信していますが、読み取りと書き込みがどのように遅くなるかはわかりません。上の例はそれを説明していないかもしれませんが、私のAPIは次第に多くの書き込みと読み取りを行って、リソースチェーンのさらに下に行きます。したがって、データベース内の最大のテーブルが、小さいテーブルよりも多くの回数読み書きされるシナリオがあります。 クエリを実行する前にテーブルを結合する必要もあります。その理由は、各ユーザーが同じ名前のクライアントを持つことを許可するためです。間違ったクライアントデータを取得しないように、usersテーブルとclientsテーブルは{userID}によって結合されます。これは販売にも当てはまります。大きなテーブルを結合して読み取りと書き込みを実行すると、処理がさらに遅くなりますか?

4
特定のユーザーのクエリが遅い
C#.NET Webアプリケーションから呼び出されるクエリがいくつかあります。これは常に高速です(SQL Serverのローカル管理者です)が、ユーザーのグループ(必要な権限を持つドメイングループ)の場合、クエリはアプリケーションでタイムアウトするポイント。 まったく同じクエリがユーザーごとに異なる動作をする原因は何ですか? より詳しい情報: クエリは、ストアドプロシージャではなく、C#コードのインラインSQLです。 アプリはドメイン認証を使用し、ユーザーと私はアプリを通じてクエリを実行します 問題は別のプランであるようで、1つはキャッシュされたため、ユーザーごとに異なっていました。クエリがアプリ経由で遅くなり、SQL Server Management Studioで高速になるため、何かがキャッシュに影響しています。

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