案件・業務の進捗記録と備忘録

業務用のサーバではありませんが、私が稼動させているMySQL4サーバーのパフォーマンスを測定してみました。

パフォーマンスを決める要素は、

●サーバ自体の設定(スレッド数・処理メモリサイズ・キャッシュなどのシステム変数)
●テーブル構造・インデックス
●クエリ

が関わってきます(※64bitカーネルなどなら、適切なビルドを用いることももちろんです)。これらが最適になるように計画して稼動を開始したので、それが狙いどおりであれば、いいパフォーマンスが出るはずです。それを確かめるのが今回の目的となります。

当方でMySQL4が稼動しているサーバは、並列でApache・Postfixも稼動していますが、小規模なサーバではそのようなケースも多いと思いますし、なにしろ相当古い計算機でもあります。いくらなんでも今時こんな低クラスのサーバは何処へ行っても買えませんが、古いものでもどの程度のパフォーマンスが出せるのか・という参考値としてご覧下さい。

■計算機のスペック
　i815 / Pentium!!! 733MHz / PC133 SDRAM 512M / IDE SoftwareRAID1(MD)
　Apache 1.3 / request 20,000 - 100,000
　Postfix 2.1

MySQLは外部からの接続が殆どで、ローカルのApacheなどからは呼び出されていません。データベース数は３つ、うちテーブル数は５つ(MyISAM=3/InnoDB=2)、おおまかですがカラム数(フィールド数)は10-50・ロウ(レコード数)は10,000以下くらいです。

まず、サーバの稼働時間ですが、現時点で247 日, 15 時, 26 分 34 秒となっています。この間、テーブルを変更・追加などはしていませんので、パフォーマンスを測定するのには十分な期間です。

MySQLへの接続数は7,663,183、１時間あたり1,289.35接続がありました。
要求クエリ数は、毎秒1.44クエリとなっています。但し、外部からの要求は同時に連続して10以上の接続とクエリ発行が来るシステムになっているため、密度はばらつきます。

それでは、パフォーマンスの参考値としてステータスを見ていきすが、ステータスの値によって、冒頭に示したパフォーマンスを決める要素の、「どの部分は適切で・改善するならどの点なのか」を見ることが出来ます。

起動してからの総クエリ数 = 30,798,128　起動してから、これだけのクエリが送られています。この数値とステータスとの対比が判断材料の一つになります。

Created tmp disk tables 0
このステータスに限らず、メモリ＆ディスクへのテンポラリテーブル作成はゼロでした。もっとも、テーブル結合をしているクエリが無いので、それも理由になります。

Handler read first 11484 ← インデックスのフルスキャン
Handler read key 17797594 ← キーに基づくレコード読み込み
Handler read next 26107115 ← キー順序での次レコード読み込み
Handler read rnd 1095850 ← テーブルのフルスキャン
ランダムでロウを選択する・カラム値とランダム値が同一のロウを得るようなクエリも投げているので、全体スキャンも発生していますが、概ねインデックスの貼り方が良かったと判断できます。

Key read requests 32669452 ← キャッシュ内からのキー読み込み要求
Key reads 210 ← ディスク内からのキー読み込み要求
キャッシュのミス率は6.4280233411934794620981092673363e-6、キーバッファが適切に割り当てられ、機能していることがわかります。

Open tables 22 ← 現在開いているテーブル数
Opened tables 145 ← これまで開いたテーブル数
稼働時間・要求数に対して、非常に小さな値ですので、テーブルキャッシュのサイズが適切に割り当てられているようです。

Table locks immediate 15361607 ← テーブルロック要求で即ロック実現
Table locks waited 7672 ← テーブルロック要求で待ちがあった
MyISAM・またはクエリで明示的にテーブルロックを指示した結果数です。専用サーバではなく、同じテーブルに対して連続して読み書きのある要求が多い中で、この結果が出たということは、クエリとテーブル設計・インデックスが適切であることを示し、この結果は良好だと考えられます。

Threads cached 15 ← 現在動作して処理待ちをしているスレッド数
Threads created 74 ← これまで作られた最大スレッド数
Linuxの場合、一つの接続を一つのスレッドで処理しているようですので、これまでの稼動の間に、並行で74の要求を処理したことがあったようです。

さらに参考までに、40のカラム・500のロウを持つテーブルに対して、varchar(255)でカーディナリティの高いカラムを昇順でソートした結果を得るための時間を出してみます(このカラムはインデックス化されています)。

SELECT * FROM `footable` ORDER BY `HOGE` ASC

このクエリの結果は、0.0026 secで得られました。

上記によって、自分の行ったテーブル設計やクエリ最適化がうまくいっていることを確認できたことが嬉しくもありますし、同時に、こんな古臭い計算機でもこれだけのパフォーマンスを叩きだすMySQLの凄まじい速さに、改めて驚きを禁じ得ません。

元の記事はこちらを参照

IT関連企業の上場先としては、いわゆる新興市場が主になるのですが、その新興市場の上場審査を緩めることで、失墜した新興市場の信頼を取り戻し、ベンチャー企業の成長を後押しし、活性化を促せるとの目論見で、研究会を発足との事です。

株価は、市場を反映して会社の資産価値に繋がるものですが、「失墜」とは、まさに株価の下落で、市場が新興市場を嫌って、資金が入ってこないのです。

新興市場のIT関連株で、公開後の運用で利益を得られた投資家が、果たしてどのくらい存在したのか。市場の信頼失墜の理由として、ライブドアショックが明記されていますけれども、それが果たして今現在までの評価にまで、ずっと影響を与えているのでしょうか。

それは違うでしょ・と、私は思います。企業に成長の兆しがあれば、必ず市場は反応します。少なくとも、短期投資目的で利ざやを稼ごうとするならば、間違いなく買い気配の反応があるはずです。そして、信用と信頼感があれば、株式を長期運用しようとする人も出ますし、取引も活発になります。

ということは、現在の状況を見る限り、市場は新興市場に「失望」しており、投資価値を見出していない・これまで果てしなく損をさせられた新興市場に浮かれている状況ではない・と考えるのが普通です。

そこに、上場審査を緩和させたらどうなるか。それこそ、IPOのみを狙う投資の動きに拍車が掛かります。公開日に株を入手したら即高値で売却する、その後は持った人が損切り・損切り・損切り…、一番最後の人がジョーカーを持っている状態です。これでは、もう投資ではなくて投機です。また、創業者利益を確保した何年か後に上場廃止という企業も、これから出てくるかもしれません。

株式は本来、資金を集め易くして企業の創出や成長を助けるのが目的ですが、果たして、資金を集めた後に成長していくような企業が本当に上場しているのか。今の新興市場で取り扱われている銘柄は、どういう状態にあるのか。

審査の緩和は、今の失墜の状況を上回る場当たり的な上場を増やしてしまい、本来の成長を妨げるような気がしてなりません。そして、内外の投資家達は経験を積み、トレンドも見てきているためにずっと賢くなっています。魅力・信頼の無いマーケットに、軽々しく資本投下はしないでしょう。

ベンチャーと言いますけれども、ベンチャーで終わってしまう企業では、一時の金の流れを創出したに過ぎません。企業は社会への貢献が主たる役目ですが、その社会というのは「投資マーケット」だけでしょうか？

上場基準が厳しければ、発展性と展望のある、本当に企業を成長させていきたい経営者がそこを目指すのではないでしょうか。長期に渡って市場の評価を得られる企業、そういう企業にこそ投資価値があると私は思うのですが…