オープンソース情報データベースシステム(OSS iPedia) は、2013年5月17日(金) をもちまして運用を終了いたしました。 長い間ご利用をいただきましてありがとうございました。 OSS iPediaで提供しておりました、IPAフォント、文字情報基盤、その他報告書等については、下記リンクをご参照ください。 皆様には大変ご不便をおかけいたしますが、何卒ご理解の程をよろしくお願い申し上げます。
ストレージエンジンとしてInnoDBを使うときはMyISAMのときと触るべきポイントが違うので注意。 http://www.mysqlperformanceblog.com/files/presentations/OSCON2004-MySQL-Innodb-Performance-Optimization.pdf を読みながら取ったメモ。状況としてはRedHat AS3.0で動かしたときのDBT2*1のパフォーマンスを改善していくというもの。MySQL デフォルト状態での分析 Handler_read_nextが多い、つまりrange scanかindex scanが多すぎる slow query logで何が悪いかを引っかける 例では2秒以上処理にかかったqeuryを記録するようにしている 結果を分析 update文が遅かったけど、update文そのままではexplainできないので、
MySQL is a widely used and fast SQL database server. It is a client/server implementation that consists of a server daemon (mysqld) and many different client programs/libraries. You can check the same tips from here.Here is very useful tips for all mysql DBA’s,Developers these tips are noted from MySQL Camp 2006 suggested by mysql community experts. Kaj (Most Excellent Obvious Facilitator) Index s
Every so often people ask me the question how should they estimate memory consumption by MySQL Server in given configuration. What is the formula they could use. The reasons to worry about memory usage are quite understandable. If you configure MySQL Server so it uses too small amount of memory it will likey perform suboptimally. If you however configure it so it consumes too much memory it may be
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください! まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
This blog is in reference to our previous ones for ‘Innodb Performance Optimizations Basics’ 2007 and 2013. Although there have been many blogs about adjusting MySQL variables for better performance since then, I think this topic deserves a blog update since the last update was a decade ago, and MySQL 5.7 and 8.0 have been released since then with some major changes. These guidelines work well for
突然何の脈絡もないですが、func package controllerなるものを作成しました。 ダウンロードはこちらから:fpc-1.0.zip これはfunc (Fedora Unified Network Controller)というサーバ管理フレームワークを使っているシンプルなPythonスクリプトで、以下のようなことができます。 ・大量のサーバに一括してRPMをインストールする。 ・大量のサーバから一括してRPMをアンインストールする。 ・大量のサーバの任意、または全てのパッケージをアップデートする。 ・大量のサーバの内、任意のRPMがインストールされているサーバをしらべる。 ・大量のサーバの内、任意のRPMがインストールされていないサーバをしらべる。 つまりは大量のサーバのパッケージ管理がワンライナーでできますよ、というツールです。 インストール方法や使い方などは付属のREAD
http://www.mysql-ucj2007.jp/details/j25.html 木下 靖文 氏 NTTコムウェア株式会社 プロジェクト管理統括部技術SE部門 DB技術グループ (「InnoDB」は「いんのでーびー」と言うらしい...今まで「いのでーびー」と言ってました) InnoDBをなぜ使うか トランザクション コミット、ロールバック、セーブポイント 外部キー 行レベルロック オンラインバックアップ クラッシュリカバリ クラッシュリカバリ MyISAMはデータ量の増大とともに時間がかかる InnoDBはデータ量の増大との相関がない InnoDBチューニングの王道的アプローチ クエリを改善して全体的に処理効率を上げる データサイズをできるだけ小さく メモリをできるだけ多く積む コミット性能(同期書き込み) innodb_flush_log_at_trx_commit=1,0,2
パラメータで言うとinnodb_flush_method っていう奴。 ようはトランザクションログなどをディスクに反映するときにfsync(2)を使うか、そもそもファイルをopen(2)するときにカーネルのバッファをバイパスするようなオプションを使うかの違い。デフォルトだとfsyncdataになるため前者になるが、Linuxの場合O_DIRECTを指定することで後者の動作となる。 InnoDBはI/Oのバッファリングを独自に行うことが出来るので、OSが提供するキャッシュを切ってしまった方がメモリの無駄が少ない。 例によって使ったベンチマークはsysbench-0.4.8、MySQLは5.0.37 Threads fdatasync O_DIRECT 1 19.8 20.31 2 20.88 21.04 3 21.06 20.64 4 20.89 20.78 5 21.15 21.03 6
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く