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

18
貧弱な内部データベース-交換するか、ハードウェアをチャックしますか?
だから-私たちは社内のデータベース、通常の種類のものを持っています:クライアント、電話、販売取引、クライアント契約/スキームを管理します。 これは、Access 2000フロントエンドおよびSQL Server 2000 Standardバックエンドです。単一サーバー、デュアルXeon 3.2GHz、2GB RAM、Windows Server 2003は、1日中約40%のCPU負荷を取得し、OS(HT)から見える4つのコアに分散しています。 バックエンドデータベースの設計は不十分であり、10年以上にわたって有機的に成長し、熟練していない個人によって維持されています。それはひどく正規化されており、いくつかの明らかな問題には、主キーまたはインデックスのない数万行のテーブルが含まれます。これらは、システムの最も頻繁に使用される一部のマルチテーブル結合でも頻繁に使用されます(例:全員のセカンドモニターに1日8時間常駐し、数秒ごとに大きな非効率的なクエリを実行するコールマネージャーアプリケーション)。 フロントエンドはあまり良くありません。それは典型的な数百のフォームの混乱、ネストされた保存されたクエリ、VBAコードでの不十分な記述の埋め込みSQL、数十の「奇癖」などです。「十分に」機能する1つのMDBに決着しました。現在、社内にAccessヘビーウェイトがないため(また、いずれも採用する予定もありません)、変更に関するポリシーはありません。 同社は現在ゆっくりと成長しており、クライアント、コールなどの数が増加し、同時ユーザー数がわずかに増加しています。また、最近ではパフォーマンスが著しく悪化しています(フォーム間を移動するのを待っている、リストにデータが入るのを待っているなど) ) Perfmonより: 1秒あたりのディスク転送:0〜30、平均4。 現在のディスクキューの長さ:1前後 SQL Serverのプロファイラーは、毎分数十万のクエリを確認します。クライアントのCPU使用率はほとんどゼロであり、サーバー側のクエリの実行を待機していることを示しています。DB Engine Tuning Advisorを使用してこのワークロードを配置し、テストバックアップにその提案を適用しましたが、実際にはそれほど大きな違いはありません。 ちなみに、100MBとギガビットイーサネットが混在しており、すべて1つのサブネット上にあり、2つのフロアに40人のユーザーがいます。 質問に。 私が見るように、この状況を解決/改善するための2つの選択肢があります。 それを廃棄して、完全に新しいCRMシステム(特注または一部特注)に置き換えることができます ハードウェアをチャックすることで、このシステムの寿命を延ばすことができます。 ソフトウェアを交換するよりもはるかに少ないコストで、クレイジーなパフォーマンスを備えたIntel i7システムを構築できます。 最終的に新しいシステムが開発されると、このボックスでホストできるため、無駄なハードウェアはありません。新しいCRMシステムはどんどん消えていきます。少なくとも1年間はそうなるとは思いません。 特に自分がここにいる場合は、この状況についての考えをお寄せください。 ありがとう

2
PostgreSQLのmax_connectionsとpgbouncerのdefault_pool_sizeの計算方法は?
私はかなりの数を計算するために使用できるルールまたは何かがあるmax_connections、default_pool_sizeとmax_client_conn? デフォルトは奇数です。PostgreSQLのデフォルトはmax_connections = 100で、pgbouncerのデフォルトはdefault_pool_size = 20です。default_pool_sizeを常にmax_connectionsより大きくするべきではありませんか?それ以外の場合、ポイントは何ですか?pgbouncerは、オーバーヘッドを下げることで(PostgreSQLの接続を再利用することで)より多くの接続を処理できるようにするためのものだと思いました。よくわかりません。 「このパラメータはメモリの最大50%である必要があります」など、PostgreSQLのwikiにあるアドバイスと同様のアドバイスを探しています。 これらの種類のパラメータを計算できるMySQLのスプレッドシートがあったことを覚えています。PostgreSQL / pgbouncerにそのようなものがあれば素晴らしいでしょう。

6
運用データベース用のSQL Server Expressですか?
各クライアントが独自のデータベースを持つデュアルWeb /内部トランザクションアプリケーションを展開しようとしています。各データベースは非常に小さく、それぞれ50 MB未満であるため、完全なSQL ServerではなくSQL Express 2008を使用するのが理にかなっているのではないかと考えていました。 これには、大量の$$$を節約しながら、サーバー間でディスクI / Oを分散できるという利点があるようです(小さな15Kドライブと使用済みのデュアルコアサーバーはどちらも安価であるため)。ある時点で必要なサーバーが多すぎる場合は、SQL Serverにアップグレードできますが、数十の内部ユーザーがいると、今はあまりにも高価に思えます(特にフェールオーバーボックスが必要なため)。 1 GBのメモリと1つのプロセッサでの4コアの使用は、データベースサイズが小さいため、制限が厳しすぎるとは思えません。最大200人の同時ユーザーが存在することは決してなく、ほとんどの操作はトランザクションに依存します(重いRAM / CPUよりも多くの高速ディスクを好むようです)。 SQL Server Standardの利点のうち、当初は5〜2000万ドルの追加投資を正当化できるものがありませんか?

2
utf8_unicode_ciとutf8_general_ciの影響を測定するMySQLパフォーマンスベンチマークはありますか?
私が読んでこことそこに使用していることをutf8_unicode_ci照合すると、デフォルトに比べて(例えば、そのような検索や発注のための「OE」へのOE」などの文字を拡大する方法をknowns)のUnicodeテキストのより良い治療を保証utf8_general_ci基本的には発音区別符号を除去します。残念なことに、両方のソースは、それutf8_unicode_ciがよりもわずかに遅いことを示していutf8_general_ciます。 だから私の質問は:「少し遅い」とはどういう意味ですか?誰もベンチマークを実行していますか?パフォーマンスの影響が-0.01%なのか、それとも-25%のようなものですか? ご協力いただきありがとうございます。

3
Microsoft SQL Serverのインストール場所の重要性
安価な低速ディスクと高価な高速ディスクを搭載したサーバーがあります。 データベースなど、高速であることが重要なすべてのものに高価なディスクを使用したいと思います。 お金を節約するために、バックアップなど、高速でも低速でもほとんど変化がないものに低速ディスクを使用したいと思います。 さて、私の質問は、Microsoft SQL Serverを低速ディスクまたは高速ディスクにインストールする必要がありますか? (明確にするために、データベースは何があっても高速ディスクに配置するので、私の質問はインストール自体の場所にのみ関係します)

3
postgres stats collectorプロセスによって生成されたI / Oが多すぎます
ローカルのpostgresデータベースを持ついくつかの仮想マシンでXenServerを使用しています。すべてのアプリケーションが使用されておらず、データベースがアイドル状態の場合でも、各vmは一定のストレージネットワークトラフィックを引き起こし、iscsiストレージデバイスのパフォーマンスを低下させます。 実行後iotop、postgres stats collectorプロセスプロセスが約2 MByte / sのレートでディスクに常に書き込みを行っていることに気付きました。 次に、編集して統計の収集を無効にしました/etc/postgresql/8.4/main/postgresql.conf: #------------------------------------------------------------------------------ # RUNTIME STATISTICS #------------------------------------------------------------------------------ # - Query/Index Statistics Collector - track_activities = off track_counts = off ... http://www.postgresql.org/docs/8.4/static/runtime-config-statistics.htmで提案されているとおり。 これは継続的な書き込みを排除しましたが、統計の追跡をオフにするデメリットはありますか? または、ディスク/ネットワークトラフィックを回避するために、ラムディスクにpg_stat_tmpディレクトリを配置する必要がありますか? システムは最新のDebian 6.0.7(squeeze)であり、postgres 8.4および約20のデータベースに約50のテーブルがあり、ダンプファイルの合計サイズは100 MB未満です。

1
大量の行を削除した後、テーブルのREINDEXとVACUUMを行う必要がありますか?
ログ情報を格納するいくつかのテーブルを持つPostgreSQLデータベースを実行しています。この情報はレポートのみを目的としており、30日以上経過するとファイルにダンプされ、データベースから削除されます。 何百万行も削除される可能性があり、削除後に毎回REINDEXを実行しています。 これで十分ですか、それともVACUUMまたはVACUUM ANALYZEも実行する必要がありますか?または、REINDEXは必要ありません。代わりに、VACUUMまたはVACUUM ANALYZEを実行する必要がありますか? 私たちはPostgreSQL 8.2.3を使用していますが、自動バキュームは許可されていません。

2
PostgreSQLは多数のデータベースでどの程度うまく機能しますか?
登録ユーザー(実際には会社)を他のユーザーから分離する必要があるアーキテクチャを持つWebアプリケーションがあります。つまり、同じWebappを同じデータモデルで実行しますが、顧客ごとに異なるデータセットを使用します。 したがって、Postgresで顧客ごとに異なるデータベースを作成することを検討しました。このソリューションは、たとえば10〜20Kのデータベースに拡張できますか?いかに良く? 誰かがこれのためのより良い解決策を持っていますか? 前もって感謝します。

1
mysqlデータベース設定の最適化
主にinnodbを実行するトラフィックの多いデータベースがあり、mysql構成をより最適化したいと考えています。サーバーには32Gb RAMがあり、最大のテーブルは〜18Gb innodbです。パフォーマンスを向上させるためにすべての明白なことを行ったと思いますが、他の人が何を勧めるか疑問に思います。 [mysqld] datadir=/mysql/data socket=/var/lib/mysql/mysql.sock pid-file=/var/run/mysqld/mysqld.pid key_buffer_size=1G read_buffer_size=16M sort_buffer_size=16M innodb_data_home_dir=/mysql/innodb innodb_log_group_home_dir = /mysql/log innodb_file_format=barracuda innodb_file_per_table=true innodb_thread_concurrency=8 innodb_buffer_pool_size=20G innodb_additional_mem_pool_size=128M innodb_log_buffer_size=512M innodb_flush_method=O_DIRECT innodb_flush_log_at_trx_commit=2 innodb_lock_wait_timeout=50 myisam_sort_buffer_size=64M read_rnd_buffer_size=32M max_connections=125 max_user_connections=90 sql-mode=traditional tmpdir=/mysql/tmp slow-query-log=1 slow-query-log-file=/mysql/tmp/mysql_slow_queries.log max_allowed_packet=32M tmp_table_size=128M max_heap_table_size=128M open_files_limit=8096 join_buffer_size=256M thread_cache_size=150 table_cache=8096 query_cache_size=512M query_cache_limit=32M expire-logs-days=3 log-error = /mysql/log/mysqlderror.log max_binlog_size=1G interactive_timeout=3600 wait_timeout=28800 [mysql.server] user=mysql [safe_mysqld] …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.