3

古いサーバーを完全に新しいハードウェアに交換しようとしていますが、奇妙なことが起こります。

  • 古いマシンはAMD Athlon 64 X2 5600+ @ 1GHzで、Debian 4.0 32 ビットと 2x380 GB (またはその程度) の HDD を RAID1 で実行する2 GB RAMを搭載しています。
  • 新しいマシンはIntel i7-3770 @ 3.4GHzで、32 GB RAMを搭載し、Debian 6.0 64 ビットを実行し、RAID1 (6Gbps SATA、7200rpm) で 2x3TB HDD を搭載しています。

SQL ダンプ (以下を参照) をロードするとき、新しいサーバーは約32 分間ビジーです。新しくインストールされたので、サーバーは他に何もする必要がありません。一方、古いサーバーは、他のことで忙しいにもかかわらず、32%少ない時間がかかります。それはどうしてですか？

どちらのマシンも Debian の最小イメージを使用してインストールされ、必要に応じてパッケージがインストールされています。

古いサーバーと新しいサーバーの両方のmy.cnf 設定を使用し、新しいサーバーでははるかに大きくなります (16 GB 対 0.5 GB)。innodb_file_per_tableinnodb_buffer_pool_size

SQL ダンプに関するデータ:

  • 完全に新しいデータベースをロードする ( CREATE DATABASE)
  • 16テーブル
  • 遅い単一の大きなテーブル (約 1,2M 行 / 240MB の SQL データ)
  • 外部キーを持つ InnoDB
  • ダンプ使用LOCK TABLES "xxx" WRITE; ALTER TABLE "xxx" DISABLE KEYS;(によって生成mysqldump)

そのことをスピードアップする方法はありますか？

アップデート

/var古いマシンは専用の 50GB ext3 パーティションを使用しているのに対し、新しいマシンは 1TB の ext4 ルート パーティション (を含む/var) と 2TB の ext4 を使用していることに気付きました/home。どちらの場合も、 MySQL データは at/var/lib/mysql/にあります。

更新 2

どうやら、小さなブロックの処理が遅いのは HDD です。

# dd if=/dev/zero of=test bs=1024 count=100 oflag=direct,sync
102400 bytes (102 kB) copied, 2.49824 s, 41.0 kB/s

古いサーバーは、同じテストで1.1 MB/秒に達します。

大きなブロックは、新しいサーバーで処理できます。

# dd if=/dev/zero of=test bs=1024k count=100 oflag=direct,sync
104857600 bytes (105 MB) copied, 7.11175 s, 14.7 MB/s

hdparm書き込みキャッシュが両方のドライブでオンになっていると言います。パーティションテーブルの配置の問題ですか? 私のパーティションテーブルを見てください。

4

2 に答える 2

2

わかりました、私はこれの理由を見つけました。うまくいけば、これは他の人を助けるでしょう.

ext4はそのシステムで「バリア」を有効にしていたため、小さな書き込みが非常に遅くなりました。このような書き込みは、データベース ファイルでは正常です。

バリアを無効にするとパフォーマンスが向上し、同じ SQL ダンプが最大 8 分で読み込まれます (4 倍の速さ)。

mount -o remount,barrier=0 /

バリアを無効にすると fs の整合性にマイナス面が生じるため、まずそのことを考えてください...

于 2012-11-14T16:32:57.797 に答える
0

新しい構成ファイルの最後に次の行があります。

!includedir /etc/mysql/conf.d/

そこにあるファイルがこれらと同じであると仮定します: https://github.com/biapy/howto.biapy.com/tree/master/mysql、つまり、これらの設定を (とりわけ) 確認する必要があることを意味します。 :

ベース最適化.cnf:

log_bin = /var/log/mysql/mysql-bin.log
sync_binlog = 1
于 2012-11-14T14:59:47.817 に答える