pythonのバージョン上がったらyumが使えなくなった

yum python

元々python2.4で動いていたらしく、誰かが2.5をソースで入れてから使えなくなった。

# yum
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

  No module named yum

Please install a package which provides this module, or
verify that the module is installed correctly.

It's possible that the above module doesn't match the
current version of Python, which is:
2.5.2 (r252:60911, Aug 27 2008, 17:42:48)
GCC 4.1.1 20070105 (Red Hat 4.1.1-51)]

If you cannot solve this problem yourself, please go to
the yum faq at:
 http://wiki.linux.duke.edu/YumFaq

yum本体をいじって、古いバージョンを明示的に使うように修正して直った。

#!/usr/bin/python2.4

たぶんこんなad hocな解決方法ではなくて、きちんとした方法があるはず。だけど今はこれでいいや。

MySQLユーザコンファレンス2008 2日目(10/31)メモ

mysql mysqlcon2008

1日目のメモはこちらです。-> MySQLユーザコンファレンス2008 1日目(10/30)メモ

MySQL Performance Tuning 1 (10:00 ~ 10:50)

queryのスループットについて
slow query logを調査
  • インデックスを活用する
  • クエリを書き直す
  • オプティマイザの問題
applicationの問題
  • app-db間のラウンドトリップ
  • 1回のSQLで出来るものを、複数回query投げていると遅くなる
スロークエリログについて
  • 名前の通り遅いクエリをロギングする
  • mysqlに組み込まれている機能
  • スロークエリ = 最適化の余地があるクエリ
  • でもスロークエリログだけでは問題を解決できない
    • そのクエリのどの部分が遅いのかはわからない
    • 表示されたくないメタデータも表示されてしまう
mysql 5.1で拡張される機能
  • fileだけでなくて、tableにもロギングできる
  • 稼動中にロギングのon/offの変更が出来る
  • 単位がマイクロセカンドになる (以前は秒単位)
  • しきい値(long-query-time)を0秒にして、全クエリログを取ることもできる
mysqldumpslow
  • スロークエリログの統計を取れるスクリプト
    • mysqlに付属
    • 同じクエリのグループ化
  • mysql 5.1のものにはbugがある => 次のバージョンで修正
EXPLAIN文
  • クエリのどこが悪いかを調べるために使う
  • 使い方 - クエリの前にEXPLAINをつけるだけ
  • select_type
    • simple: selectだけのクエリ
    • subquery: UNION、JOINとかを使うクエリ
  • type
    • single_row
    • system: テーブルにひとつの行だけのとき
    • const
    • eq_ref
    • ref
    • range
    • index: Full index scan
    • all: Full table scan
  • extra
    • Using where
    • Using temporary
    • Using filesort
    • Using index
    • Using index for group-by
mk-virual-explain
  • EXPLAINの結果がツリー状に表示される
  • http://www.maatkit.org
    • Part of the Maatkit toolkit
  • このツールはフォローするのが難しいねーって言ってた
  • 午後のセッションでさらに掘り下げるよ
query cache
  • クエリと、その結果をキャッシュする
    • 同じクエリが投げられたら、キャッシュしてる結果をクライアントに返す
  • ハッシュ構造
    • クエリがキー、結果が値
  • 結果が同じ(ex:whereの条件の論理的な意味が同じ)でも、クエリが違えばクエリキャッシュは有効にならない
    • sql1: where a = 5 OR a = 10
    • sql2: where a IN(5,10)
  • 実行するたびに結果が変わる関数もキャッシュされない
    • DATEとか
Configuration Options
  • query-cache-type
    • NO_SQL_CACHEと明示的に指定したらキャッシュしない
  • query-cache-size
  • query-cache-limit
show global status
  • Com_select
    • キャッシュにhitしなかったクエリ数
  • Qcache_hits
    • キャッシュにhitしたクエリ数
  • 他にも色々パラメータがある
    • show global status like 'Qcache_%';
query cacheには注意も必要
  • 非常に大きいサイズにしてしまうと、その分キャッシュのパージに時間がかかる
    • パージ中はキャッシュできないので、実質止まるようになる？(と言ってた気がする。でも止まるの意味がよくわからない)
    • キャッシュサイズ 12GByteとかやめてね！ Hahahaha
  • 負荷の高いサーバの場合、クエリキャッシュをdisableにしたほうが逆に性能あがるかも
    • クエリがキャッシュにhitするか都度チェックするため？？

MySQL で押さえておくこと (11:00 ~ 11:50)

Table/Index Partitioning
  • テーブルを別々の領域に分ける
  • I/O負荷が下がる
  • Partitioningの種類
    • range,list,hash,keyなど
  • 特定の条件で振り分ける
  • Partitioningの例
    • mysql> desc partitions;
    • 800万行のデータに対して、パーティションの有無でのselect結果の比較
    • 38.30sec => 3.88sec 90%の性能改善
Full Text/Plug-in Enhancements
  • ParserをPlug-inで追加できる。
    • SHOW PLUGIN
    • UNINSTALL PLUGIN
    • INSTALL PLUGIN
XML Xpath Support
Archive Engine Enhancements
  • Faster I/O operations
  • Lower Memory
  • Autoincrement column support
    • Unique key support
    • Non-unique key support
  • Archive Reader tool
MySQL Cluster Disk-Based Data
  • 今までのクラスタはメモリベースだった
    • (データもインデックスもメモリに置く必要があった？)
  • 5.1ではこれを拡張して、データはディスクに書けるになった。
    • メモリに置くのはインデックスだけ
Row-Based Replication
  • 行ベースレプリケーションに対応
  • 今までのステートメントベースのバイナリログによるレプリケーションでも90％は大丈夫
    • でも、Non-Deterministicなクエリを使うと駄目
  • Insertの場合はステートメントベースでも、行ベースでも速度はあまり変わらない
  • Updateの場合は行ベースの場合、コストが高くなる
    • 全部 or 大量の行をupdateする場合は駄目？
    • primary insertで少しの行だけupdateする場合はよい
  • InnoDBだと行ベースレプリケーションで性能がよくなる
    • とあるロック処理がないから、らしい
Easier Manageability
  • Event
  • タスクプロシージャ(ストアドプロシージャ)
  • 特定の時間にOPTIMIZEを実行とか出来る
    • linuxでいうcronが、MySQL内で出来るということ
  • ストアドプロシージャがうまく書けなかったらクビになるかもしれない。けど、皆さんなら大丈夫ですよね Hahahaha
High Performance
  • Faster Alter Table/Faster Add-Drop Index
その他

MySQL Performance Tuning 2 (14:00 ~ 14:50)

大盛況。人数多すぎて制限かかった？ 時系列とは異なりますが、午前のセッション繋がりなので、こちらを先に書きます。後半は私の脳みそのスタミナ不足により内容に追いつけませんでした。

benchmark環境
  • ロギングは全て止める
  • クエリキャッシュもoff
  • 十分に大きなメモリ
  • ベンチマークツールはsuper-smack
  • 同時connectionを1から256まで増やしてテスト
評価対象のENGINE
結果(指標はqps?)
  • MyISAM: connection 16以降でスケールしない
  • MyISAM with insert delayed: connection 64以降でスケールしない
  • InnoDB: connection 64以降でスケールしない
  • Archive: connection 256までスケールする
CPU利用率
  • MyISAM: connection 64以降でCPU利用率が落ちた
    • 接続数増加によるテーブルロックが原因
  • Archive: CPUをうまく利用する
Disk利用率
  • InnoDB: 利用率は常に60％以上
  • 他のENGINE: 30％程度
まとめ
  • Archiveは性能は良いが、用途が限られる
    • update,deleteできない
    • 検索用のINDEXが使えない
TIME-ENTRY
  • timestampが一番良い
  • TRIGGERが一番悪い
INDEX Merge Test
InnoDB INDEX Merge
status
  • SHOW GLOBAL STATUS LIKE 'handl%';
  • SHOW SESSION STATUS LIKE 'handl%';
  • SHOW ENGINE INNODB STATUS\G

@Nifty ココログ PostgreSQLからMySQLへのマイグレーション考察 (13:00 ~ 13:50)

cocologとは
  • Niftyが運営 / 富士通グループ
  • おそらく日本の大手ISPで最初のblogサービス
    • TypePad, Movable Type by SixApart
    • 数億PV/月 (日本では10番以内ぐらい？ 中〜大規模)
  • ユーザ数 2008/04時点で70万人、もうすぐ80万人
  • UI
    • TypePadとほぼ同じ
    • TypePadのバージョンがあがればcocologもバージョンあがる
ユーザ数、記事数
  • ユーザ数は無料会員のほうが多い
  • が、投稿記事数は接続会員(ISPユーザの有料会員)のほうが多い
現在のシステム構成
cocologの歴史
  • Phase1
    • DB: PostgreSQLのサーバ１つ
    • 10サーバ
    • TypePadで静的コンテンツをはいて、Webサーバにうｐ
  • Phase2
    • 50サーバ
    • デザイン、テンプレートなどでサーバが増えていく
    • appとDBとが密結合
    • Typepadのバージョンupにあわせて、スキーマ変更、SQL変更が必要になる
  • Phase3
    • memcached採用
    • 携帯に対応
    • 200サーバ
    • このころからPostgreSQLは腫れ物のように
    • 統計情報を取得することすらガクブル
  • Now
    • 150サーバ
    • MySQLに移行
DBP: Database Partitioning
  • 全情報を1サーバにもっていたものを、ユーザごとに振り分け
    • ユーザごとの共通DB、ユーザごとのDBなどに
  • TheSchwartzにjobを投げて、1ユーザずつPostgreSQLからMySQLに移行
Postgresql => MySQLで困ったことなど、苦労話
  • Postgresql時代
    • DBサーバ。上位スペックの機種に買い換えて耐えていた
    • 最終形態: Redhat AS4, 3.3GHz 2Core * 4, mem 16G
  • Postgresql 7.4 => 8.1
    • Data size 100GB
    • 巨大なインデックス (40%)
    • 7.4 => 8.1にして早くなった
  • 文字コードで困った(UNICODE圏のSPAM)
    • 8.1のrestore時にはじかれた

MySQLユーザコンファレンス2008 1日目(10/30)メモ

mysql mysqlcon2008

MySQL ユーザコンファレンス - 10/30 - サン・マイクロシステムズ

場所はJR東京駅からすぐの東京ステーションコンファレンスの5F。受付のロゴはMySQLじゃなくてSUNでした。主催だから当然か。会場の規模の割りには参加者が大勢きていて、一部のセッションで入場制限、立ち見になっていました。
というわけで、まず1日目のメモを。
2日目のはこちら -> MySQLユーザコンファレンス2008 2日目(10/31)メモ

State of MySQL from Sun (10:30 ~ 12:00)

基調講演
  • 皆さんご存知の通り、今年の始めにSUNがMySQL ABを買収
  • 対応プラットフォームも今まで同じ (unix,linux,windows,mac)
    • Solaris,javaに特化する、なんてことはないらしい
  • ダウンロード数
    • 6万DL/日 (今年1月)
    • 7万DL/日 (最新)
  • ダウンロード元をプロットしたグラフ
    • 世界地図の輪郭ができた => 世界中で使われてるということ
    • アメリカ、日本(北海道を除く)、韓国あたりの色が濃かった
    • 北海道でも活動しろ、と営業に言っておく(笑
ダビッド・アックスマークのお話
  • 特徴
    • pluggable storage engine
  • ex)
    • Archive
      • select,insertのみ(updateとdeleteがない)
      • ロギング用に使えるかも
    • InfoBright
  • 組み込み
MyNA (MySQL日本ユーザ会)
  • 2000年設立
    • ML参加人数 3500人ほど
  • SUNと統合して期待すること、不安なことなど
    • 日本語ドキュメント、情報の提供
    • MySQL AB時代に勉強会などで色々助けてもらった。今後(SUNに統合されてから)も協力して欲しい
    • java,solarisに特化したものにならないか (基調講演でも述べられてたから、これはないらしい)

Amebloで比較するMySQLストレージエンジンとファイルシステム (13:00 ~ 14:00) - サイバーエージェント 岡田 達典 氏　大黒 圭祐氏

あとで資料をうｐする予定と言ってた。前半は岡田さんの発表。

インフラチーム
  • DBチーム
    • OS/サービスにあわせたMySQL,mMeasureのRPMの作成
    • サーバのラックマウントもしてるらしい
      • ラックは自社の地下？にある。まだスカスカ
    • サーバの自作もしてる
サーバ構成 過去と現在
  • 2006年9月時点
  • 現在
    • Oracle 10g Rac
      • ？台 (聞き逃した。3台と言っていたような。。)
    • MySQL
      • master 1台
      • slave 41台
      • Masterが壊れたら、手作業で代替機と交換(後の質疑応答より)
      • mMeasureで負荷、qps等を監視
    • 画像はNAS(NFS)サーバに
    • SunWeb,Web Logicからapache,tomcatに変更
    • web/appサーバを参照/更新に切り分け
    • キャッシュサーバの構築
    • NFSだと負荷がかかるのでWebDav化
    • 50億PV/月
OracleからMySQLへの移行
  • バッチ処理による移行ツールを行おうとしたが、、、
    • 時間がかかりすぎて失敗
  • DBのdump、importを使うように変更
    • Oracle => UTL_FILEでエクスポート
    • MySQL => LOAD DATA INFILEでインポート
    • 2億件の記事を4時間程度で終了
  • 他にもPostgres,DB2からもMySQLに移行
appの参照先をOracleからMySQLへ変更
  • MySQLに変えるタイミングで、blogのインタフェースも変更
    • ユーザからの使いにくいといわれていたため
  • Oracle時代のSQL
    • 2回SQLをたたくシンプルな構成
  • MySQL時代のSQL
    • SQLを16回たたく
    • 月ごとの記事へのリンクを表示するようにしたため
チューニング1
チューニング2
  • ディスクI/Oが負荷の原因になったのでslow query logを調査
    • PVが多い、ユーザごとのblogのトップページを対象
  • EXPLAINでSQLを調査
    • "Using filesort"が出てきた (パフォーマンスが悪い)
    • INDEXを修正して、"Using index"になるように修正
サーバの負荷状況
  • SQL改修後slow queryは0に (slow-query-timeは2秒)
  • SQL発行回数は増加(ピーク時では1分間に5万弱)
  • load averageは減少 (DiskI/Oが減少したから)

ここで前半終わり。次後半。

実践検証 ストレージエンジンとファイルシステム (大黒さん)

各my.cnfの設定はDLできる資料に載せるらしい。

サーバ環境
  • CentOS4
  • ext3
    • xfsはストレージ(画像)系には使ってるけど、mysqlには使ってない
  • mysql 4.1.21
    • ほどんど4.1系を使用してる
    • でも5.1 rc使ったらパフォーマンス良かったので、変更していくかも
strage engine
  • InnoDB
  • Archive
    • 個人的にどこかで使えないか模索中らしい
検証内容
検証結果
  • ext3 < xfs
    • 全エンジンでxfsのほうが1割ほど上
  • MyISAM < Maria
  • MyIsam,Maria < innodb
    • 単純なSQLならInnodbも早い。たぶんテーブルロックと行ロックの違い？
  • ext3 > zfs(OpenSolaris)
    • zfsはOSが違うので厳密な比較ではない
考察
  • xfs 思ってたよりも良い結果
    • journal logのチューニングでもっと良くなるかも
  • zfs
    • 書き込みはまぁまぁ早かった
結論
  • xfs + MySQLはいい感じ
自作サーバ
  • SSD
    • 読み込みは抜群に良い、でも書き込みはクソだったらしい

Memcached and MySQL - Brian Joker (14:00 ~ 15:00)

発表してた資料はこれらしい。

memcachedを理解してないのでちんぷんかんぷん('A`)

protocol
  • simple
  • text base
  • binaryももうすぐ作るって言ってた？？？
Memcached Functions for MySQL
  • UDF APIとlibmemcached
Installation
  • CREATE FUNCTION memc_servers_add RETURNS INT SONAME "libmemcached_functions_mysql.so"
  • などなど
memcached-tool
libmemcached tools

MySQLユーザカンファレンス2008参加します

mysql mysqlcon2008

ただいま秋葉原に潜伏中。

23:30 追記

1日目行ってきました。とりあえず戦利品をうｐ。
マグカップめちゃでかいす。


おまけ。
飾られてた巨大マスコットのイルカ。ぐぐったら名前は"Sakila"というみたいですね。

MySQL のイルカ（当社のロゴ）の名前は Sakila です。Sakila は、当社の「イルカのネーミング」コンテストで、ユーザによって提案された膨大な数の名前の中から MySQL AB の創設者が選んだものです。

11/2 追記

つたない内容ですが、受講したセッションのメモを書きました。

ubuntuの解像度変更

ubuntu linux

GUIのメニューを探してもそれらしいのが見つからない。コマンド叩いたらいけるようだ。

sudo displayconfig-gtk

Net::CIDR::MobileJP::Scraper::Plugin::Vodafone.pmが動かなくなった

perl

dsasの中の人が作ったperlで、SoftbankのIPだけが取得できなくなったので調べてみた。どうやらSoftbankのIP帯域が載ってるURLが変わったのが原因で、Net::CIDR::MobileJP::Scraper::Plugin::Vodafone.pmが古いままだかららしい。適当に修正したら動くようになった。


作者にお知らせしたいけど、testの書き方わかんないしpatchの送り方とかわかんねぇ。アレか、わかんねぇとか言ってないでこれを機に調べれば良いのか。

# diff -u Vodafone.pm.org Vodafone.pm
--- Vodafone.pm.org     2008-10-11 10:03:00.000000000 +0900
+++ Vodafone.pm 2008-10-11 10:05:25.000000000 +0900
@@ -3,7 +3,8 @@
 use warnings;
 use base qw/Net::CIDR::MobileJP::Scraper::Plugin/;

-sub url { return 'http://developers.softbankmobile.co.jp/dp/tech_svc/web/ip.php'; }
+sub url { return 'http://creation.mb.softbank.jp/web/web_ip.html'; }
+

 sub run {
     my ($self, ) = @_;
@@ -12,7 +13,7 @@
     my $content = $self->get($url);

     my @result;
-    while ($content =~ m!<FONT size="2" class="j10".*?>(\d+\.\d+\.\d+\.\d+/\d+)</FONT>!g) {
+    while ($content =~ m!<td bgcolor=".*?">&nbsp;&nbsp;(\d+\.\d+\.\d+\.\d+/\d+)</td>!g) {
         push @result, $1;
     }
     return \@result;

参考

sendmailのload averageとキュー保持、接続拒否の関係

sendmail

load averageが一定値以上になると、sendmailに怒られて接続できなくなった。

sendmail[1001]: rejecting connections on daemon MTA: load average: 20

デフォルトの状態だと、

  • 8以上になるとキューに溜める
  • 12以上になると接続拒否


だもんでサーバの用途によっては上げたほうがいいかも。そんなにloadavgが高くなるまで放置するなっていう話でもあるけど。

sendmail.mc

dnl loadavgが20以上だとキューに保持
define(`confQUEUE_LA', `20')dnl
dnl loadavgが30以上だと接続を拒否
define(`confREFUSE_LA', `30')dnl

参考